🚀 go-pugleaf

In article <898@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes:
>In article <1881@homxc.UUCP> dwc@homxc.UUCP writes:
>>In some other article someone else writes:
>>do compilers take the time to keep track of which registers have
>>been used and only save the 'dirty' ones or do most call and
>>return mechanisms save the entire register set on the stack?
>It depends on the architecture and the compiler, the three easy ways
>to do it are:
>	a) save all registers
>	b) have the caller save only the registers it is using
>	c) have the callee save only the registers it will use
>pdp-11's use "a" since they only have 3 register variables anyway.  Most
>68k compilers use "c" since you get about 12 register variables.  I don't
>know of anyone who uses "b" but it should be about as efficient as "c".
>

Actually b can be much less efficient than c, because the strategy in c
can conditionally save registers while b must save all which might be
used.  E.g., consider the routine

int foo(a)
struct foo_structure	*a;
{
	if (a) {
		/* long hairy computation which uses
		 * several register variables
		 */
	}
}
Using scheme b, all registers which MAY be used in foo MUST be saved,
while scheme c allows you to save registers only if a is non-null.
Guy Steele goes into this very well in an MIT Tech Report called
"Debunking the Expensive Procedure Call Myth" (Maybe.  This may be
the subtitle after a dry formal title.).  It's written in the context
of LISP compilers, but talks about compiling for register machines.
It also talks about tail recursion (something even C compiler writers
could probably learn from).  All in all, a good paper.

>The method used has a large effect on whether setjmp/longjmp can put the
>correct values back into register variables (SYSVID says they may be
>unpredictable :-(.

Sad, but true.  The non-orthogonality of "modern" machine design again
pokes through to bite the programmer.  So it goes.

Frank Adrian
Mentor Graphics, Inc.