Re: "standard" C calling convention?

Peter Seibel <peter@javamonkey.com> wrote:
>People often refer to the "standard C calling convention", usually as
>opposed to some other calling convention that a compiler also
>supports. I have several questions, in no particular order about this
>"standard".
>
> - Am I correct in assuming that this is more of an de facto than de
> jure standard.


Yes, most definitely. There is no relevant formal or even semi-formal
standard.


> - Is this calling convention the same across different machine
> architectures, OSes?


No, absolutely not. It is wildly different between operating systems
and often compiler vendors and architectures. You don't want to know
about the history of C calling conventions under IBM MVS, I can assure
you :-)


> - Where can I find a reliable description of it? (Other than looking
> at the source of gcc or something.)


Because there isn't one, you can't. You can find a description of
de facto conventions within a more restricted arena by techniques
such as you mention. Using assembler-level debuggers on the compiled
code is the other main way.


> - Is the point of having a standard calling convention that it allows
> code compiled with different compilers to be linked together? (I
> suspect that question itself may expose my deep ignorance of the
> relation between compilers and linkers--please bear with me, I'm
> filling in the gaps as fast as I can.)


Yes. But that is relevant only for a single operating system and
hardware combination. It is even more important for allowing the
compiled code to call system libraries without having to have a
complete set of the latter for each language.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
[Nick and I had a long argument, and I pointed out that the procedure
calling conventions for most current languages and systems are spelled out
in the documentation. He pointed out that the rest of the execution
environment, like how longjumps and signals are handled, usually isn't.
-John]

Return to the comp.compilers page.
Search the comp.compilers archives again.