Xref: utzoo comp.lang.c:26983 comp.lang.misc:4491
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <14273@lambda.UUCP>
Date: 16 Mar 90 21:15:32 GMT
References: <29509@amdcad.AMD.COM>
Lines: 33

From article <29509@amdcad.AMD.COM>, by tim@nucleus.amd.com (Tim Olson):
> [...]
> If you partition your registers into a set that is live across a
> function call and a set that is killed, then leaf routines can run
> entirely out of the later set, not having to save any registers.  For
> example, in the Am29000 calling-convention, a function can allocate up
> to 126 local registers which are saved across function calls and
> also has use of 24 "temporary" registers which are not.  Most leaf
> routines can run entirely out of these 24 temps.  The entire overhead
> is simply a call instruction and a return instruction (2 cycles if the
> delay slots are filled).

It seems to me that if a procedure is so small that it can only find
use for 24 (or fewer) registers, then it is small enough to be a real
good candidate for inlining.  Clearly, _any_ procedure can be written
only _use_ 24 registers (there were some machines in the past with only
_one_ register - the were completely functional).  However, most procedures
of any size can benefit from quite a few more registers than 24.

Similarly, any 'caller' routine that can afford to leave 24 registers
unused is fairly small as well.  For efficiency, all 'live' values
should be kept in registers if at all possible.  The problem is that
any large program (and some small ones) have quite a large number of
'live' values.  Procedures that manupulate arrays may have whole
arrays (or array sections) that are 'live'.   If there's _room_ in
the register set for all these values, that's where they should be
kept.

The fact is that this kind of 'temp' register idea only _appears_
to save time.  You probably actually lose performance by forcing
many of your 'live' values to memory when they needn't have been.

J. Giles