Benjamin Stuhl wrote:
At 03:00 PM 1/22/2003 -0500, you wrote:
... Although,
all this would seem to suggest that we'd need/want a special-purpose allocator for bytecode segments, since every sub has to fit within precisely
one segment (and I know _I'd_ like to keep bytecode segments on their own memory pages, to e.g. maximize sharing on fork()).
IMHO this is a big waste of memory - and running this page aligned code JITted doesn't buy anything.
Design Edict #7: the compreg opcode will execute the compiled code, calling in with parrot's calling conventions. If it should return something, then it had darned well better build it and return it.
How does this play with
eval 'sub bar { change_foo(); } BEGIN { bar(); } (...stuff that depends on foo...)';
? The semantics of BEGIN{} would seem to require that bar be installed into the symbol table immediately... but then how do we reproduce that if we're e.g. loading
precompiled bytecode?
Precompiled PBC and eval is a PITA. This issue seems to imply some extra parsing during load time and setting up symbols. I dunno yet, how to handle this.
leo
