Angel Faus wrote:
I explained very badly. The issue is not spilling (at the parrot level)
The problem stays the same: spilling processors to parrot's or parrots to array.
[ ... ]
set I3, 1 add I3, I3, 1 print I3
fast_save I3, 1
set I3, 1
Above's "fast_save" is spilling at parrot register level and moving regs to parrot registers a processor regs level. Actual machine code could be:
mov 1, %eax # first write to a parrot register inc %eax # add I3, I3, 1 => (*) add I3, 1 => inc I3 mov %eax, I3 # store reg to parrot registers mem print I3 # print is external *) already done now
Above sequence of code wouldn't consume any mapped register - for the whole sequence originally shown.
So the final goal could be, to emit these load/stores too, which
then could be optimized to avoid duplicate loading/storing.
An even better goal would be to have imcc know how many temporaries every JITed op requires, and use this information during register allocation.
As shown above, yep.
All this is obviously machine dependent: the code generated should only run in the machine it was compiled for. So we should always keep the original imc code in case we copy the pbc file to another machine.
I'l answer this part in the reply to Nicholas reply.
-angel
leo
