> I would expect a large majority of parrot subroutines to > *not* use all four register types. > > How difficult would it be to make imcc detect when less than 4 > register types were used in a subroutine, and replace a call to > "saveall" with an appropriate combination of "pushi", "pushs", > "pushp", and "pushn" (and likewise with "restoreall")? I've been > looking at the optomizer, and it hurts my head to try and understand > it. > > Perhaps more importantly, could continuations be made to *not* > save/restore all four register types, and instead only save/restore > those types that we ask it to save/restore?
There is value in implementing your proposal even ahead of imcc support, as hand-written code can already take advantage of it.
One would, presumably, write an opcode like this (modifying a shameless cut-and-paste from core.ops):
#define FILE_I (1<<0) #define FILE_N (1<<1) #define FILE_S (1<<2) #define FILE_P (1<<3) /* #define FILE_L (1<<4) ;-) */
inline op savesome(in INT) {
if ($1 & FILE_I)
Parrot_push_i(interpreter);
if ($1 & FILE_N)
Parrot_push_n(interpreter);
if ($1 & FILE_S)
Parrot_push_s(interpreter);
if ($1 & FILE_P)
Parrot_push_p(interpreter);
goto NEXT();
}And similarly for restoring. But how much work is in imcc, only the imcc lord can say. And it may not be possible to automate the use of partial saves all the time, but what do I know?
[As a bit of related info, known already to some, for sure: there is at least one processor which has a bit in a control register, bit which is set each time a register in an architecturally-visible register file is modified. The program saves the register file contents upon entering and restores it only if the 'modified' bit is set. Otherwise just moves the head.
The difference is that the hardware can do all the tracking in parallel to the regular operation; a software equivalent will have to execute code in every set-like operation.]
Flaviu
