At 12:09 PM 4/29/2002 +1000, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
>
> > I don't think I and Andrew were saying we shouldn't do caller-save, we
> > were just discussing that the calling convention (read activation record of
> > a subroutine) should support the common optimization of passing args
> > in scratch registers when it might make sense. Having scratch registers
> > and/or allowing passing in registers says nothing about whether you can
> > implement co-routines or continuations how you see fit nor whether
> > a caller saves its environment correctly or not.
>
>Actually, I _was_ saying we shouldn't do caller-save (except possibly
>for a small number of registers designated for the purpose).
>
>Because of the principle that callees are responsible for pretty much
>everything, I had assumed that they were to be responsible for saving
>registers too.  (Sorry Dan for not noticing your previous
>pronouncements on the matter.)
>
>My main reason for objecting is that it slows down trivial leaf subs,
>which are very common in OO programming.  Ideally neither the caller
>nor the callee should need to save registers when calling such a sub.
>
>I also can't see that it speeds anything up in the case of non-trivial/
>non-leaf subs.  If the caller isn't trivial, it will still have to save
>lots of registers, so it really doesn't matter who does it.
>
>There's got to be a reason for making caller-save the default, but I
>can't think of it. :-)

Ok, agreed. Sorry for speaking for you.

Regarding performance, a decent compiler should be able to
analyze a method to see if any register saving is needed at all,
so, even though the convention says "caller save" it doesn't
force you to save if you don't want or need to. Right?

This is true for a method where you have this info at compile time.
For leaf subs that are so simple, wouldn't a decent compiler skip
the call altogether and generate an inline? Then the convention is moot.

-Melvin

Reply via email to