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

Groups > comp.lang.c > #13959

Re: Variables allocated on stack

Show all headers | View raw

On 27.11.2011 00:35, BartC wrote:
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:9jda3mF4d0U13@mid.individual.net...
>> On 11/27/11 12:00 PM, BartC wrote:
>>> "Markus Wichmann"<nullplan@gmx.net>  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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web