I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an instruction or other annotation which
denotes what registers are live at some point in the code. The
Does it have to be in the instruction stream to be useful? Why not just
be part of the constants /fixup segment. This way non-JIT execution won't
require wasted op-execution (which we're devilishly trying to pre-maturely
optimize :). You could profile things via perl6-code attributes which
give clues to an optimizer or JIT (such as frequency of use, etc). In any
case, I can't imagine that a JIT compiler is expected to quickly execute.
What you have suggested is summary code, which can be determined at JIT
compilation time. I'm not convinced that the waste of CPU for invocation
of op-codes that aren't used in non-JIT form (which is the case when you
know you're only going to run this once) is justified for such simplistic
information.
However, a similar idea of live-registers exists on newer
CPU-architecture. Namely mapping how many registers need to survive the
subroutine call. The block, in turn, specifies how many it will use
within it's block. The CPU then frees non-maintained registers and
allocates just enough. The IA64 does something along these lines.
Here, however, we're not starved for register space; We're utilizing
multiple stack-streams. The beginning of a block simply allocates new
stack space on whichever stacks it requires. The only optimization in
this manner is to have the caller specify if it has used less than the
full compliment (or 32 or so), which would allow the potential
stack-allocation to save a block of 8, 16 or 24 registers (useful when
only 8 are used.. This also rewards compiler optimizatios which reuse
registers; which has cache rewards as well). Namely:
general-op
general-op
keep_int_regs %16
jsr _foo_func
general-op
_foo_func:
push_int_regs // only shifts reg-stack by 16 (properly handles over-flow)
push_num_regs // shifts a full 32
general-ops
...
pop_num_regs // shifts back 32
pop_int_regs // remembered to shift back only 16
ret
Unfortunately this trades off memory savings for extra CPU overhead. You
have to maintain a seperate shift-stack which says how much to shift
each time you do a push/pop. The current shift-value is set via the
new op-code keep_x_regs which also introduces over-head.
I personally would like to see smaller subroutines and more of them, but I
don't know that we're really going to be wasting a whole hell of a lot of
stack-space. At least not enough to be worth the CPU-overhead.
In general, if the hint-information is useful for non-JIT execution as
well, then I'd recommend it, but I'm not seeing this particular point as
being worth the cost.
-Michael
