Dan Sugalski wrote: *) Global namespace pointer
This would require a new opcode e.g. B<new_global_table Sx> to be useful. Also the global table handling as of pdd06 is missing. This global table stuff in pdd06 looks like we need a hash of hashes for the globals. Saving such a HoH seems rather expensive, we don't have COW hashes, so, with current data structures this would be a nested hash_clone() call.
We don't so much need a hash of hashes as a linked list of hashes. And yeah, it'll definitely have a performance impact on global lookups.
*) Opcode function table because we may have different opcode functions in the new sub
This probably can wait some time.
I'm of two minds on this one--on the one hand I agree that we don't need it now. On the other, I'm concerned that if we don't have it in now we'll do something that makes it very difficult later.
*) Current bytecode segment pointer since we may be entering a new bytecode segment with a new constant table and such
Needs still some work in the packfile code, which currently is some PITA because of the compat stuff for assemble.pl Either we toss it or it has to use pack*.c.
I'd be perfectly happy to see assemble.pl go and have parrot itself be capable of generating bytecode from input assembly.
*) Interp flags (maybe, I'm not sure)
Changing run cores needs restart opcodes. Just restoring the flags isn't very useful.
Fair enough. Scratch that one from the list.
*) Warnings, since warnings are lexically scoped
Yep. Is there any reason that the warning flags are malloced instead of using an UINTVAL?
I think this is in part a result of the experiences we had with perl's warnings. Warnings and warning classes multiply at an amazing rate, and it's pretty easy to blow through a UINTVAL's worth of bits.
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
