Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >> Dan Sugalski <[EMAIL PROTECTED]> writes: > >>>There are ways to get around that, and there are some inefficiencies >>>in the implementation there. I think we can work around some of >>>those--I am rather tempted to have invoke promise not to alter >>>non-parameter registers or something so you don't have to pushall >>>every time you make a call to what could be assumed to be an atomic >>>and non-parrot function. > >> Doesn't that rather invalidate the whole 'caller saves' principle? > > > The 'caller save' principle is IMHO subotimal. The caller doesn't > know, how a sub is implemented, so has always to save everything. > When the called sub is responsible for preserving the environment, > only a minimal set of needed registers can be saved in the sub.
Whichever style you choose will be suboptimal. However, if you move to callee saves you lose the possibility of adding tail call optimization at a later date, and some subs will end up saving registers that don't need saving. (I also wonder how continuations are going to work with callee saves since the continuation needs to get the register set back into a sane state and it gets created at call time.) I coness I'm somewhat bemused to see any sub doing 'save all', a given sub knows which registers it uses, and they are the only ones that it needs to save (because it's callers have already saved anything that's important to them). > I would vote for above "non-parameter registers are preserved". > > BTW imcc needs some extensions: > - subroutine return values in registers are OUT params WRT the invoke > call, which imcc isn't aware of > - popX/clearX/restoreall do change registers, though this isn't > flagged in the opcode. > > imcc assumes, that all registers are preserved over function calls. Looks like IMCC needs fixing.
