Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13871 > unrolled thread

Variables allocated on stack

Back to article view | Back to comp.lang.c

Contents

  Variables allocated on stack Bogdan <cristeab@gmail.com> - 2011-11-24 13:28 -0800
    Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-25 10:40 +1300
    Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-24 23:30 +0100
      Re: Variables allocated on stack Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-12-02 22:33 +0000
        Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-12-03 00:54 +0100
        Re: Variables allocated on stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-02 23:33 -0800
          Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-12-03 02:25 -0800
    Re: Variables allocated on stack jt@toerring.de (Jens Thoms Toerring) - 2011-11-24 23:37 +0000
    Re: Variables allocated on stack Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-25 01:53 -0800
      Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-25 11:05 +0000
        Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-25 12:11 +0100
          Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-25 11:40 +0000
            Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-25 12:52 +0100
              Re: Variables allocated on stack Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-27 02:31 -0800
                Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 13:28 +0100
                Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 13:44 +0100
                  Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 15:44 +0100
                    Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 17:34 +0100
                      Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-27 18:28 +0100
                        Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-28 07:48 +1300
                          Re: Variables allocated on stack gwowen <gwowen@gmail.com> - 2011-11-29 01:11 -0800
                            Re: Variables allocated on stack jacob navia <jacob@spamsink.net> - 2011-11-29 17:02 +0100
            Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
              Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 11:07 +0000
                Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-26 21:16 +0100
                  Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 23:00 +0000
                    Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 12:12 +1300
                      Re: Variables allocated on stack "BartC" <bc@freeuk.com> - 2011-11-26 23:35 +0000
                        Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 12:48 +1300
                        Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-27 10:56 +0100
                          Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-11-28 16:17 -0800
                            Re: Variables allocated on stack Markus Wichmann <nullplan@gmx.net> - 2011-11-30 17:04 +0100
                              Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2011-11-30 09:36 -0800
                                Re: Variables allocated on stack Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 05:11 -0800
                                  Re: Variables allocated on stack Keith Thompson <kst-u@mib.org> - 2012-01-25 12:23 -0800
                                    Re: Variables allocated on stack Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 19:11 -0800
                      Re: Variables allocated on stack Ian Collins <ian-news@hotmail.com> - 2011-11-27 13:06 +1300
                  Re: Variables allocated on stack André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 11:20 +0100
                    Re: Variables allocated on stack David Thompson <dave.thompson2@verizon.net> - 2012-01-19 02:43 -0500
                Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-28 08:32 +0000
      Re: Variables allocated on stack Bogdan <cristeab@gmail.com> - 2011-11-26 01:18 -0800
        Re: Variables allocated on stack Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-26 08:36 -0500
    Re: Variables allocated on stack Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
    Re: Variables allocated on stack Noob <root@127.0.0.1> - 2011-11-29 11:51 +0100

Page 1 of 3  [1] 2 3  Next page →

#13871 — Variables allocated on stack

Hi

 I had during an interview this question: which variables are
allocated on the stack in a function ? I am unsure how the output
variable is handled. Is this one too allocated on the stack and popped
when the function exists ?
Here is an example:

char* some_function(char c)
{
     char *out = malloc(10);
     return out;
}

On the local stack are there one char and 2 pointers to chars ?

Bogdan

[toc] | [next] | [standalone]

#13872

On 11/25/11 10:28 AM, Bogdan wrote:
> Hi
>
>   I had during an interview this question: which variables are
> allocated on the stack in a function ? I am unsure how the output
> variable is handled. Is this one too allocated on the stack and popped
> when the function exists ?
> Here is an example:
>
> char* some_function(char c)
> {
>       char *out = malloc(10);
>       return out;
> }
>
> On the local stack are there one char and 2 pointers to chars ?

The question was bogus, either trick or the interviewer had a rather 
myopic viewpoint.

There isn't a correct answer.  On some machines (that do have a stack), 
nothing will be on the stack.  Both an and out will be in registers.

Then there machines that don't have a stack....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13875

Le 24/11/11 22:28, Bogdan a écrit :
> Hi
>
>   I had during an interview this question: which variables are
> allocated on the stack in a function ? I am unsure how the output
> variable is handled. Is this one too allocated on the stack and popped
> when the function exists ?
> Here is an example:
>
> char* some_function(char c)
> {
>       char *out = malloc(10);
>       return out;
> }
>
> On the local stack are there one char and 2 pointers to chars ?
>
> Bogdan

Conceptually a function has a stack that holds argument's values
and local variables. In your example the "c" argument and the
"out" pointer are in that stack.

The return value is normally in a register but it can be also
be understood as a stack.

In your example, a register would hold the value of the "out" pointer
after the execution of the function.

Today in a normal x86 based PC (linux, macintosh or windows) the first
parts of the execution stack are held in register, which one variying
with the calling conventions of the operating systems in question.

Under windows, the first 4 arguments are held in registers, under linux
or macintosh the first 7 arguments go into registers, when possible.

Do not forget that some arguments never go into registers because
they are too big for them. For instance, when you have a 476 byte
structure and you pass it by value the value goes into the stack
even if maybe the first 128 bytes would fit into a series of registers.

Depending on the specific machine architecture, some types have a
preferred set of registers where they are passed to functions, instead 
of the general purpose registers. Specifically double/long double values
go into the xmm or the FPU registers (in a x86 CPU) or into the FP unit
(Power PC) etc.

What needs to be retained is that C implies (because it accepts 
recursive functions) a stack like organization of the activation frames
of each function.

[toc] | [prev] | [next] | [standalone]

#14245

On Thu, 24 Nov 2011 23:30:36 +0100, jacob navia wrote:
> What needs to be retained is that C implies (because it accepts
> recursive functions) a stack like organization of the activation frames
> of each function.

Sorry, but this is extremely misleading. C can and does run on 
implementations with no stack. Although the C standard states in general 
terms that "recursion function calls shall be permitted", the 
"environmental limits" section places no constraints whatsoever on the 
depth of recursion that a C implementation is required to support. So it 
is perfectly acceptable to store the current hierarchy of function calls 
in a fixed length list buffer, with NO notion of a stack growing and 
shrinking.

[toc] | [prev] | [next] | [standalone]

#14251

Le 02/12/11 23:33, Quentin Pope a écrit :
> On Thu, 24 Nov 2011 23:30:36 +0100, jacob navia wrote:
>> What needs to be retained is that C implies (because it accepts
>> recursive functions) a stack like organization of the activation frames
>> of each function.
>
> Sorry, but this is extremely misleading. C can and does run on
> implementations with no stack. Although the C standard states in general
> terms that "recursion function calls shall be permitted", the
> "environmental limits" section places no constraints whatsoever on the
> depth of recursion that a C implementation is required to support. So it
> is perfectly acceptable to store the current hierarchy of function calls
> in a fixed length list buffer, with NO notion of a stack growing and
> shrinking.

Sure, and that is not a stack huh???

I did not mention any machine stack but just a "stack like organization"
and your trolling has nothing to do with what I wrote.

[toc] | [prev] | [next] | [standalone]

#14259

On Dec 3, 12:33 am, Quentin Pope <qp19...@hotmail.NOSPAM.com> wrote:
>
> Sorry, but this is extremely misleading. C can and does run on
> implementations with no stack.
>
I had such an implementation. int was eight bits, double 24 bits, of
which 7 were exponent. Recursion was not supported. There was no
malloc. Essentially every variable had an invisible "static"
qualifier. It wasn't conforming, but it was clearly C.

[toc] | [prev] | [next] | [standalone]

#14261

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Dec 3, 12:33 am, Quentin Pope <qp19...@hotmail.NOSPAM.com> wrote:
>> Sorry, but this is extremely misleading. C can and does run on
>> implementations with no stack.
>>
> I had such an implementation. int was eight bits, double 24 bits, of
> which 7 were exponent. Recursion was not supported. There was no
> malloc. Essentially every variable had an invisible "static"
> qualifier. It wasn't conforming, but it was clearly C.

I'd say such an implementation is C-like, but it's not C.

I think what Quentin is referring to is implementations on which
activation records for function calls are not necessarily allocated
at monotonically increasing or decreasing addresses.

Any conforming C implementation must have something that behaves in
a stack-like manner.  It needn't be a contiguous region of memory.
And even if, as Quentin suggested, the implementation uses a fixed
length buffer for active function calls, it still has to behave in
a stack-like manner.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13876

Bogdan <cristeab@gmail.com> wrote:
>  I had during an interview this question: which variables are
> allocated on the stack in a function ? I am unsure how the output
> variable is handled. Is this one too allocated on the stack and popped
> when the function exists ?
> Here is an example:

> char* some_function(char c)
> {
>      char *out = malloc(10);
>      return out;
> }

> On the local stack are there one char and 2 pointers to chars ?

This can actually be a clever question, at least if it's meant
to test your understanding on several levels (assuming that the
person asking it is aware of that).

The correct answer to the question (unless further qualified)
is, of course, that it's impossible answer it. The C standard
doesn't mandate the existence of a "stack", "heap" etc. (none
of these words appear in the standard at all). It is left to
the discretion of the compiler where it gets the memory needed
from.

On the other hand on all machines I am familiar with compilers
use a stack and a heap. And (non-static) local variables like
'out' are allocated (if necessary) on the stack (while alloca-
tions with malloc() are made from the heap).

Things get even more interesting since there is a chance
that a local variable actually might not reside in memory at
all, e.g. in this function the compiler (at least when allowed
to do a bit of optimization) might rather likely not need room
on the stack for 'out' but will be able to get along with a CPU
register - the function could easily rewritten as

char * some_function( char c )
{
    return malloc( 10 );
}

and then there's no 'out' variable left.

The next question is how values are passed between the caller
and the function. In the simplest case (again, on machines one
typically encounters - remember that there is no requirement
that a stack exists at all) arguments and return values are
put on the stack. But if there aren't too many of them the
compilers often passes them in CPU registers. Thus for the
function there is a good chance that neither 'c' nor 'out'
ever make it to the stack and instead just reside in CPU
registers (which, again, might depend on the settings for
the compiler, gooogle for e.g. "calling convention").

So, except for the first statement that the question, can't
be answered, it all depends on how the compiler works (and
the architecture the program is compiler for). It only can
be determined for sure by inspecting the assembler code the
compiler generates. But that, of course, is then not a
question about C but about the way a certain compiler im-
plements what is required by the C standard (though it's
also an interesting question that a compentent C programmer
is not unlikely to at least have spend a bit of time won-
dering about).
                           Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#13878

On Nov 24, 11:28 pm, Bogdan <crist...@gmail.com> wrote:
> Hi
>
>  I had during an interview this question: which variables are
> allocated on the stack in a function ? I am unsure how the output
> variable is handled. Is this one too allocated on the stack and popped
> when the function exists ?
> Here is an example:
>
> char* some_function(char c)
> {
>      char *out = malloc(10);
>      return out;
>
> }
>
> On the local stack are there one char and 2 pointers to chars ?
>
A modern compiler would probably just optimise that function to a call
to malloc().

However the abstract C compiler needs a stack for the function calls,
and a stack for variables. When you call a function, the address of
the instruction to return to in caller is pushed onto the call stack.
Then the parameters are pushed onto the variable stack (in this case,
c). Then the local variables are pushed onto the variable stack (in
this case, out). The function then does its calculations, the variable
stack is popped, the return address is popped off the call stack and
the function returns. So what happens to the return value? Almost
always, it is returned in a register.

However pushing and popping stacks is not very efficient. So compilers
use registers as much as possible. On most processors, the first four
parameters will be passed in registers. Also, the call stack can be
the same as the variable stack.
--
New: sequence logo generator
http://www.maclommclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#13880

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:aae5e2ca-0716-489f-9ad5-4ab494a16841@o1g2000vbe.googlegroups.com...
> On Nov 24, 11:28 pm, Bogdan <crist...@gmail.com> wrote:

>> char* some_function(char c)
>> {
>>      char *out = malloc(10);
>>      return out;
>>
>> }
>>
>> On the local stack are there one char and 2 pointers to chars ?
>>
> A modern compiler would probably just optimise that function to a call
> to malloc().
>
> However the abstract C compiler needs a stack for the function calls,
> and a stack for variables. When you call a function, the address of
> the instruction to return to in caller is pushed onto the call stack.
> Then the parameters are pushed onto the variable stack (in this case,
> c). Then the local variables are pushed onto the variable stack (in
> this case, out). The function then does its calculations, the variable
> stack is popped, the return address is popped off the call stack and
> the function returns. So what happens to the return value? Almost
> always, it is returned in a register.

If you're going to talk about abstract call and variable stacks, then why 
not put the return value onto the abstract variable stack too?

> However pushing and popping stacks is not very efficient. So compilers
> use registers as much as possible. On most processors, the first four
> parameters will be passed in registers.

That's fine until the registers are needed for something else or you need to 
make another function call. Then they need to be saved, perhaps by pushing 
onto the stack, then popping again. Except this might be done a million 
times within the function, instead of just once.

> Also, the call stack can be
> the same as the variable stack.

Some compilers have an option to display the code they generate. Then it is 
possible to see some actual code.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13881

Le 25/11/11 12:05, BartC a écrit :
>> However pushing and popping stacks is not very efficient. So compilers
>> use registers as much as possible. On most processors, the first four
>> parameters will be passed in registers.
>
> That's fine until the registers are needed for something else or you
> need to make another function call. Then they need to be saved, perhaps
> by pushing onto the stack, then popping again. Except this might be done
> a million times within the function, instead of just once.
>

Unlikely. In most cases the compiler knows if the function calls
another function and will save the registers at the start
in the function prologue...

[toc] | [prev] | [next] | [standalone]

#13882

"jacob navia" <jacob@spamsink.net> wrote in message 
news:jant5d$lji$1@speranza.aioe.org...
> Le 25/11/11 12:05, BartC a écrit :
>>> However pushing and popping stacks is not very efficient. So compilers
>>> use registers as much as possible. On most processors, the first four
>>> parameters will be passed in registers.
>>
>> That's fine until the registers are needed for something else or you
>> need to make another function call. Then they need to be saved, perhaps
>> by pushing onto the stack, then popping again. Except this might be done
>> a million times within the function, instead of just once.
>>
>
> Unlikely. In most cases the compiler knows if the function calls
> another function and will save the registers at the start
> in the function prologue...

Fair enough. In that case it's just another way to push those parameters, 
via registers, leaving it to the callee to do the actual pushing. With the 
advantage that the callee will know when it is possible to avoid pushing 
onto the stack.

The disadvantage for the caller might be a little more effort, for the 
compiler, in evaluating complex parameters and ensuring those registers 
already loaded are preserved. For example:

 fn(f(p,q,r), g(s), h(t,u,v), i());

Here, purely stack-based parameters would be far simpler.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13883

Le 25/11/11 12:40, BartC a écrit :
>
>
> "jacob navia" <jacob@spamsink.net> wrote in message
>> Unlikely. In most cases the compiler knows if the function calls
>> another function and will save the registers at the start
>> in the function prologue...
>
> Fair enough. In that case it's just another way to push those
> parameters, via registers, leaving it to the callee to do the actual
> pushing. With the advantage that the callee will know when it is
> possible to avoid pushing onto the stack.
>
> The disadvantage for the caller might be a little more effort, for the
> compiler, in evaluating complex parameters and ensuring those registers
> already loaded are preserved. For example:
>
> fn(f(p,q,r), g(s), h(t,u,v), i());
>
> Here, purely stack-based parameters would be far simpler.
>

Yes, I agree with you 100%. Having implemented linux's calling
conventions where you have nothing less than 7 registers that
can receive parameters those calls with embedded cals in the arguments
evaluation are a plain nightmare...

For me.

But in the big view where the compiler writer is just a matter of
fact that nobody cares about, this speeds up the code in MOST cases,
what is the important point anyway.

[toc] | [prev] | [next] | [standalone]

#13965

On Nov 25, 11:52 am, jacob navia <ja...@spamsink.net> wrote:

<snip>

> [...] Having implemented linux's calling
> conventions where you have nothing less than 7 registers that
> can receive parameters

I can'tbelieve Linux specifies there are 7 registers. How would it run
on a processor that didn't have 7 registers?

> [...] those calls with embedded cals in the arguments
> evaluation are a plain nightmare...

<snip>

[toc] | [prev] | [next] | [standalone]

#13969

Le 27/11/11 11:31, Nick Keighley a écrit :
> On Nov 25, 11:52 am, jacob navia<ja...@spamsink.net>  wrote:
>
> <snip>
>
>> [...] Having implemented linux's calling
>> conventions where you have nothing less than 7 registers that
>> can receive parameters
>
> I can'tbelieve Linux specifies there are 7 registers. How would it run
> on a processor that didn't have 7 registers?
>

I do not think it would run in a processor with less than 7 registers

:-)

The 8086 already had 8 more than 30 years ago... But in your fantasy 
world maybe, anything is possible there.

Most of linux users and software runs in the x86. Yes, there
is a power pc version (32 registers) and there is an ARM version
(16 registers) and there could be other versions that I do not
know about.

[toc] | [prev] | [next] | [standalone]

#13971

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> On Nov 25, 11:52 am, jacob navia <ja...@spamsink.net> wrote:
> 
> <snip>
> 
> > [...] Having implemented linux's calling
> > conventions where you have nothing less than 7 registers that
> > can receive parameters
> 
> I can'tbelieve Linux specifies there are 7 registers. How would it run
> on a processor that didn't have 7 registers?
> 
> > [...] those calls with embedded cals in the arguments
> > evaluation are a plain nightmare...
> 

Linux calling convention depends on the architecture. I guess Mr navia
is refering to the x86_64 calling convention.

-- 
André Gillibert

[toc] | [prev] | [next] | [standalone]

#13973

Le 27/11/11 13:44, André Gillibert a écrit :
> Nick Keighley<nick_keighley_nospam@hotmail.com>  wrote:
>> On Nov 25, 11:52 am, jacob navia<ja...@spamsink.net>  wrote:
>>
>> <snip>
>>
>>> [...] Having implemented linux's calling
>>> conventions where you have nothing less than 7 registers that
>>> can receive parameters
>>
>> I can'tbelieve Linux specifies there are 7 registers. How would it run
>> on a processor that didn't have 7 registers?
>>
>>> [...] those calls with embedded cals in the arguments
>>> evaluation are a plain nightmare...
>>
>
> Linux calling convention depends on the architecture. I guess Mr navia
> is refering to the x86_64 calling convention.
>
In the Power PC you use register windows, and as far as I remember
there are more than 7 rfegisters in a window.

Now, it could be that in the ARM the situation is completely different
I do not know. Those are marginal "markets" for linux, (unless you 
consider Android as linux) most users are in the main x86 distribution.

[toc] | [prev] | [next] | [standalone]

#13974

jacob navia <jacob@spamsink.net> wrote:
> Le 27/11/11 13:44, André Gillibert a écrit :
> > Nick Keighley<nick_keighley_nospam@hotmail.com>  wrote:
> >> On Nov 25, 11:52 am, jacob navia<ja...@spamsink.net>  wrote:
> >>
> >> <snip>
> >>
> >>> [...] Having implemented linux's calling
> >>> conventions where you have nothing less than 7 registers that
> >>> can receive parameters
> >>
> >> I can'tbelieve Linux specifies there are 7 registers. How would it run
> >> on a processor that didn't have 7 registers?
> >>
> >>> [...] those calls with embedded cals in the arguments
> >>> evaluation are a plain nightmare...
> >>
> >
> > Linux calling convention depends on the architecture. I guess Mr navia
> > is refering to the x86_64 calling convention.
> >
> In the Power PC you use register windows, and as far as I remember
> there are more than 7 rfegisters in a window.
> 
> Now, it could be that in the ARM the situation is completely different
> I do not know. Those are marginal "markets" for linux, (unless you 
> consider Android as linux) most users are in the main x86 distribution.
> 
> 

Are we talking of the same thing?
As far as I know, the C calling convention for Linux on i386, as used
in CCC, TCC and intel C compiler for user space function calls, put
function arguments on the stack pointed by ESP.

If you are refering to the system calling convention, that programs use
to enter kernel mode, this is a different thing, and, in my opinion,
not relevant to the original topic.

-- 
André Gillibert

[toc] | [prev] | [next] | [standalone]

#13976

Le 27/11/11 17:34, André Gillibert a écrit :
>
> Are we talking of the same thing?
> As far as I know, the C calling convention for Linux on i386, as used
> in CCC, TCC and intel C compiler for user space function calls, put
> function arguments on the stack pointed by ESP.

Sorry, I forgot to specify 64 bit linux. Obviously under 32 bits
the machine can't access all the extended registers (R8 to R15)
so the conventions are very similar to windows 32 bits, as you
say, using the stack.

Since 32 bit linux is quite dated, I just didn't think that it was
necessary to specify that.

Sorry.

[toc] | [prev] | [next] | [standalone]

#13981

On 11/28/11 06:28 AM, jacob navia wrote:
> Le 27/11/11 17:34, André Gillibert a écrit :
>>
>> Are we talking of the same thing?
>> As far as I know, the C calling convention for Linux on i386, as used
>> in CCC, TCC and intel C compiler for user space function calls, put
>> function arguments on the stack pointed by ESP.
>
> Sorry, I forgot to specify 64 bit linux. Obviously under 32 bits
> the machine can't access all the extended registers (R8 to R15)
> so the conventions are very similar to windows 32 bits, as you
> say, using the stack.
>
> Since 32 bit linux is quite dated, I just didn't think that it was
> necessary to specify that.

Far from dated.  Most targets for embedded Linux are 32 bit (ARM, PPC).

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web