Re: C function return value?

From: Chris Torek (nospam_at_torek.net)
Date: 12/29/03


Date: 29 Dec 2003 03:22:12 GMT

In article <news:Pine.SOL.4.56.0312282139360.19311@hadar.cse.Buffalo.EDU>
Ravindranath Gummadidala <rg27@cse.buffalo.edu> writes:
>I am trying to understand the C function call mechanism. Please bear with
>me as I state what I know:
>
>"every invocation of a function causes a frame for that function to be
>pushed on stack. this contains the arguments this function was called
>with, address to return to after return from this function (the location
>in the previous stack frame), location of previous frame on stack (base or
>start of this frame) and local variables of this function"

This is *a* method. It is not *the* method. Different C compilers
use different methods. (In particular, one common technique in
use today is not to have the parameters and return-address on any
stack at all, nor to have separate stack and frame pointers. If
the return address is in a register -- as done by the hardware on
MIPS and SPARC and PowerPC, for instance -- then leaf functions,
i.e., functions that do not call other functions, can just leave
it there and "return" using a jump-register instruction. If all
its local variables fit in any registers left over after accounting
for parameter registers, a leaf function often needs no memory at
all!)

>my question is how is a value returned from this function.

In a machine- and/or compiler-specific manner.

Three common techniques are to put the return values into registers,
or to return pointers to the return values (again often in registers),
or to have the caller pass, as "hidden" extra arguments, pointers
to the places the return values should go.

If you want to learn the method for a particular machine and/or
compiler, consult the appropriate documentation (if any) or newsgroup
(if any), or read the compiled code or the compiler code. Note
that information gleaned via the latter two methods (reverse
engineering) is often "subject to change without notice".

-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.


Relevant Pages

  • Re: LPC900/80C51 Compiler Toolchain
    ... Although the fixed-size frame optimization is orthogonal to removing ... storing stack arguments is less important in such cases. ... storing data at (SP + offset) takes exactly the same time ... up and uses up another 2 registers. ...
    (comp.arch.embedded)
  • Mails stack up in incoming folder
    ... Registers: ... Call stack ... Address Frame ... no events in event viewer. ...
    (microsoft.public.backoffice.smallbiz2000)
  • Re: Memory Operand Performance
    ... they are passed in registers AND space is reserved for them in the stack ... had they been passed on the stack. ... the stack frame). ...
    (comp.lang.asm.x86)
  • pop connector craching?
    ... Registers: ... Call stack: ... Address Frame ... This happens at random times for no apparent reason i have ...
    (microsoft.public.exchange2000.win2000)
  • Re: Statement on Schildt submitted to wikipedia today
    ... you discover that Schildt was libeled. ... It turns out that, on this particular architecture, some registers are saved ... The problem is, even though indeed this implementation has "a stack", if you ... end up adjacent to one of our newest automatic variables. ...
    (comp.lang.c.moderated)