Front page | perl.perl6.internals |
Postings from October 2001
Re: Fetching the PC?
From: Gregor N. Purdy
October 12, 2001 13:29
Re: Fetching the PC?
Message ID: firstname.lastname@example.org
> 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
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy email@example.com
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax