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
16  2263 
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. 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.
-----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----- 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 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.
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. 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.
<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.
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. 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. 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
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/
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.
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
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
Keith Thompson wrote: ... parameters can be passed ... by carrier pigeon.
Is this on the same machine that famously "stores pointers
in pickle bottles"?
James This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Muthu |
last post by:
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...
|
by: RainBow |
last post by:
Hi everyone, (Very Sorry, if this is the wrong group in which I am
posting this query).
Code snippet:
//C library
typedef int (*PFunc)(int* aArg);
void call_c_foo(PFunc aPtrtoFunc)
{
|
by: j23 |
last post by:
I have library (static) testlib.cpp:
#include <stdarg.h>
void xxx(...)
{
char buf;
va_list args;
va_start(args, buf);
va_end(args);
}
|
by: apm |
last post by:
Can calling conventions of functions be changed in unmanaged C# in a similar
way that they can be changed using C++?
|
by: Geler |
last post by:
A theoretical question: Sorry if its a beginner question.
Here is a quote from the MSDN explaning the C/C++ calling convention.. It
demonstrates that the calling function is responsible to clean...
|
by: John Friedland |
last post by:
My problem: I need to call (from C code) an arbitrary C library
function, but I don't know until runtime what the function name is,
how many parameters are required, and what the parameters are. I...
|
by: teju |
last post by:
hi,
i am trying 2 merge 2 projects into one project.One project is using c
language and the other one is using c++ code.
both are working very fine independently.But now i need to merge both...
|
by: sulekhasweety |
last post by:
Hi,
the following is the definition for calling convention ,which I have
seen in a text book, can anyone give a more detailed explanation in
terms of ANSI - C
"the requirements that a...
|
by: Jaco Naude |
last post by:
Hi there,
This is my first post over here and I hope someone can give me some
guidance.
I'm trying to embed Python into a Visual C++ 2008 application and I'm
getting linker problems. I've...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
