Xref: utzoo comp.lang.c:26942 comp.lang.misc:4469
Path: utzoo!attcan!uunet!cs.utexas.edu!rice!titan!preston
From: preston@titan.rice.edu (Preston Briggs)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <5790@brazos.Rice.edu>
Date: 15 Mar 90 19:31:21 GMT
References: <1990Mar14.172152.25436@utzoo.uucp> <14268@lambda.UUCP> <1990Mar15.173408.29622@utzoo.uucp>
Sender: root@rice.edu
Followup-To: comp.lang.c
Organization: Rice University, Houston
Lines: 31

In article <1990Mar15.173408.29622@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <14268@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:

>>1) Save/restore all register values that are still 'live' values for the
>>   caller.  ...  The problem is: _MOST_ of the procedure call
>>overhead is concentrated in number (1)!  

>The correct statement is that the callee must save/restore all register
>values that are still live for the caller *and that the callee is going
>to overwrite*.  Careful register-allocation conventions (with an adequate
>supply of registers) can minimize that number, usually to zero in the case
>of leaf functions.

And of course there are register windows of various kinds.

They don't solve the register allocation problem, but they
do help reduce call overhead, at some expense to task
switching overhead (but we know which is more common).

On the other hand, Wall argues that link-time register
allocation can surpass register-window performance.
See his paper

	Register Windows vs. Register Allocation
	D. W. Wall
	Proceedings of the SIGPLAN '88 Conference on
		Programming Language Design and Implementation

--
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu