Talk:X86 calling conventions

From Wikipedia, the free encyclopedia

Jump to: navigation, search

[edit] History/meaning of cdecl?

I've looked around and can't find what exactly "cdecl" means - I'm assuming it's an abbreviation of "C declaration" but can't find a source that says so. Anyone have any insight? Would be a nice bit of information to include in the article. JonathonReinhart (talk) 07:31, 15 April 2010 (UTC)

[edit] return value in EAX

What if the returned value is larger than 32 bits ? For 64bit values I think the EAX:EDX pair is used instead, but when a large struct is returned, then it's returned on the stack. Anybody can explain the stack layout in this case ? Also for floating point values FP(0) is used, if I remember correctly.

From memory, when a function returns a struct, the caller allocates space for the returned stuct on the stack and the callee writes into this space. I don't have a citation for this handy, but someone should be able to look it up. 128.174.236.250 ( talk) 19:58, 27 February 2009 (UTC)

[edit] thiscall

There seems to be a conflict between the thiscall and the returning of class/structures. Both state that they are supposed to be passed as the "first" parameter. But only one can be number 1 ;). I'm guessing the return value wins out here and you'd have:

push c
push b
push a
push [address of this]
push [address of return]
call func

Right now I'm playing around with creating function calls on the fly. Some disassembly is required for this. If I find out for sure, I'll move this fact to the normal page.

About the thiscall convention, I was wondering if 'this' can be NULL? Can't find out...

I believe that it can never happen. The only problem I can think about are "Class Functions" (declared as 'static' in Java and C++) but if you use 'this' in such a function you will have a compilation error. (I'll make sure it's true and will let you know)

Yes, it can and does happen. Try it:

C* p= 0;
p->foo(); // segfault crash

//...
/* Must not be virtual!! */
void C::foo()
 {
 cout << this << endl;
 }

—Długosz

Static functions do not have access to a "this" pointer.

A "this" pointer being NULL has no effect other than a likely segfault when you attempt to access a class data member (as it would take the offset of the member and add it to the "this" pointer, then attempt to access it). Member functions only exist in code once and non-static ones are passed a hidden "this" pointer so that they can "know" which instance of the class they are working on. To most users, this is completely transparent and it would appear each instance has its own copy of the functions.

71.200.70.242 03:20, 2 November 2006 (UTC)

In the previous exemple, the call p->foo(); will create a segfault crash... That's why one can consider that this will never be NULL...

—pszczepa

[edit] stdcall

I've changed the line about whether the registers are preserved by the caller within the function, and added the {{dubious}} template, since I don't know what the real answer is. The line, before my change, was "Registers EAX, ECX, and EDX are preserved ** not preserved! ** for use within the function", which is obviously not helpful.

I've also removed a couple of other comments placed within the body of the article. If you want to clean up something, clean it up, or leave a comment on the talk page, not within the article itself.

--MrBoo (talk, contribs) 18:42, 27 October 2006 (UTC)

 

The previous versions didn't say they were preserved WITHIN the function, but that they were preserved for the function to use them without saving. Microsoft abide by the Intel ABI, and thus, since functions are free to use EAX,ECX and EDX *without* first pushing (saving) it, then, technically, it is true that these registers (if need be) are preserved prior a call. In any case, putting the sentence "Registers [...] are not preserved [...]" would be confusing, because it would seem to say that others might be (which is definitly NOT the case: it is the responsibility of the callee and modifier of these other regs to save them first). Also, primitive data types of size <= 8 bytes are returned via EDX:EAX, which underlines again that these regs are obviously needed to be saved prior an stdcall since they will be overwritten by the return.

So, anyway, Długosz was mistaken with his addition there.

I would say to "Długosz" BE CAREFUL with your edits, in doubt, use the talk page. In the thiscall section, you stated "Windows API functions don't have a this pointer!", well, the section was already talking about *C++ member functions*, and non-static was obviously implicit but should be noted. I have reverted to Letdorf's version, though I agree that Windows functions can be misleading. This should be replaced by on Microsoft Visual C++ compiler.

Another note: there was a mistake even in the other versions (pre Długosz), when saying "This is the same method used by Windows thiscall functions that use variable arguments." This is untrue: in Visual C++, this is passed in ECX, regardless of the use of the ... operator.

[edit] Standard Entry Sequence

I'm pretty sure this isn't right:

mov ebp, esp   ;make the base pointer point to the current stack location which is where the parameters are

At this point in code, the closest elements on the stack are the old ebp, then the return address, and only then the parameters. The mistake is repeated elsewhere in the section I think. Aaron McDaid (talk - contribs) 00:03, 24 November 2006 (UTC)

[edit] Pascal == Stdcall ??

Everything I've seen says that Pascal is the same as Stdcall: right-to-left, callee cleans up stack. —The preceding unsigned comment was added by 70.19.86.148 (talk) 22:30, 28 December 2006 (UTC).

If I got it right, the only thing in question is, if the pascal keyword pushes the parameters left-to-right or right-to-left. Before reading your comment, I thought it was left-to-right and that's what the wikipedia article had said, before you doubted it. However, I've found different opinions in the internet:

pro left-to-right:

1. http://webster.cs.ucr.edu/Page_win32/win32API.html
2. http://support.microsoft.com/kb/100832/en-us?spid=3041&sid=global (it doesn't say pascal is left-to-right, but it says that stdcall is supported, pascal is not, which implies that stdcall and pascal are different things)
3. http://www.swissdelphicenter.ch/torry/printcode.php?id=1233

pro right-to-left:

1. http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Stdcall-Calling-Convention.html (pascal means the language here, not the keyword, but the calling convention should be the same)
2. http://www.unixwiz.net/techtips/win32-callconv.html

After all, one opinion must be wrong, but I can't see which. Perhaps we should write that in the article? -- BB-Froggy 13:31, 5 January 2007 (UTC)

Be careful here, to not confuse traditional Pascal conventions and what C compilers make out of it in their "Pascal" modifier. This is the same problem as with "cdecl" in other languages. It is not an universal "c" calling convention, but more specifically the "c compiler that this compiler sees as its natural twin", which can vary subtally This means it can be also a C++ compiler. (like with Delphi) with additional constraints

So Pascal traditionally pushed right to left and callee popped. But to assume such things about modern compilers (like Delphi and Free Pascal) is dangerous, since they are generally more flexible in calling conventions than C because they lack the need for a fixed calling conventions because they don't have loosely typed varargs kludges (printf) in normal code. In fact, both of them have a register convention as default. 88.159.73.216 10:34, 8 January 2007 (UTC)

Just thought I would weigh in here. I looked up the __pascal keyword in the Watcom C/C++ User's Guide, and its clear that:

• __pascal calling convention was used for OS/2 1.x and Microsoft Windows 3.x APIs
• __pascal pushes arguments on the stack from left to right (opposite of __stdcall), the callee cleans up

I think that this is an authoritative source, and I am accordingly writing it into the article. Choppingmall 17:25, 12 January 2007 (UTC)

[edit] Custom calling conventions

Afaik GCC has some form of custom calling conventions too, at least for prototypes (iirc see FreeBSD csu code, the part that wraps syscalls). Free Pascal has a bit more, for its AmigaOS connectivity. Another 16-bit compiler that had custom calling conventions was the TopSpeed 3.x series (Pascal,C++,Modula2 iirc)

One main use of a custom calling convention is already illustrated above; interfacing to APIs that are not in procedural format. System calls mostly (Dos interrupts, AmigaOS Api which uses a custom register allocation per function, even Linux and BSD syscalls).

Even though BSD syscalls are generally procedural (contrary to x86 Linux), they have to be modified because there are slight differences relating to the errorhandling.

The other major application is intrinsics; defining inline functions over assembler code, with the calling conventions specifying where parameters should go. A classic is the x86-Dos outport: (the exact syntax is fictional here)

1. pragma customcall (edx,eax)

__inline __asm void outport (int port,char value) {outb %al,%edx}

which means - the code should be inlined (__inline) and is a single assembler instruction (outb %al,%edx). - the first argument should go into edx, the second into eax (but in practice %al), exactly where the asm instruction expects them.

You can probably imagine other cases like SSE instructions now.

88.159.73.216 10:48, 8 January 2007 (UTC)

[edit] Case Sensitivity

Should the article include a description of the case-senstivity of the calling conventions?

cdecl and stdcall names are case-senstive. pascal names are not.

While technically not part of the calling convention, there is the greater good to consider. If case-sensitivity is included, it would help those reading this article who are trying to resolve calling convention related problems. —Preceding unsigned comment added by 71.96.69.21 (talk) 07:34, 10 March 2009 (UTC)

[edit] Visual Studio 2007

Someone mentions this (AFAIK) non-existent Visual Studio version. Probably version 2005 or 2008 is meant. —Preceding unsigned comment added by 85.220.124.20 (talk) 00:40, 7 July 2009 (UTC)

[edit] Abstract Binary Interface?

The beginning of the article maps "ABI" to "Abstract Binary Interface". I'm pretty sure this is incorrect. Later in the article, "ABI" is mapped to "Application Binary Interface" which is what I've more commonly heard ABI defined as Electron100 (talk) 23:16, 31 December 2009 (UTC)

Retrieved from " http://en.wikipedia.org/wiki/Talk:X86_calling_conventions"