Talk:X86 calling conventions

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Software / Hardware (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
Taskforce icon
This article is supported by Computer hardware task force (marked as Mid-importance).

Pascal calling convention[edit]

"Pascal, as used in the Pascal programming language". This is a tired myth. The language never specified a calling convention, any more than the C language did. This could be converted to a reference to a specific compiler (my guess is Borland). However, it is incorrect as it is.

double/float arguments on Linux/GCC[edit]

In Linux/GCC, double/floating point values should be pushed on the stack via the x87 pseudo-stack.
Using this method ensures it is pushed on the stack in the correct format.

I cannot verify this. Where is the citation/reference? What other "method" is not "correct"? -- (talk) 01:41, 24 July 2012 (UTC)

Difference between GCC 4.4 and 4.5[edit]

" Since GCC version 4.5, the stack must be aligned to a 16-byte boundary when calling a function (previous versions only required a 4-byte alignment.) "

I can not find this statement in the internet. Some related discussions here:

Basically that's says:

thiscall on GCC incorrect?[edit]

The section on thiscall for GCC seems to be incorrect.


On the Intel 386, the thiscall attribute causes the compiler to pass the first argument (if of integral type) in the register ECX. Subsequent and other typed arguments are passed on the stack. The called function will pop the arguments off the stack. If the number of arguments is variable all arguments are pushed on the stack. The thiscall attribute is intended for C++ non-static member functions. As gcc extension this calling convention can be used for C-functions and for static member methods.

Rbmj (talk) 00:53, 31 May 2012 (UTC)

History/meaning of cdecl?[edit]

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)

return struct[edit]

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. (talk) 19:58, 27 February 2009 (UTC)
This is largely true, but none of this is written in stone! It's completely up to the implementation of a particular language (not only C/C++...) and particular compiler. For regular internal calls (i.e. those which not use an external linker), many different schemes and conventions are used—sometimes even within a single compiler—for optimization. (talk) 17:11, 5 April 2011 (UTC)

What happens with small structs varies wildly. Though the system abi might have something to say about that (e.g. on Mac, Windows is essentially free for all) (talk) 11:12, 29 December 2011 (UTC)

Yes, struct return format matters. It should probably be added to a table. For now, here are some links:

OCTAGRAM (talk) 23:08, 7 December 2014 (UTC)


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;


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. 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...



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.

Standard Entry Sequence[edit]

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)

Pascal == Stdcall ??[edit]

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 (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:
  2. (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)
pro right-to-left:
  1. (pascal means the language here, not the keyword, but the calling convention should be the same)
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. 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)

What platform is Watcom authorative for? 32-bit Dos is all I can think off and varies wildly by vendor. Moreover "pascal" calling conventions are not limited to Windows. Classic MacOS had them too, default even.

I would simply keep "pascal" as a family of calling conventions "right-to-left, callee cleans up stack". Stdcall is then a specific version that als details which registers are saved. (talk) 11:15, 29 December 2011 (UTC)

Seems it was depending on the Pascal compiler. The only one I'm sure about, is for Borland Turbo Pascal for DOS, which used “left‑to‑right + the callee clean the stack” (I remember this, I did assembly with the assembler embedded directly into the language).--Hibou57 (talk) 10:41, 18 April 2013 (UTC)

Custom calling conventions[edit]

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, and on x86_64 they exchange ecx with r10

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. 10:48, 8 January 2007 (UTC) (minorly updated with x86_64 details in dec 2011)

Case Sensitivity[edit]

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 (talk) 07:34, 10 March 2009 (UTC)

Visual Studio 2007[edit]

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

Abstract Binary Interface?[edit]

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)

x64 Sections[edit]

Why are these two sections in an article titled "x86 calling conventions"? I think they should be in a separate article, or perhaps in x86-64. Jeh (talk) 11:51, 16 November 2010 (UTC)

Table of x86 calling conventions[edit]

The term "Red zone below stack" is never discussed before the table and is not explained, it should perhaps also be described how large it is, but on the other hand this is wikipedia and not the reference work... What it means is: For leaf functions (functions not calling other functions), they are free to use a certain number of bytes on the stack without having to change the stack pointer first. This matters for interrupt/signal handlers because they must start by moving the stack pointer below the red zone before they can push anything onto the stack, otherwise they risk corrupting data in leaf functions' red zone. (talk) 08:24, 28 October 2011 (UTC)

Caller-/callee-safed registers[edit]

Isn't it part of the calling convention, which processor registers must be saved by the caller/callee? If yes, it should be mentioned here. If not, where does this information belong to? --RokerHRO (talk) 09:11, 9 July 2013 (UTC)

Oh, I see, it is mentioned in the text, but missed in the overview table below. It should be there, too. What do you think? :-/ --RokerHRO (talk) 09:14, 9 July 2013 (UTC)

"bare" of an OS or compilers, as did the IBM PC.[edit]

Technically true for certain values or "OS", "compilers", and "IBM PC".

The "IBM PC" came with ROM BASIC, which included File Access, Disk Access and Memory Access, and certainly had a calling convention, although not a CALL statement. — Preceding unsigned comment added by (talk) 04:55, 12 August 2013 (UTC)

Lattice c return registers[edit]

The Lattice C 16 bit compiler returned 32 bit values in the AX:BX pair, not DX:AX. See page 32. — Preceding unsigned comment added by (talk) 07:28, 1 June 2015 (UTC)

Should the x64 calling convention be labeled as a variant of "__fastcall"?[edit]

I have noticed that the MSDN refers to the standard x64 calling convention as __fastcall[1], as do various other sources[2][3][4]. Considering this, should the main article be updated to mention this? I'm not too familiar with wikipedia policies for this sort of thing, so I'll just leave the information here. (talk) 21:43, 10 June 2016 (UTC)

"Parameters in registers" Column for x86-64 Entry[edit]

It lists the order as RDI, RSI, RDX, RCX, R8, R9, XMM0–7, but I think this is slightly unclear, for two reasons. The assembly output of compiling C code like:

 static const char *string = "Hello, world!\n";
write ( 0, string, 14 );

results in the call to write() being something like:

 movl $14,%edx
 movq $string,%rsi
 movl $0,%edi
 call write

The first point being that since on x86_64 pointers are 64 bits, but integers still default to 32 bits, it would be more accurate to say that the order is EDI/RDI, etc., depending on whether the parameter is an integer or an address.

The second point being that it might be helpful to indicate that the "order" referred to is how the code is read, left to right, *not* the order in which they are actually pushed onto the stack, right to left. So the "first" parameter from the callee's signature gets the first register in the described order, even though, in this case, it would be the third parameter pushed onto the stack, which might make one think that it was passed in EDX instead of EDI.

These are not academic points but things that actually did trip up my efforts for a bit before I looked a the -S output from gcc, so I thought I'd point out my misconceptions from having read the original text. — Preceding unsigned comment added by Ddade (talkcontribs) 05:06, 8 October 2016 (UTC)

  1. ^
  2. ^
  3. ^ (search for "default")
  4. ^ (Table 16, pg.28-29)