Re: "standard" C calling convention?

peter@javamonkey.com (Peter Seibel) 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. It's always machine-dependent.


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


No, but they often have stylistic resemblances. The simplest way a C
calling convention works is about like this:


* Parameters are all passed on the stack, narrow ones (like chars) being
    widened in some way not unrelated to the ways described in the C
    standards for function calling, but not necessarily identical.


* The order of parameters on the stack is the same as that in the function
    call, with the ones on the left being the ones closest to the stack
    pointer value once you're inside the function. This is usually achieved
    by pushing then in right-to-left order, but I don't believe that's
    guaranteed, and the order in which functions whose result is used
    as parameters is called is explicitly not guaranteed, IIRC.


* Parameters are left on the stack by the callee, and removed by the
    caller once the call has returned. This is the crucial difference
    from pascal conventions on many platforms, where the callee removes
    the parameters. Pascal-style conventions produce smaller code, but
    can't so readily handle functions with variable numbers of arguments.


* The alignment of parameters on the stack is generally the same as their
    alignment in memory. This tends to involve the stack pointer having some
    minimum alignment, but this may well be less strict than that required
    for some parameter types. Handling this also varies.


* There will be conventions about the preservation of registers and
    their usage for return values.


This basic model is inefficient for many functions, because parameters
have to be put on the stack and taken off again. More efficient ways of
doing it involve using registers for some arguments - although one always
falls back onto using memory if there are enough arguments - and are
utterly machine-specific.


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


The documentation for a processor architecture should describe it, or the
variants on it that are used. Sometimes this is found in compiler
documentation - e.g., there were several conventions for 16-bit x86,
differing in things like which integer registers were used for returning
long values. If you name your architecture(s), someone will probably be
able to tell you where to find the calling conventions documentation. For
Itanium, where it's kind of complicated, there's a small manual on the
subject.


> - Is the point of having a standard calling convention that it allows
> code compiled with different compilers to be linked together?


Yes, plus other reasons. Notably, it allows assembler subroutines to be
written which can be called from compiled code, and allows programmers who
really need to do silly tricks with arguments to manage it. For example, I
maintain DIY printf routines for a number of platforms, which aren't
allowed to use compiler built-in functions, for arcane historical reasons.
This can be tricky, but has always proved possible so far.


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


Linkers don't usually play with this, as far as I know, but I could be
wrong. Some platforms have conventions that try to ensure that code
compiled with incompatible calling conventions can't be linked together:
for example, MS Visual C++ has three possible calling conventions, and
uses different symbol naming conventions to prevent linking them.


---
John Dallman jgd@cix.co.uk
                    "C++ - the FORTRAN of the early 21st century."

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