At 12:05 PM +0200 6/22/03, Leopold Toetsch wrote:
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.Dan Sugalski wrote: *) Global namespace pointer
Fine. Then we just need to save the linx chain and reset it to the saved end-pointer or so, *if* that sub does use globals.
*) Opcode functionThis 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.
Ok. Then please have (again) a look at my proposal:
Subject: [RfC] a scheme for core.ops extending
Date: Wed, 05 Feb 2003 12:28:21 +0100
This basically does extend loaded opfunc tables. Existing tables are still valid. A core func table would provide basic functionality and adding e.g. math.ops or trig.ops would append these. The added functions get just an offset depending on the load sequence - no absoult values. This of cource requires that assembler and runtime are in sync of the modules that require new oplibs. But IMHO we do need such behavior anyway for Perl6 so that e.g. BEGIN and runtime are in sync.
(If archives dont have the attached proof of concept I can repost it)
Anyway I think, this would make saving/resetting opfunc tables an operation of storing the current highest opcode number.
*) Current bytecode segment pointer
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.
Could be a first - and already longer proposed - step: just move languages/imcc into $root/imcc and s/imcc/parrot/ + some Makefile and test hacks.
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.*) Warnings, since warnings are lexically scopedYep. Is there any reason that the warning flags are malloced instead of using an UINTVAL?
Albeit most of the warning will come out of $perl6-parser, this is might for sure happen. Shouldn't be to expensive, to setup a warnings structure once per new callee and (eventually if the sub messes with the flags) update the area at invoke time.
leo
