James -- > I'm having a parrot-project weekend, y'all might have noticed. Right now, > I'm thinking of multiple oplibs, specificly how to get the bytecode/packfile > to express it.
I've been working on this. I've added an opcode_table section that contains (oplib, opindex) pairs (they are constant table string indexes to allow lookup by name). The custom opcode table for the bytecode in the packfile is produced by scanning this, loading oplibs as they are referenced. The opcodes for the bytecode are presented in order, and only the opcodes actually used need be mentioned. So, opcode N for one bytecode chunk could be a totally different opcode from opcode N in a different bytecode chunk. This may be too flexible for some people's liking, but I'd like to see it happen, hoping that we can create some special case capabilities for folks that want more optimization to do things in a more rigid manner. > Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify > the oplib (as an index to the table of oplibs, see the next para), the rest > can identify the opcode. This shouldn't be too bad a limit: 64k opcodes > perl oplib, 64k oplibs per packfile. > There should be a table of oplibs used (probably in the fixup section, but > possibly in imports) in the packfile. Each entry should have the name of > the oplib and a signature. (The index is implicitly inorder.) > > The number one problem I see with this is that when we can dynamicly load > bytecode, different peices might want to have different oplibs. The best > way I see to handle this is to know in the runops core that we're > dispatching to a different set of tables when we cross boundries between > opcode peices. > > I'm going to set about implementing this now. This should be fun... What do you think about what I've written above? Regards, -- Gregor
