Memory allocation for function paramaters

[Praveen Kumar Madis]

Hi

Can anybody tell me, where memory will be allocated for Function
parameters and return value of a function.
Are these stored on stack area, or data area, or any where else.

Reg
Praveen

 

[Irrwahn Grausewitz]

Hi

Can anybody tell me, where memory will be allocated for Function
parameters

From the C Standard POV function parameters behave just like ordinary
automatic variables with function scope.

and return value of a function.
Are these stored on stack area, or data area, or any where else.

Yes. No. Neither. Both. Depends.

<OT>
On some (most?) typical implementations return values will be passed
by stack or register. However, this is beyond the scope of the C
language definition and hence OT in comp.lang.c.
</OT>

Regards

 

[Case]

Hi

Can anybody tell me, where memory will be allocated for Function
parameters and return value of a function.
Are these stored on stack area, or data area, or any where else.

C implementations have a lot of freedom in this area. On many
implementations/platforms, function parameters are passed in a
defined set of registers and if the registers are for some reason
not enough, the stack is used (as well). The same for return
value: often a register but the stack is used for this as well.

I said 'implementations/platforms' because in many cases the C
implementation is not (fully) free to choose which registers to
use; this because the platform (i.e., the operating system or even
the CPU design) has certain rules as well. Using the same rules
on a platform also makes linking modules written in different
programming languages easier/possible; of course when all compiler
adhere to the same or compatible rules.

As a portable C programmer you don't need to know how and where,
and that's a great thing about this language!

Case

 

[Martin Dickopp]

Can anybody tell me, where memory will be allocated for Function
parameters and return value of a function.
Are these stored on stack area, or data area, or any where else.

The C language standard doesn't say how the values of the arguments are
transferred to a function, or how the return value is transferred back,
so it's up to the implementation to decide. There is no requirement
that a stack even exists.

That said, most implementations do indeed use a stack for this, often
in combination with CPU registers. If you're interested how your
particular implementation handles it, please ask in a newsgroup
dedicated to that implemenation.

Martin

 

[Dan Pop]

Can anybody tell me, where memory will be allocated for Function
parameters and return value of a function.
Are these stored on stack area, or data area, or any where else.

Function parameters are allocated the same way as function automatic
variables, regardless of the mechanism used for passing their values
from the caller.

The return value of a function need not be stored anywhere, except in a
machine register. If it doesn't fit in one or more registers, it is up to
the compiler to decide where to store it, so that the caller can retrieve
it.

But the qood question is: why do you care about these issues? Portable C
code (the only kind of code we normally discuss here) is not affected in
any way by them.

Dan

 

[red floyd]

(e-mail address removed) (Praveen Kumar Madis) writes:
[Q about where parameters live redacted]

That said, most implementations do indeed use a stack for this, often
in combination with CPU registers. If you're interested how your
particular implementation handles it, please ask in a newsgroup
dedicated to that implemenation.

The Zilog ZEUS Z8000 compiler passed the first 6 16 bit arguments in
registers (R7-R1, descending), and thereafter on the stack.

Made the implementation of <vararg.h> (this was pre-C89) kind of a
pain in the butt!

 

[Dan Pop]

(e-mail address removed) (Praveen Kumar Madis) writes:
[Q about where parameters live redacted]

That said, most implementations do indeed use a stack for this, often
in combination with CPU registers. If you're interested how your
particular implementation handles it, please ask in a newsgroup
dedicated to that implemenation.

The Zilog ZEUS Z8000 compiler passed the first 6 16 bit arguments in
registers (R7-R1, descending), and thereafter on the stack.

Made the implementation of <vararg.h> (this was pre-C89) kind of a
pain in the butt!

This kind of convention (first N arguments in registers, the rest on the
stack) is commonplace on modern architectures. Never bothered to see
how <stdarg.h> is actually implemented (probably using compiler magic).

Dan

 

[Kevin Bracey]

This kind of convention (first N arguments in registers, the rest on the
stack) is commonplace on modern architectures. Never bothered to see
how <stdarg.h> is actually implemented (probably using compiler magic).

Simplest thing to do is often for the compiled function entry sequence to
push the argument registers onto the stack if any of their addresses are
taken by the C code in the body. Then a bog-standard <stdarg.h> will just
work.

Alternatively, arguments might not get passed in registers for variadic
functions (possible because variadic functions must be prototyped).

 

[Dan Pop]

In message <[email protected]>


Simplest thing to do is often for the compiled function entry sequence to
push the argument registers onto the stack if any of their addresses are
taken by the C code in the body. Then a bog-standard <stdarg.h> will just
work.

Alternatively, arguments might not get passed in registers for variadic
functions (possible because variadic functions must be prototyped).

This alternative approach is avoided in practice by most implementors,
although perfectly allowed by the standard: far too many (clueless)
people call printf/scanf without including <stdio.h> and the implementors
don't want to get complaints from them ;-)

Dan