Michael -- > I'm of the opinion that you shouldn't just be able to jump into > another code-segment.
I agree. Since in the future, different chunks of code could be compiled with different oplibs, the opfunc and opinfo lookups will have to move to be close to the bytecode stream, not part of the interpreter proper (although the interpreter may cache them to save indirections). That implies that when we call out to a noncontiguous block of code, we have to point interpreter->code at it, and probably re-cache the opfunc and opinfo tables. So, *all* non-special jumps have to be relative to the current code chunk, which means that jumpabs_ic 1 should mean to set PC to interpreter->code->byte_code + 1 I would imagine it only makes sense to jump into another code chunk at the location of an exported symbol, so once we can have linkage information in the packfile format, we can allow the loader to do the fixups, and we end up with something like call_ic FOO # Implicit local code block call_ic_ic MATH, WHATEVER # Explicit code block and the call stack saves both the 'code' identifier (index, or whatever) and the return address within that code. > Given that modulaA will have interp->code range from say 28M to 28.4M, moduleB > will have interp->code range from 41.4M to 42.2M, etc - Where-ever mmap > assigns the address. It would therefore be almost impossible to map PC to > a linear physical address. Yeah. You'd have to contrive to concat them into one big chunk, which defeats mmapping on systems that have it. Although, there might be some mmap defeating going on anyway for vivifying constants. We might be able to handle some constants with special versions of their implementations that know not to do reallocations (CONST_STRING, anyone?) and expect to use placement initialization (although we probably still can't get away with that with a platform neutral format. shucks). So, mmapping is nice, but we are still going to have to use it more like a source of init arguments for some things than as a backing store (that's not to say that it can't be backing store for immutable chunks of bytecode). Regards, -- Gregor _____________________________________________________________________ / perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \ Gregor N. Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/ 8080 Beckett Center Drive #203 513-860-3570 vox West Chester, OH 45069 513-860-3579 fax \_____________________________________________________________________/
