At 11:33 AM +0200 6/13/03, Leopold Toetsch wrote:register windows
I'd rather not have the window, but...
Saving and restoring all the registers is obviously a waste of time in many cases.
This sentence seems to contradict pdd03 - not that's a waste but ... When it comes to return values they clearly clobber these values that the caller is obligued to save.
A typical return value sequence currently looks like
pushp P5 # return val restoreall popp Px
OTOH the callee has to preserve P0-P2, S0, I0. Other registers, mainly I1-I4 must be set on each sub return. The state of all other registers - at least according to calling conventions - has to be preserved.
... My assumption is that the compilers won't emit saveall/restoreall instructions unless they're really needed, and in most cases they won't be, so I think part of the timing's excessive.
The compiler can't decide on not to emit saveall/restoreall - we are talking here about Parrot calling conventions and the caller saves all.
The compiler may omit the saveall/restoreall on the last function call, *if* the compiler is really sure, that its calling really a leaf (If that returns with C<invoke> the compiler *doesn't* be sure).
Having said that, since the lower half of the register sets are parameters and shouldn't be restored over, it seems sensible that they shouldn't be saved over either.
This sounds very reasonable to me. But some of these registers must not get globbered by the callee either. This needs another - and please - very detailled update for pdd03. (And with separated parts with or w/o prototypes - Thanks)
Not a big deal--the only reason it's not done is it has Jit repercussions and I wanted you and Daniel to have a chance to bring up problems with the scheme before I went and broke the JIT.
No JIT involved currently AFAIK. IMCC is a much bigger problem here. The flow of registers in and out of suborutines has to be well defined to get register allocation done. At PASM level, where registers are fixed they are either mapped to an hardware processor register or not. Before function calls they have to be flushed to Parrot registers, because of exceptions and other interpreter weirdness like introspective possibilities.
Back to register windows for a minute:
Do you already have data structures in mind for multi threading? The registers are for sure separated per thread. So the extra pointer for the register window or something similar would be needed anyway.
leo
