On Feb-18, Leopold Toetsch wrote:
> =head1 Stack calling conventions
> 
> Arguments are B<save>d in reverse order onto the user stack:
> 
>    .arg y     # save args in reversed order
>    .arg x
>    call _foo  #(r, s) = _foo(x,y)
>    .local int r
>    .local int s
>    .result s  # restore results in reversed order
>    .result r  # [1]
> 
> and return values are B<restore>d in reversed order from there.
> 
> The subroutine is responsible for preserving registers.
> 
>  .sub _foo            # sub foo(int a, int b)
>    saveall
>    .param int a
>    .param int b
>    ...
> 
>    .return pl         # return (pl, mi)
>    .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?"

You may want to add a brief description of the kazillion different
stacks that Parrot uses. There are six, I think:

1. The user stack -- holds a stack of unions, so entries can be
   int/float/pmc/string
2. The control stack -- holds return addresses
3. The int register stack -- holds frames of 32 ints each
4. The float register stack
5. The string register stack
6. The pmc register stack

I think this has been discussd before, but are we all okay with this
callee-save-everything policy? 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.

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")

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.

[It's nice to have a net connection again!]

Reply via email to