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]

pr**********@softhome.net (Praveen Kumar Madis) wrote:

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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Case]

Praveen Kumar Madis wrote:

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]

pr**********@softhome.net (Praveen Kumar Madis) writes:

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
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Dan Pop]

In <a3**************************@posting.google.com > pr**********@softhome.net (Praveen Kumar Madis) writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[red floyd]

Martin Dickopp <ex****************@zero-based.org> wrote in message news:<cu*************@zero-based.org>...

pr**********@softhome.net (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]

In <96************************@posting.google.com> re********@yahoo.com (red floyd) writes:

Martin Dickopp <ex****************@zero-based.org> wrote in message news:<cu*************@zero-based.org>...

pr**********@softhome.net (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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Kevin Bracey]

In message <c9**********@sunnews.cern.ch>
Da*****@cern.ch (Dan Pop) wrote:

In <96************************@posting.google.com> re********@yahoo.com (red floyd) writes:

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).

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).

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: [phone]
182-190 Newmarket Road Fax: [phone]
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/

[Dan Pop]

In <60****************@tematic.com> Kevin Bracey <ke**********@tematic.com> writes:

In message <c9**********@sunnews.cern.ch>
Da*****@cern.ch (Dan Pop) wrote:

In <96************************@posting.google.com> re********@yahoo.com (red floyd) writes:

>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).

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de