Building support for non-native bytecode

Now that we've got docs and specs for many of the other VM systems 
out there, it's time to see about writing code to execute them. There 
are three basic things we need here for each.

1) A bytecode loading module. This takes on-disk non-native bytecode 
and turns it into parrot bytecode. At the very least this'll mean 
extending many of the bytecode formats from an 8-bit format to our 
32-bit format, and remapping the opcode numbers to wherever their 
appropriate opcode numbers have mapped to.

2) A set of opcode functions for the non-native bytecode. There 
doesn't have to be a one-to-one mapping--it's perfectly acceptable to 
use existing parrot code if it fits, or to map a single source opcode 
to one of several different parrot opcodes. (.NET, for example, can 
benefit greatly from this, as it has generic opcodes that can be 
given a speed boost by transforming them to more specfic opcodes)

3) Potentially some per-interpreter information specific to the 
opcode set that shouldn't necessarily be in the global namespace. The 
z-machine, for example, may benefit from having a current story data 
pointer somewhere. (I'd rather keep this as part of the global 
namespace somewhere, but if it truly becomes necessary, well, we'll 
do it)

I don't see any of these as particularly troublesome. I'll get the 
specs for dynamic opcode and PMC loading out in the next 24 hours, 
and the specs for some of the support stuff soon after. (Then 
followed by a first cut extension mechanism, but that's for later)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

• Building support for non-native bytecode by Dan Sugalski