At 7:09 PM +0100 10/27/02, Leopold Toetsch wrote:
So the I-register access is substituted by access to 3 global integers.
Now, how would these globals be loaded? When are these »arg« OPs inserted?
Currently the register optimizer in jit.c does something very
similar: Setting up register access for the most used parrot
registers in one execution block + load and store add block
begin/end.
This is definitely a Clever Thing, and one I've pondered on and off.
It will definitely speed up some things, as there's less bytecode to
chew through, there's more of a chance for optimization by the C
compiler when parrot's being built, and generally more opportunity to
cheat.
I'm currently leaning against it only because it doesn't ultimately
help the JIT. What we have now is wildly cool and damn useful (and
has anyone heard from Daniel lately, BTW?) but there's room for more
optimizations.
Specifically, since the interpreter struct address is fixed, the
bytecode is fixed at JIT time, and the JIT is allowed to make
interpreter-private JITted versions of bytecode, it means that the
JIT already has license to take things a step beyond what you're
looking for--since the registers are at a fixed address and the
bytecode is fixed, the JIT can produce a stream of executable code
that directly addresses data, which is what the micro-ops are meant
to do.
Now, on the other hand it *does* speed up the interpreter, so it's
definitely not an idea to discard. But if we're going to (and I'd
still like to hold off) I think we're better off with a few special
versions of ops that target one or twi registers directly, perhaps
register 0 and 1, rather than have a separate set of special-purpose
registers.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
