Dan Sugalski <[EMAIL PROTECTED]> wrote: > Here's some stuff we need to add to the packfile format and the sub > header to get things ready for more language work.
First: any changes here imply, that assemble.pl/disassemble.pl will seeze to work. So first step would be: grep the tree and remove all traces of these programs. > Packfiles need to have a symbol table. A series of name/type/location > tuples so we can have global names that map to values in the > bytecode, either variables or subroutines. The successor/extension of the current fixup table, which has name/location. > ... When the bytecode is > loaded, we need to put those symbols in the symbol table and > construct the backing PMCs. Which backing PMCs? The subroutine itself? And how are global symbols related with the global stash? > ... When we invoke a > sub (or closure, or continuation, or whatever) we need to put that > packfile pointer and bytecode start/end pointer in place, First is: How do we load subs/packages/modules? pdd06 has C<load_bytecode sx>, does that prederef or JIT at loadtime or should that happen on the first call into the new bytecode segment? We could setup a dummy entry which generates JIT code and replace the entry with the real code then. Also implied is: * constant table is per code segment * fixup table too, and we build a global symbol table when loading these symbols, so we can find them in one place. * this should play together with threads. We have per thread data inside the bytecode segment (prederef and JIT code). Prederef code could use an addressing scheme like [interpreter + addr], which would be thread independent. For JIT this will not work easily. I'm thinking here of a code segment PMC which has some shared data and some thread local data. Next is: How do we actually call code in a different bytecode segment? Currently we fall out of the runloop, start/end/pc of the new code segment are set and then we restart there, at the desired address. This is for sure subotimal. > There's a bit more, but this is a good start. If people want to bat > this around some, we can put together a list in the repository and > start getting it implemented. Good idea. leo
