On Feb-18, Leopold Toetsch wrote:
[ ... ]
.return mi # [1] restoreall ret .end
My immediate reaction to this (okay, I really saw this before in perl6-generated code) is "why don't the values from .return and restoreall get mixed up?"
Yep. It is at least confusing at the beginning.
You may want to add a brief description of the kazillion different stacks that Parrot uses. There are six, I think:
7 if you count the intstack too.
I think this has been discussd before, but are we all okay with this
callee-save-everything policy?
I'm not that convinced of it - I still think the subroutine knows best, how to preserve its registers.
... At the very least, I'd be tempted to
add a bitmasked saveall/restoreall pair to reduce the amount of cache
thrashing. ("saveall 0b00100110111111110000000000000000") It just
seems odd that you have to either save all 32 of one of the types of
registers, or to save selected ones onto a different stack. But it
*is* simpler to copy over the entire register file to a stack frame, I
guess.
Probably yes.
Taking that farther, I've always liked systems that divide up the registers into callee-save, caller-save, and scratch (nobody-save?)
Register windows, like (AFAIK) IA64 has? This would avoid a lot of saveall/restoreall/saveX/restoreX for smaller subroutines.
Maybe that's just me. And I vaguelly recall that there was some discussion I didn't follow about how that interferes with tail-call optimization. (To me, "tail call optimization" == "replace recursive call with a goto to the end of the function preamble")
Dan did mention it, when arguing for callee-save calling coventions. But I don't know how it exactly works.
Or, as another stab at the same problem, does Parrot really need 32*4 registers? I keep thinking we might be better off with 16 of each type. But maybe I'm just grumbling.
I think 16 might be not enough. So the current setting is ok.
leo
