Xref: utzoo comp.lang.c:27000 comp.lang.misc:4503
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sco!seanf
From: seanf@sco.COM (Sean Fagan)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: function calls
Message-ID: <5237@scolex.sco.COM>
Date: 16 Mar 90 22:09:48 GMT
References: <1990Mar14.172152.25436@utzoo.uucp> <14268@lambda.UUCP>
Sender: news@sco.COM
Reply-To: seanf@sco.COM (Sean Fagan)
Organization: The Santa Cruz Operation, Inc.
Lines: 53


In article <14268@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>Most machines implement call/return with single instructions.  However, this
>tends to be the tip of the iceberg for procedure call overhead.  The interface
>_MUST_ do the following:

No, it must not.

>1) Save/restore all register values that are still 'live' values for the
>   caller.

What about callee saves?

>2) Test the stack to make sure there is enough room for the callee's local
>   variables (and call the memory manager for a new stack frame if there
>   wasn't room).

	sub	esp, 1000000

seems to work just fine here.  True, you will get into problems if you run
out of VM, or your stack-pointer wraps around, but I don't know of anyone
who checks for those.

>3) Create (on the stack) a traceback entry so the debugger and/or the
>   postmortem analyzer can find the current thread through the call tree.

It need not be on the stack.  Ever hear of saving the return address in a
register?  You know, like Cray's do?  You only have to save the retaddr when
you call another function.

>The problem is: _MOST_ of the procedure call
>overhead is concentrated in number (1)!  And, this overhead applies to all
>procedures - including 'leaf' routines.

True.  That's why register windows were considered a "good thing" (I'm not
sure I like them).  It's also one of the problems you have if you have
large, large amounts of registers (say, 256 anyone?).

>Because modern machines tend
>to have a _large_ number of registers, implementing (1) is usually quite
>expensive - and it can't be made cheaper without interprocedural analysis
>which in turn can't be done as long as separate compilation is possible.

Huh?  The MIPS compiler does interprocedural analysis, and I'm lead to
believe that the Pyramid compilers do as well.  It's not *easy* or cheap, to
be sure, but it can be done.

-- 

-----------------+
Sean Eric Fagan  | "Time has little to do with infinity and jelly donuts."
seanf@sco.COM    |    -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422   | Any opinions expressed are my own, not my employers'.