Talk: x86 calling conventions

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Contents [Hide] 1 history/meaning of cdecl? 2 Return Value in eax 3 thiscall 4 stdcall 5 standard entry sequence 6 Pascal = stdcall ?? 7 custom calling conventions 8 case sensiti.pdf 9 Visual Studio 2007 10 abstract binary interface?

[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? Wocould be a nice bit of information to include in the article. jonathonreinhart (talk), 15 minutes l 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 shocould be able to look it up. 128.174.236.250 (talk), 27 February 2009 (UTC)

[Edit] thiscall

There seems to be a conflict betweenThiscallAnd 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 cpush bpush apush [address of this]push [address of return]call func

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

AboutThiscallConvention, I was wondering if 'eas' 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 'it' 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 Required 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 wocould take the offset of the member and add it to" 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 wocould appear each instance has its own copy of the functions.

71.200.70.242, 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 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 obviusly not helpful.

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

-- Mrboo (talk, contribs), 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 [...] "wocould be confusing, because it wocould 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 obviusly needed to be saved prior an stdcall since they will be overwritten by the return.

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

I wocould say to "d your ugosz" be careful with your edits, in doubt, use the talk page. In ThiscallSection, you stated "Windows API functions don't have A this pointer! ", Well, the Section was already talking about * C ++ MemberFunctions *, and non-static was obviusly implicit but shoshould be noted. I have reverted to letdorf's version, though I agree that Windows functionsCan be misleading. This shocould be replaced On Microsoft Visual C ++ Compiler.

Another note: there was a mistake even in the other versions (pre d your ugosz), when saying "this is the same method used by Windows ThiscallFunctions that use variable arguments. "This is untrue: in Visual C ++, ThisIs 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 mcaid(Talk-contribs), 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), 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 shocould 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 shoshould write that in the article? -- BB-Froggy, 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 versions. 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, 8 January 2007 (UTC)

Just thought I wowould 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, 12 January 2007 (UTC)

[Edit] custom calling conventions

Afaik GCC has some form of M m calling conventions too, at least for prototypes (iirc See FreeBSD CSU code, the part that wraps syscils ). 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 using strated above; interfacing to APIs that are not in procedural format. system CILS mostly (DOS interrupts, amigaos API which uses a custom register allocation per function, even Linux and BSD syscils ).

Even though BSD syscils 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 your er code, with the calling conventions specifying where parameters shoshould 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 shocould be inlined (_ inline) and is a single operator er instruction (outb % Al, % EDX ). -The first argument shocould 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, 8 January 2007 (UTC)

[Edit] case sensiti.pdf

Shocould 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 already ded, it wocould help those reading this article who are trying to resolve calling convention related problems. -preceding unsigned comment added by 71.96.69.21 (talk), 10 March 2009 (UTC)

[Edit] visual maxcompute 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), 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), 31 December 2009 (UTC)

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