Dan -- > > Comments? Suggestions? Critiques? > > This is nifty. Couple'a things:
Thanks. I really want to get enough of a solution together that we can move the temporary during-development-only ops into a separate oplib (call it 'devel.ops'). This then becomes proof of the overall approach and technique and allows us to start thinking about how the assembler and disassembler interact with oplibs, too. > *) It points out a huge weakness in the build system. We need something > better to generate shared libraries Yep. That one's outside my expertise, I'm afraid. My hope is to get something good enough to commit so folks with the expertise on other platforms can work in their parts to make it work for everyone. I'm happy to coordinate that if we can get people to send me patches for the patch that handle their cases. > *) We definitely need to abstract out the shared library loading > code. dlopen isn't nearly as portable as I'd like. (Check out the hoops > perl 5 jumps through...) Can we "borrow" Perl's implementation by working it into a separate library? Or, are we better off doing our own thing? > *) I'm thinking at the moment that shared libraries need to export a > single function that we call. Metainfo about the library should be in an > external file I considered that. In fact, my current code has distinctly named entries depending upon the the oplib name, which really isn't the best way. I'm thinking about defining an oplib struct and having ops2c.pl generate not only the opfunc and opinfo tables, but to put pointers to them into such a structure. Then, we grab a pointer to oplib_init(), call it and expect it to return a pointer to the oplib struct. How does that sound? > *) We need some core routines to register and unregister opcode functions, > so the single exported function in the library can do what it needs to. Hmmm... We need to move the oplib stuff into the packfile code, since op availability varies by packfile. The main pointer to the opfunc table is not going to be interpreter->opcode_funcs (although we will probably cache it there), but rather interpreter->code->opcode_funcs (built by merging oplibs). I think. > *) We need to decide if changes to outer scope opcode function tables > should propagate to already-constructed inner-scope tables I have thought about opcode assignments varying by bytecode chunk, but not about them varying within a bytecode chunk. I really like the former, and feel itchy when I think about the latter (although I don't necessarily disagree with it). > And you thought this was going to be easy... :) I knew it would be easy to whip up the first piece on my box, but I knew it was going to be tricky to get a complete solution together. My goal is to get something complete enough put together that we can get some shared experience under our belt to guide further refinements. I'm going to do a couple of simple refinements to what I have now along the lines I've outlined above and post a revised patch. Could we put together a small set of requirements we have to meet before we could add something like this to the code base? Once we've met the basics we can work out the rest. Regards, -- Gregor
