At 9:55 AM -0800 2/20/03, Steve Fink wrote:
I think this has been discussd before, but are we all okay with this
callee-save-everything policy?

Nope. It's safe to say that a lot of folks aren't. :)


Still, I think it's the right way to go in the general case. Most sub calls of any complexity will be saving off all the I and P registers (at least, probably the S registers too) that I don't see it saving anything except in the trivial leaf sub case. Which, I realize, is common for some styles of programming, but those aren't the styles that people use with perl/python/ruby generally.

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.

Faster in a number of ways. I considered the bitmask, but then you have the issue of lots of bit tests which isn't cheap in software. (Hardware yes, but we don't have that on our side) Besides that, doing a simple bit-blast is hardware accelerated on many systems, and cache friendly on others, which makes it a better option overall.


At one point I did a test and found that whole-register-frame saves were faster than saving three individual registers in a frame, though we do have a relatively heavy-weight general purpose stack.

Taking that farther, I've always liked systems that divide up the
registers into callee-save, caller-save, and scratch (nobody-save?)
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")

I can see doing this. If there was some sort of metainformation that would allow us to know at compile time that registers were safe we could emit different code, though there's still the issue of nested calls where there's limited info.


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.

Yeah, 32 is a bunch. I've considered going with 16 on and off, and still might. -- Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to