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