Front page | perl.perl6.internals |
Postings from August 2001
# -----Original Message----- # From: Simon Cozens [mailto:simon@netthink.co.uk] # Sent: Saturday, August 25, 2001 10:59 AM # To: Dan Sugalski # Cc: perl6-internals@perl.org # Subject: Re: Something to hash out # # # On Sat, Aug 25, 2001 at 10:37:35AM -0400, Dan Sugalski wrote: # > I'm currently thinking of using .pasm as the extension for # parrot assembly # > code, and .pbc for precompiled bytecode. (Yes, the # interpreter loads and # > runs compiled bytecode from disk. Wheee!) Can anyone think # of anything # > better? They seem rather lame. (Bonus points for clever # acronyms gotten # > without strain, or puns in any human language) # # I was using .pas and .pac. Gotta think about 8.3ness, unfortunately. If you're worried about Win32, even Microsoft is breaking 8.3 in Visual Studio.NET. (The extension for VB project files is .vbproj, and VC++ is .vcproj. I'm trying to shuck Win32, but haven't been too successful so far--apparently Tux didn't like my old box.) Besides, both of those can be truncated without any problems. # On an unrelated note, and seeing Dan Bryan's experiments with # different # kinds of switch/dispatch, I think it makes sense to separate out ops # which correspond to PMC vtable functions (add, subtract, # etc.) and those # which don't. Those which do can be done with a switch to save # a function # call, and those which don't can use function pointers. This achieves # the same objective as auto-generating op wrappers around # vtable functions, # (saving one level of indirection) while leveraging the gain # from a split-level # op despatch loop. Not a bad idea. Allowing for optimizations later so they aren't premature is usually a good idea. :^) --Brent Dax brentdax@cpan.orgThread Previous | Thread Next