C calling conventions

A

aarklon

Hi folks,

recently i read the book named assembly language step by step by Jeff
Duntemann.

in the chapter coding for linux, he has got a paragraph

named C calling conventions, which he describes as follows

1)
a function must preserve the values of ebx,esp,ebp,esi and edi 32 bit
registers. i.e although it may use those registers, when it returns
control to it's caller,the values of those registers must be the same
values they had before the function was called

2)

the contents all other G.P registers may be altered at will(in linux
this pointedly does not include the segmented registers, because it
being a protected mode operating system)

3)
A procedures return value is returned in EAX. if it's value is 32
bit or smaller.64 bit integer values are returned via EDX and EAX, with
the low 32 bits in EAX. floating point return values are returned via
floating point stack.strings structures and other items larger than
bits are returned by reference. i.e a function returns a pointer to
them in EAX.

4)
parameters passed to the procedure are pushed in the reverse order,
i.e given the C function(foo,bar,bas); bas pushed onto the stack first,
bar pushed onto the stack second.foo pushed onto the stack last.

5)
procedures do not remove parameters from the stack. the caller must
do that after the procedure returns.

either by popping the procedures Off(more commonly since it is
usually faster)

by adding an offset to the stack pointer ESP

well my question is how far these statements are correct.

please note that i am by no means an expert C programmer.i just want
gain a good understanding on these matters
 
R

Roger Leigh

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

recently i read the book named assembly language step by step by
Jeff Duntemann.

in the chapter coding for linux, he has got a paragraph

named C calling conventions, which he describes as follows
[...]

well my question is how far these statements are correct.

please note that i am by no means an expert C programmer.i just want
gain a good understanding on these matters

You are better asking in a GNU/Linux newsgroup, such as
comp.os.linux.development.system, or an i386 assembler group. All
this is implementation- and platform-specific.

Also note that the "calling conventions" also vary depending on the
CPU type. For example, the system I'm writing this on
(powerpc-unknown-linux-gnu) almost certainly does not use the above
conventions, but is a regular GNU/Linux system in all respects.

In six years of writing applications in C for GNU/Linux, I've never
once needed to touch assembler (though I once needed to check the
assember output of different GCC versions to find a GCC bug). Unless
you are writing kernel internals or highly-optimised speed-critical
routines using Altivec/SIMD instructions, I can't see any benefit.


Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCuHYjVcFcaSW/uEgRApbBAKCmoYJzgqjuf79szaYJqt2+ofpDwQCgmcMa
kWXEFtdEHRFPogyVEeK83a8=
=N7to
-----END PGP SIGNATURE-----
 
J

Jean-Claude Arbaut

Hi folks,

[...]

well my question is how far these statements are correct.

100% off-topic here. The C language doesn't discuss such implementation
issues.

These statements seem to apply to the Intel i386 ABI (it is also OS
dependant). I didn't check if they are right or wrong for any particular
one, you should read in your book to which system it applies, and then get
some information on that system on the web.
You can start at http://downloads.openwatcom.org/ftp/devel/docs/

Intel Pentium manuals will probably help you if you learn the assembly
language on that machine:

http://developer.intel.com/design/Pentium4/documentation.htm
please note that i am by no means an expert C programmer.i just want
gain a good understanding on these matters

You should also get a copy of the C standard then ;-)

Maybe of interest to you is the POSIX standard:

http://www.opengroup.org/onlinepubs/000095399/

Not directly related with your question, but even if you program in
assembly, you may be interested by common C functions.
 
K

Keith Thompson

recently i read the book named assembly language step by step by Jeff
Duntemann.

in the chapter coding for linux, he has got a paragraph

named C calling conventions, which he describes as follows

1)
a function must preserve the values of ebx,esp,ebp,esi and edi 32 bit
registers. i.e although it may use those registers, when it returns
control to it's caller,the values of those registers must be the same
values they had before the function was called [snip]
well my question is how far these statements are correct.

That looks like it's specific to x86 processors, and possibly to Linux
systems. The C language itself says nothing about calling
conventions. As far as the language is concerned, parameters can be
passed on the stack, in registers, or by carrier pigeon.
 
E

Eric Sosman

Hi folks,

recently i read the book named assembly language step by step by Jeff
Duntemann.

in the chapter coding for linux, he has got a paragraph

named C calling conventions, which he describes as follows
[...]

well my question is how far these statements are correct.

The book is describing the conventions of one particular
implementation of C. Other implementations on other machines
will do things differently -- for example, the machine I happen
to be using at the moment has none of the registers mentioned
in the book and does not always push arguments on the stack.

I'm not able to say whether the description is correct for
the implementation it describes. For one thing, it does not
name the implementation (although a shrewd guess is possible).
For another, I am not qualified to say whether the book may
have overlooked or mis-stated some subtle point (e.g., the
allocation of the pointed-to result of a struct-valued function).
please note that i am by no means an expert C programmer.i just want
gain a good understanding on these matters

What you should do next depends on what you think "these
matters" are. If you are interested in how C is implemented
on one particular platform, this is the sort of thing to read.
If you are interested in how to write C that runs on many
platforms, this is the sort of thing you should probably *not*
read -- not until your grasp of C itself is firmer, so you can
distinguish the general from the implementation-specific.
 
J

Jean-Claude Arbaut

In six years of writing applications in C for GNU/Linux, I've never
once needed to touch assembler (though I once needed to check the
assember output of different GCC versions to find a GCC bug). Unless
you are writing kernel internals or highly-optimised speed-critical
routines using Altivec/SIMD instructions, I can't see any benefit.

On the speed-critical side, you can use Altivec "builtins" in gcc so the
only reason to write in assembly is trying to beat gcc optimizer.
 
J

Jean-Claude Arbaut

On the speed-critical side, you can use Altivec "builtins" in gcc so the
only reason to write in assembly is trying to beat gcc optimizer.

gcc4 is even said to be able to introduce Altivec instructions if your code
can take benefit from that, but I doubt it works very well.
 
J

jacob navia

Hi folks,

recently i read the book named assembly language step by step by Jeff
Duntemann.

in the chapter coding for linux, he has got a paragraph

named C calling conventions, which he describes as follows

1)
a function must preserve the values of ebx,esp,ebp,esi and edi 32 bit
registers. i.e although it may use those registers, when it returns
control to it's caller,the values of those registers must be the same
values they had before the function was called

Correct. All compilers do that under windows. Under linux
ebx is used in shared objects to access the GOT (global
object table). It may be a global register so that maybe it
should not be used at all. Look in the docs for
the shared object flag of gcc. (I think it is called --picture,
but I am not so sure)
2)

the contents all other G.P registers may be altered at will(in linux
this pointedly does not include the segmented registers, because it
being a protected mode operating system)
It is never a good idea to alter a segment register. In the flat model,
that is supported by Linux/Windows, all the segment registers point
to the same 4GB segment. But Windows uses FS to point to the exception
handling list, and other segment registers have other uses. Just do
not change anything
3)
A procedures return value is returned in EAX. if it's value is 32
bit or smaller.64 bit integer values are returned via EDX and EAX, with
the low 32 bits in EAX. floating point return values are returned via
floating point stack.strings structures and other items larger than
bits are returned by reference. i.e a function returns a pointer to
them in EAX.

Structures with size less than 32 bits may be returned in EAX. Some
compilers return 64 bit values in EAX:EDX, others can use different
registers. Under 64 bit windows XMM0 is used for floating point data.
4)
parameters passed to the procedure are pushed in the reverse order,
i.e given the C function(foo,bar,bas); bas pushed onto the stack first,
bar pushed onto the stack second.foo pushed onto the stack last.

Correct. This is the C calling convention.
5)
procedures do not remove parameters from the stack. the caller must
do that after the procedure returns.

either by popping the procedures Off(more commonly since it is
usually faster)

by adding an offset to the stack pointer ESP

The _stdcall calling convention allows for the *called* procedure to
clean the stack with return XX, where XX is the parameter stack size.
This is more efficient and under the windows OS all system calls are
like that.

Under linux system calls receive arguments in the registers.
well my question is how far these statements are correct.
They are correct with some provisions.
 
M

Malcolm

1)
a function must preserve the values of ebx,esp,ebp,esi and edi 32 bit
registers.
etc

well my question is how far these statements are correct.

please note that i am by no means an expert C programmer.i just want
gain a good understanding on these matters
Most platforms have a calling convention, which allows functions written in
assembly language or other languages to work well together. Because it is
quite common for C programs to call assembly functions directly, the way the
C compiler observes the convention is often of particular interest.

However C compilers exist for many platforms, most of which are not x86. And
on a platform as widespread as the PC, many C compliers are available. Very
few people could give you chapter and verse on which ones comply with which
particular conventions. For this reason we discourage discussion of such
specific topics here.

But a compiler will almost always set up arguments and preserve registers in
a defined way, so that you can write C-callable assembly functions. Either
the compiler or the assembler (often provided by the same company) will give
you the details in the documentation.
 
K

Keith Thompson

jacob navia said:
(e-mail address removed) wrote: [snip]
4)
parameters passed to the procedure are pushed in the reverse order,
i.e given the C function(foo,bar,bas); bas pushed onto the stack first,
bar pushed onto the stack second.foo pushed onto the stack last.

Correct. This is the C calling convention.

As I'm sure you're aware, referring to this as the "C calling
convention" does not in any way imply that it's defined by the C
language. There may be some secondary standard or standards that say
that some particular convention should be used by C compilers on some
particular set of systems, but the C language itself says little or
nothing about calling conventions. As I mentioned in another followup
in this thread, as far as the C language is concerned, parameters can
be passed on the stack, in registers, or by carrier pigeon.

If you want to discuss system-specific details like this, please do so
in an apppropriate system-specific newsgroup.
 
E

E. Robert Tisdale

Recently,
I read the book named assembly language step by step by Jeff Duntemann.

In the chapter coding for linux,
he has got a paragraph named C calling conventions

This is a description of
the platform (machine architecture - operating system) specific
Application Binary Interface (ABI) for
the C computer programming language,
the Linux operating system and
the Intel i386 computer architecture.

It doesn't actually have anything to do
with the C computer programming language.
C compiler developers comply with the ABI
so that programs compiled by their compilers
interoperate seamlessly with the operating system
and the underlying machine architecture.
Compliant compilers can then be used
to compile the operating system itself.

C developers may choose not to comply with the C ABI
and provide assembler routines to implement the interface.

Compilers for other computer programming languages
may also comply with the C ABI so that they interoperate
with the operating system and C programs.

I used Google

http://www.google.com/

to search for

+"C ABI"

and I found lots of stuff.
 
C

CBFalconer

recently i read the book named assembly language step by step by
Jeff Duntemann.

in the chapter coding for linux, he has got a paragraph
named C calling conventions, which he describes as follows

1)
a function must preserve the values of ebx,esp,ebp,esi and edi
32 bit registers. i.e although it may use those registers, when it
returns control to it's caller,the values of those registers must
be the same values they had before the function was called

.... snip further system specific stuff ...

That is specific to one particular implementation on one particular
CPU. We specifically avoid dealing with such things here, and
restrict ourselves to the portable aspects of the language. Such
system specific things are best dealt with in system specific
newsgroups.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
 
S

Spiro Trikaliotis

Hello,

I know this is OT here, but to show why it is not good to answer OT
answers, I will show in error in this posting.

jacob navia said:
The _stdcall calling convention allows for the *called* procedure to
clean the stack with return XX, where XX is the parameter stack size.
This is more efficient and under the windows OS all system calls are
like that.

This is not completely true. On Windows, there is a define WINAPIV
(additionally to WINAPI) this is used to specify the calling convention
for wsprintfA() and wsprintfW().

Furthermore, the equivalent VFWAPIV is used for many more functions in
vfw.h.

Thus, it is not correct that ALL OS system calls on Windows are that
way.

As this is OT here, most people do not consider answering such things,
and such false claims stay uncontradicted.


Regards,
Spiro.
 
J

jacob navia

Spiro said:
This is not completely true. On Windows, there is a define WINAPIV
(additionally to WINAPI) this is used to specify the calling convention
for wsprintfA() and wsprintfW().
Those are deprecated since windows 95...
Furthermore, the equivalent VFWAPIV is used for many more functions in
vfw.h.
No longer in windows 32
Thus, it is not correct that ALL OS system calls on Windows are that
way.

I can't tell you but well, I did not find any that wouldn't be like this.

WINAPI is defined as _stdcall.
 
C

CBFalconer

jacob said:
Those are deprecated since windows 95...

No longer in windows 32
.... snip ...

Are you doing this solely to annoy? Why did you snip Mr.
Trikaliotis' preamble, which read:
 
R

Richard Bos

jacob navia said:
Those are deprecated since windows 95...

You really do have the gift of finding examples of why posting
off-topically is unwise, jacob.

The above is only mostly, not completely true. (No, I'm not explaining
why. If you want to know, take it somewhere where it's _on bleeding
topic_!)

Richard
 

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

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top