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. ;-( For example:
use Scalar::Util qw(blessed weaken reftype); use POSIX;
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].
The number of times a variable occurs in a program, may have _no_ relation to how many times it will be accessed. So what's the optimization then?
If you're thinking about this, then maybe a better heuristic would be to group globals into groups that are _only_ referenced within a specific scope and fetch them on scope entry and store them on scope exit. But then, anything like eval"" or the equivalent of a glob assignment (or even worse: an event) within that scope, will cause problems.
But please, people around me always tell me that I'm way too negative. That I'm always saying why things _can't_ happen. I'd like to be proven wrong... ;-)
Liz
