Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Variables allocated on stack

Reply
Thread Tools

Variables allocated on stack

 
 
Ian Collins
Guest
Posts: n/a
 
      11-27-2011
On 11/27/11 12:30 PM, Stefan Ram wrote:
> Ian Collins<(E-Mail Removed)> writes:
>> No. At least not on any of the platforms I'm familiar with. Other
>> languages know how to call C (so they can access the platform's services).

>
> In this case, wouldn't »know how to call the platform's ABI«
> a more appropriate wording than »know how to call C«?


The two tend to be synonymous.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Markus Wichmann
Guest
Posts: n/a
 
      11-27-2011
On 27.11.2011 00:35, BartC wrote:
> "Ian Collins" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 11/27/11 12:00 PM, BartC wrote:
>>> "Markus Wichmann"<(E-Mail Removed)> wrote:
>>>
>>>> Plus, when you ask a compiler writer whether he want's to include
>>>> _two_different_ calling conventions in his compiler with the added
>>>> maintenance and stuff, guess what he'll say.
>>>
>>> Isn't that what happens anyway, when calling a function in a different
>>> language? (pascal, stdcall and so on.)

>>
>> No. At least not on any of the platforms I'm familiar with.

>
> So how do you call Pascal, Fortran, (or C++) etc from C on your platform? Do
> you not need to tell it that that imported function is in a different
> language?
>


Not here. Well, there's two possibilities: For one, my C compiler has a
nonstandard way of declaring a function with another calling convention,
for two my Pascal compiler has a de-facto standard way (i.e. Borland
does it the same way. ISO Pascal is next to unusable) of declaring a
function with another calling convention. OK, that is, my Pascal
compiler_s_. For Freepascal, I can either append "cdecl;" to a function
declaration/definition, or compile it with the commandline switch
"-Cccdecl", which I can also set in the config file, and for GNU Pascal,
cdecl is already the standard.

>> Other languages know how to call C (so they can access the platform's
>> services).

>
> The platform interface should be language-independent. This is where a
> binary interface becomes useful. (C has done a good job here in past, in
> defining such interfaces, but there is often confusion; is 'long' 32-bits or
> 64-bits for example? gcc for Windows says 32, gcc for Linux says 64.)
>


The binary interface is necessary when multiple compilers come into
play. Those may even be two C compilers, or a C compiler and an
assembler. (As is needed for writing a C standard library, because most
OSes cannot call a C-style main function, so you need a wrapper to get
from the OS-specific entry point to main(). You also need assembly for
other stuff in there.)

Also (I cannot resist):

$ uname -m -o
x86_64 GNU/Linux
$ cat test.c
#include <stdio.h>

int main()
{
printf("%d\n", sizeof(long));
return 0;
}
$ gcc test.c && ./a.out
8
$ gcc -m32 test.c && ./a.out
4

The ABI also defines much of the stuff the C standard deliberately
excludes, like padding rules of structures (arrays in structures are
only padded as much as the array type is big, i.e. a "char a[3];"
receives no padding at all on AMD64/SysV)

> But should a complex, register-based interface (I believe this might be for
> x86-64) be also used as the standard when one C function calls another C
> function in the same application?
>


The register-based interface of AMD64 is really not that much harder to
use than the register preservance rules of i386 were. You know, when a
function could only use three registers before having to set up a stack
frame. With AMD64 you could reserve the whole first register bank to
parameter passing and still have 8 registers left to do all of your
calculations. The result is that the calculations stay in the processor
without having to use the memory, which is nowadays a severe speedup.

CYA,
Markus
 
Reply With Quote
 
 
 
 
André Gillibert
Guest
Posts: n/a
 
      11-27-2011
Markus Wichmann <(E-Mail Removed)> wrote:
> On 26.11.2011 12:07, BartC wrote:
>
> > Surely compiler writers can do what they like - within their own
> > implementation? Calling conventions are only important when calling foreign
> > and OS functions, and being called from outside.
> >

>
> Yeah, that's right!
>
> Only... every function not defined "static" may be called "from the
> outside". Every call to a function only declared (and not qualified
> "static") but not defined may be to a foreign function.
>


Plus, when a "static" function pointer is passed around, either the
function must get the standard calling convention or a stub must be
written.

Or, an implementation that wants a non-standard calling convention may
use a non-standard keyword to differentiate internal functions that
must be called with the new calling convention from exported functions.

--
André Gillibert
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      11-27-2011
On Nov 25, 11:52*am, jacob navia <(E-Mail Removed)> 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>
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-27-2011
Le 27/11/11 11:31, Nick Keighley a écrit :
> On Nov 25, 11:52 am, jacob navia<(E-Mail Removed)> 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.
 
Reply With Quote
 
André Gillibert
Guest
Posts: n/a
 
      11-27-2011
Nick Keighley <(E-Mail Removed)> wrote:
> On Nov 25, 11:52Â*am, jacob navia <(E-Mail Removed)> 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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-27-2011
Le 27/11/11 13:44, André Gillibert a écrit :
> Nick Keighley<(E-Mail Removed)> wrote:
>> On Nov 25, 11:52 am, jacob navia<(E-Mail Removed)> 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.


 
Reply With Quote
 
André Gillibert
Guest
Posts: n/a
 
      11-27-2011
jacob navia <(E-Mail Removed)> wrote:
> Le 27/11/11 13:44, André Gillibert a écrit :
> > Nick Keighley<(E-Mail Removed)> wrote:
> >> On Nov 25, 11:52 am, jacob navia<(E-Mail Removed)> 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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-27-2011
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.


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-27-2011
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
stack frame size on linux/solaris of a running application stack Surinder Singh C Programming 1 12-20-2007 01:16 PM
perl variables allocated in shared memory - feasible/possible/done already? Chris Perl Misc 1 02-03-2007 06:12 PM
variable allocated from stack/bss ?? onkar C Programming 148 12-18-2006 07:22 AM
Dynamically Allocated Memory vs. Statically allocated Memory csnerd@gmail.com C++ 5 12-09-2004 01:44 AM



Advertisments