469,926 Members | 1,558 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,926 developers. It's quick & easy.

C calling conventions

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

Nov 14 '05 #1
16 2044

On 21/06/2005 21:50, aa*****@gmail.com wrote:
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/Pe...umentation.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.

Nov 14 '05 #2
aa*****@gmail.com writes:
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

aa*****@gmail.com writes:
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-----
Nov 14 '05 #4


aa*****@gmail.com wrote:
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.

--
Er*********@sun.com

Nov 14 '05 #5
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.

Nov 14 '05 #6

On 21/06/2005 22:47, Jean-Claude Arbaut wrote:
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.


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.

Nov 14 '05 #7
aa*****@gmail.com wrote:
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.
Nov 14 '05 #8

<aa*****@gmail.com> wrote
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.
Nov 14 '05 #9
jacob navia <ja***@jacob.remcomp.fr> writes:
aa*****@gmail.com 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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #10
aa*****@gmail.com wrote:
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.
Nov 14 '05 #11
aa*****@gmail.com wrote:

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:
news:news.announce.newusers
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
Nov 14 '05 #12
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 <ja***@jacob.remcomp.fr> schrieb:
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.


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.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Nov 14 '05 #13
Spiro Trikaliotis wrote:
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.
Nov 15 '05 #14
jacob navia wrote:
Spiro Trikaliotis wrote:
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

.... snip ...

Are you doing this solely to annoy? Why did you snip Mr.
Trikaliotis' preamble, which read:
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 <ja***@jacob.remcomp.fr> schrieb:


--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 15 '05 #15
jacob navia <ja***@jacob.remcomp.fr> wrote:
Spiro Trikaliotis wrote:
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...


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
Nov 15 '05 #16
Keith Thompson wrote:
... parameters can be passed ... by carrier pigeon.


Is this on the same machine that famously "stores pointers
in pickle bottles"?

James

Nov 15 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Muthu | last post: by
13 posts views Thread by RainBow | last post: by
2 posts views Thread by Geler | last post: by
16 posts views Thread by teju | last post: by
10 posts views Thread by sulekhasweety | last post: by
16 posts views Thread by Jaco Naude | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.