function Calling conventions

M

Muthu

I've read calling conventions to be the order(reverse or forward) in
which the parameters are being read & understood by compilers.

For ex. the following function.
int Add(int p1, int p2, int p3);

The parameters here can be read either in the forward order from p1
till p3 or reverse order from p3 till p1.

Can anyone explain what is the advantage/disadvantage of either of
these ? What does C++ standard say about this?

Rgds
Muthu
 
K

Karl Heinz Buchegger

Muthu said:
I've read calling conventions to be the order(reverse or forward) in
which the parameters are being read & understood by compilers.

For ex. the following function.
int Add(int p1, int p2, int p3);

The parameters here can be read either in the forward order from p1
till p3 or reverse order from p3 till p1.

or p3, p1, p2
or p2, p1, p3
or p2, p3, p1
or p1, p3, p2
Can anyone explain what is the advantage/disadvantage of either of
these ? What does C++ standard say about this?

It is undefined. The compiler writer may choose the way which
is most simple in the implementation he wrotes or best fits the
hardware requirements or ....
 
O

Owen Jacobson

I've read calling conventions to be the order(reverse or forward) in which
the parameters are being read & understood by compilers.

For ex. the following function.
int Add(int p1, int p2, int p3);

The parameters here can be read either in the forward order from p1 till
p3 or reverse order from p3 till p1.

Or passed partly (or completely) in registers, or (ObCompSci) written to a
tape for a Turing machine, or...
Can anyone explain what is the advantage/disadvantage of either of these ?

For certain types of function, different calling conventions can be
advantageous. It may be faster to pass parameters through registers, for
functions with small numbers of parameters (one, for most register-based
schemes on x86, but other architectures may not have such tight register
limits), and for varargs functions the calling convention needs to be able
to handle arbitrary amounts of data.

All of this should be explained in your compiler's manual. You _have_
read it, have you?
What does C++ standard say about this?

Nothing at all. Calling conventions are different for each platform;
implementations are free to define their own so long as they can implement
C++ function semantics.
 
N

Niels Dybdahl

The parameters here can be read either in the forward order from p1
till p3 or reverse order from p3 till p1.
Can anyone explain what is the advantage/disadvantage of either of
these ?

The advantage of the forward order is that the compiler can generate code in
the same sequence as the source. This was important a long time ago, when
PCs did not have very much RAM.

The advantage of the backward order is that it allows variable number of
parameters. The first parameter is in that case at a fixed offset to the
stack pointer or base pointer and the other parameters can be addressed at
higher addresses.

There are other architectures where there are other issues. Especially CPUs
with a lot of registers will probably pass most of the parameters in
registers instead.
What does C++ standard say about this?

Dont know, but most C++ compilers use the backward order because of the
variable number of parameters. Most compilers can handle other calling
sequences including forward order and register passing.
I've read calling conventions to be the order(reverse or forward)

Calling conventions do also include who is responsible for removing the
parameters from the stack. The caller or the called function. Usual C++ lets
the caller remove the parameters, because if the number of parameters is
variable, then the called function might not know the number of parameters
to remove.

Niels Dybdahl
 
A

Alf P. Steinbach

* Muthu:
I've read calling conventions to be the order(reverse or forward) in
which the parameters are being read & understood by compilers.

For ex. the following function.
int Add(int p1, int p2, int p3);

The parameters here can be read either in the forward order from p1
till p3 or reverse order from p3 till p1.

Generally a calling convention includes

* General mechanism for parameters (in registers, static memory
locations, on the stack and if so in what order).

* Specifics of passing certain types of parameters, e.g. is a source
code pass-by-value struct passed as a pointer? If nested functions
are supported, how are outer function arguments accessed (Dijkstra
display or what)? And so on.

* Who is responsible for clean-up, e.g. with stack-based parameter
passing, who pops the stack on function return?


The calling convention in turn usually determines or constrains


* Transformation of source code names to linkage level names.

Can anyone explain what is the advantage/disadvantage of either of
these?

What is commonly called "C" calling convention is stack-based with
arguments pushed from right to left and caller responsible for popping,
and source code names transformed by prepending a single underscore.

That does not mean that a C compiler necessarily uses that convention,
but most do.

Main advantage is that it allows for variable length argument lists,
the "..." notation in C++, since the called function has the named
arguments at known locations, and since the caller has the knowledge
needed to pop the stack no matter how many arguments were pushed.

What is commonly called "Pascal" calling convention is stack-based
with arguments pushed from left to right and called function
responsible for popping (no common convention for name transform).

Pascal supports nested functions but how that aspect is implemented
is not specified when one says "Pascal" calling convention.

Main advantage is reduced machine code size.

What does C++ standard say about this?

It doesn't say much at all, only that 'extern "C"' should give
compatibility with some C compiler.

I think that is one aspect that would be nice to have in upcoming
"version 2" of the standard: support for specifying calling convention
and name transformation.

Another aspect: how can the stack be properly cleaned up in


void f( int x, ... )
{
throw std::runtime_error( "Oops!" );
}

void g()
{
f( 0, "What?", 42 );
}


using a variable length argument list.
 
P

Pete Becker

Karl said:
It is undefined.

It is unspecified. When the standard says that the effect of some piece
of code is undefined it means that the standard imposes no constraints
on what that code does. When it says that something is unspecified it
means that the implementation is free to choose among a well-defined set
of alternatives.
 
P

Pete Becker

Pete said:
It is unspecified. When the standard says that the effect of some piece
of code is undefined it means that the standard imposes no constraints
on what that code does. When it says that something is unspecified it
means that the implementation is free to choose among a well-defined set
of alternatives.

I left a key point unstated: a program that uses code constructs whose
behavior is undefined are ill-formed; a program that uses code
constructs whose behavior is unspecified are well-formed.
 
K

Karl Heinz Buchegger

Pete said:
It is unspecified. When the standard says that the effect of some piece
of code is undefined it means that the standard imposes no constraints
on what that code does. When it says that something is unspecified it
means that the implementation is free to choose among a well-defined set
of alternatives.


I think that neither 'undefined' nor 'unspecified' apply. At least
not in the meaning this words are used throughout the standard.
The standard simply doesn't say anything about how a compiler
should implement it (AFAIK). Or are there any alternatives listed
in the standard.
Or am I misunderstanding you completely?
 
P

Pete Becker

Karl said:
I think that neither 'undefined' nor 'unspecified' apply. At least
not in the meaning this words are used throughout the standard.
The standard simply doesn't say anything about how a compiler
should implement it (AFAIK). Or are there any alternatives listed
in the standard.
Or am I misunderstanding you completely?

No, you're probably right. I was thinking more of order of evaluation of
function arguments, which has nothing to do with calling convention.
Changes in calling conventions don't have visible behavior, so the
wording about unspecified behavior doesn't apply.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,831
Latest member
RusselWill

Latest Threads

Top