At 19:52 -0500 1/15/04, Melvin Smith wrote:At 04:26 PM 1/15/2004 -0700, Luke Palmer wrote: I can see some potential problems to solve with regards to some languages where variables are dynamic and can be "undefined", such as Perl6, but the optimization would certainly work for constants in all languages. The only problem with Perl6 would be if a global or package variable's address changed after it was stored in the register group at bytecode load time, (which could probably happen).
Which is very hard not to happen as soon as you get into Exporter land. ;-(
Well... sorta. A lot of that stuff's known at compile time.
Anytime we cache something dynamic, we have to make sure the caches know about changes. I think that is where notifications might help.
For constants it is easy. IMCC might say, "this routine requires us to intialize
at least 3 registers with a constant value, lets make it into a register block"
This may be a premature optimization, but for certain cases I think its pretty
nifty.
This smells like premature optimization to me for languages such as Perl[\d].
To some extent, yes. I just had a really nasty thought, and I think the compiler writers need to get Official Rulings on behavior.
With perl, for example, it's distinctly possible that this:
our $foo; # It's a global
$foo = 12;
if ($foo > 10) {
print $foo;
}will require fetching $foo's PMC out of the global namespace three times, once for each usage. I don't know offhand if this is how perl 5 works (I think it might be) and we should check for perl 6, python, and ruby. This is mainly because of the possibility of tied or overridden namespaces, which would argue for a refetch on each use.
*Not* refetching is a perfectly valid thing, and not specifying is also perfectly valid, but we need to check.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
