Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: A note for those not consumed by efficiency worries (was: function calls)
Message-ID: <14287@lambda.UUCP>
Date: 23 Mar 90 01:25:05 GMT
References: <5940024@hpcupt1.HP.COM>
Lines: 24

From article <5940024@hpcupt1.HP.COM>, by jamiller@hpcupt1.HP.COM (Jim Miller):
> [...]
> The dividing up the registers into mine and yours is not necessarily
> as bad as you think, there are lots of registers that get set for
> temporary values which do not need to be preserved across procedure
> calls.  If the compiler is clever, guess which registers get used for
> the temporary values?  

Well, the first N temporary values anyway.  Meanwhile, the caller had
to save all the values that _it_ had stored in those registers before
it could call the procedure.  I have yet to come across a high-level
language which made good use of the registers AND had a fast procedure
call mechanism.

By the way, in general, it's better for a compiler to make good use
of the registers and then pay high procedure-call overhead: the user then
has some degree of control (he CAN 'inline' any critical procedures).
If the compiler makes bad use of the register set, there is nothing the
user can do about it.

But, one way or another, you pay for procedure calls in implementations
which don't have extensive interprocedural analysis built-in.

J. Giles