I don't see that.... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here.
My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed into a PMC.
There are 32 registers per type. When life analysis of all used temporary registers, can't allocate all used vars to a parrot register, then overflowed vars get spilled into a PerlArray.
This may be different to just "a block needs more than...":
set $I0, 10
add $11, $I0, 2
print $I1
add $12, $I0, 3
print $I2
only needs two registers, $11 and $I2 get the same parrot register, because their usage doesn't overlap.
But with a processor with > 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT.
RISC processor have a lot of them. But before there are unused processor registers, we will allocate P and S registers too. When a CPU has more then 4*32 free registers, we will look again.
Thanks, Phil
leo
