The history of calling conventions, part 1

Date:January 2, 2004 / year-entry #2
Tags:history
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20040102-00/?p=41213
Comments:    27
Summary:The great thing about calling conventions on the x86 platform is that there are so many to choose from! In the 16-bit world, part of the calling convention was fixed by the instruction set: The BP register defaults to the SS selector, whereas the other registers default to the DS selector. So the BP register...

The great thing about calling conventions on the x86 platform is that there are so many to choose from!

In the 16-bit world, part of the calling convention was fixed by the instruction set: The BP register defaults to the SS selector, whereas the other registers default to the DS selector. So the BP register was necessarily the register used for accessing stack-based parameters.

The registers for return values were also chosen automatically by the instruction set. The AX register acted as the accumulator and therefore was the obvious choice for passing the return value. The 8086 instruction set also has special instructions which treat the DX:AX pair as a single 32-bit value, so that was the obvious choice to be the register pair used to return 32-bit values.

That left SI, DI, BX and CX.

(Terminology note: Registers that do not need to be preserved across a function call are often called "scratch".)

When deciding which registers should be preserved by a calling convention, you need to balance the needs of the caller against the needs of the callee. The caller would prefer that all registers be preserved, since that removes the need for the caller to worry about saving/restoring the value across a call. The callee would prefer that no registers be preserved, since that removes the need to save the value on entry and restore it on exit.

If you require too few registers to be preserved, then callers become filled with register save/restore code. But if you require too many registers to be preserved, then callees become obligated to save and restore registers that the caller might not have really cared about. This is particularly important for leaf functions (functions that do not call any other functions).

The non-uniformity of the x86 instruction set was also a contributing factor. The CX register could not be used to access memory, so you wanted to have some register other than CX be scratch, so that a leaf function can at least access memory without having to preserve any registers. So BX was chosen to be scratch, leaving SI and DI as preserved.

So here's the rundown of 16-bit calling conventions:

All
All calling conventions in the 16-bit world preserve registers BP, SI, DI (others scratch) and put the return value in DX:AX or AX, as appropriate for size.
C (__cdecl)
Functions with a variable number of parameters constrain the C calling convention considerably. It pretty much requires that the stack be caller-cleaned and that the parameters be pushed right to left, so that the first parameter is at a fixed position relative to the top of the stack. The classic (pre-prototype) C language allowed you to call functions without telling the compiler what parameters the function requested, and it was common practice to pass the wrong number of parameters to a function if you "knew" that the called function wouldn't mind. (See "open" for a classic example of this. The third parameter is optional if the second parameter does not specify that a file should be created.)

In summary: Caller cleans the stack, parameters pushed right to left.

Function name decoration consists of a leading underscore. My guess is that the leading underscore prevented a function name from accidentally colliding with an assembler reserved word. (Imagine, for example, if you had a function called "call".)

Pascal (__pascal)
Pascal does not support functions with a variable number of parameters, so it can use the callee-clean convention. Parameters are pushed from left to right, because, well, it seemed the natural thing to do. Function name decoration consists of conversion to uppercase. This is necessary because Pascal is not a case-sensitive language.

Nearly all Win16 functions are exported as Pascal calling convention. The callee-clean convention saves three bytes at each call point, with a fixed overhead of two bytes per function. So if a function is called ten times, you save 3*10 = 30 bytes for the call points, and pay 2 bytes in the function itself, for a net savings of 28 bytes. It was also fractionally faster. On Win16, saving a few hundred bytes and a few cycles was a big deal.

Fortran (__fortran)
The Fortran calling convention is the same as the Pascal calling convention. It got a separate name probably because Fortran has strange pass-by-reference behavior.
Fastcall (__fastcall)
The Fastcall calling convention passes the first parameter in the DX register and the second in the CX register (I think). Whether this was actually faster depended on your call usage. It was generally faster since parameters passed in registers do not need to be spilled to the stack, then reloaded by the callee. On the other hand, if significant computation occurs between the computation of the first and second parameters, the caller has to spill it anyway. To add insult to injury, the called function often spilled the register into memory because it needed to spare the register for something else, which in the "significant computation between the first two parameters" case means that you get a double-spill. Ouch!

Consequently, __fastcall was typically faster only for short leaf functions, and even then it might not be.

Okay, those are the 16-bit calling conventions I remember. Part 2 will discuss 32-bit calling conventions, if I ever get around to writing it.

Comments (27)
  1. Steve Sheppard says:
    January 2, 2004 at 9:08 am

    Just curious, you did this off the top of your head? I have a sheet pinned on the wall of my cube because I soemtime need to do manual stack walks in WinDBG and it’s handy but I can’t ever remember it exactly for more than a week…

  2. Russ C. says:
    January 2, 2004 at 10:31 am

    I just realised exactly how long it’s been since I wrote in Assembler !

  3. Eric WIlson says:
    January 2, 2004 at 11:03 am

    x86 (to be really fair I should say IA-32 / IA-16) show once again why it SHOULD have been regulated to the scrap heap long ago:) 3 or 4 open registers is not enough for a high level language to use to do much of anything without some stack walking. Cache of course helps here (it helps a lot actually, since the stack probably displays more locality of reference than most anything in your application), but the performance would be better with more registers.

    Most CPUs developed these days have at least 32 registers (MIPS and SPARC have 32; Itaninums have 128, etc.)

    Luckly, AMD has upped the number of registers in their x86-64 assembler (I think they add 8 or 16 off the top of my head). Would that help to make __fastcall live up to its name?

    Does/will visual studio support x86-64? If so, does it take advantage of the larger number of registers?

  4. Peter Lund/firefly@diku.dk says:
    January 2, 2004 at 5:20 pm

    Weren’t there also some fun stuff with the stack pointer sometimes being odd and sometimes even in WIN16?

    Does the AMD64 windows calling conventions use a red zone?

    The history of calling conventions, part 4: ia64
  5. Peter Lund/firefly@diku.dk says:
    January 2, 2004 at 5:24 pm

    register spills didn’t have to be expensive on WIN16 on old CPUs, did they? Couldn’t you occassionally use a segment register to spill to? (At least in real mode…)

  6. Raymond Chen says:
    January 2, 2004 at 9:08 pm

    Steve: Yes, this was from memory. (And I may have remembered __fastcall incorrectly but the basic idea is sound.)

    Eric: I will talk about the ia64 and amd64 calling conventions in a future entry. They are quite interesting.

    Peter: Egads I thought everybody had forgotten the odd/even rule. I’ll make another blog entry on that piece of Windows trivia. I don’t know what you mean by a "red zone" though. And although you could spill to a segment register, that was legal only in real mode, which was woefully ancient even in Windows 3.1 days.

  7. Peter Lund/firefly@diku.dk says:
    January 3, 2004 at 12:48 am

    http://www.x86-64.org/lists/discuss/msg00122.html

    it is an area "above" the stack pointer that the hardware/os/run-time library promise not to touch so leaf functions can store stuff there without having to adjust the stack pointer.

    It is hinted at (not by name) in the section "A five-per-cent Digression" of "Computer Science Technical Report No. 102: The C Calling Sequence" by Johnson and Ritchie, Bell Labs, Sep. 1981.

    I don’t know when or how it got the name "red zone".

  8. AlisdairM says:
    January 3, 2004 at 4:46 am

    Note that MS __fastcall and the Borland __fastcall are also different conventions that by some twist of history share the same name. (The quoted article refers to Borland __fastcall, BTW)

    I’m not familiar enough with the history of MS compilers to know where that convention came from, but for Borland __fastcall was born as ‘the register calling convention’ that is the standard convention used by the Delphi language (their object-oriented Pascal variant) This used 3 registers to pass the first 3 register-sized values (integers, pointers, etc) Your return value also counts as one of these 3, as does the implicit ‘self’ pointer for object method calls. The big advantage was supposed to be for functions passing entirely in registers ( <= 3 params, all register sized) where the traditional prolog/epilog would be omitted.

    When Borland introduced a C++ mapping to their Delphi class library with C++Builder, they needed a keyword for this convention and as register was already taken by the language they chose __fastcall.

    Just to make things more fun for the poor Borland user, after MS introduced __fastcall they had to have some way to maintain compatibility with code exporting this convention out of DLLs, and as they already used __fastcall themselves, __msfastcall was introduced! This might also mean doctoring yuor supplied headers to use the correct spelling for fastcall <g>

    This all occurred in the Win32 era though

  9. Frederik Slijkerman says:
    January 3, 2004 at 5:08 am

    The Borland __fastcall convention always seemed more logical and more efficient to me than the MS fastcall. It uses eax, edx, and ecx to pass parameters, where the MS convention only uses two of these (forgotten which ones). All other registers are always preserved. This applies to Win32.

  10. Mike Hearn says:
    January 3, 2004 at 8:39 am

    Hi Raymond, more questions :D Is is true that Win16 used pascal calling convention because it was actually written in pascal?

  11. Raymond Chen says:
    January 3, 2004 at 8:48 am

    Mike: No, the reason Win16 used the pascal calling convention was the reason I stated in my entry. Win16 was written in a mix of assembly and C. (KERNEL was almost entirely assembly; GDI was largely assembly, and USER was mostly C.)

    Remember that Pascal doesn’t support casting, which would have made things like WndProcs pretty close to impossible to write in Pascal.

  12. Peter Lund/firefly@diku.dk says:
    January 3, 2004 at 9:24 am

    Many Pascal dialects do/did support casting. All the ones I have used did. It is pretty easy to add to the language so that excuse doesn’t count ;)

    Mike, I think you are thinking of the Macintosh. As far as I know the toolbox ROMs were mostly written in assembler but they did choose Pascal as their systems programming language (for non-ROM stuff). The original Inside the Macintosh shows Pascal "prototypes" for (almost?) everything.

  13. Lesma says:
    January 5, 2004 at 5:22 am

    Very cool 8)

  14. chris says:
    January 6, 2004 at 8:50 pm

    I believe fastcall uses cx for the first and dx for the 2nd. At least that makes sense since 32 bit is ecx and edx for the 1st and 2nd respectively.

  15. James Curran says:
    January 7, 2004 at 8:00 am

    I was told (I believe by Charles Petzold) that Win16 used the Pascal calling convention because it allowed Windows 1.0 to ship using one fewer install floppies. (Which, back then, was a big deal)

  16. keithmo says:
    January 7, 2004 at 12:51 pm

    While reading these 16-bit details, I suddenly had a "flash back" to the old Win16 days — MakeProcInstance(), movable memory, shared DLLs, and other horrors. Ack! Pfft!!

  17. Sam Gentile's Blog says:
    January 8, 2004 at 8:49 am
  18. The Old New Thing says:
    January 8, 2004 at 10:03 am
  19. The Old New Thing says:
    January 8, 2004 at 1:22 pm
  20. Sam Gentile's Blog says:
    January 8, 2004 at 8:02 pm
  21. Simply Patrick says:
    January 13, 2004 at 1:19 pm

    ??????,??????????? ?????????? calling convention: The history of calling conventions, part 1 The history of calling conventions, part 2 The history of calling conventions, part 3 The history of calling conventions, part 4: ia64 Why do member functions need to be…

  22. Igor says:
    March 4, 2004 at 4:39 pm

    Any chance of explaining AMD64 fastcall convention sported in windows server 2003 ddk compiler? I have checked a listing and it seems to pass first 2 integers in ecx/edx then first 2 floats/doubles in xmm2/xmm3 and then the rest on stack above [rsp + 32]. Can anyone confirm this or point me to some docs?

  23. Raymond Chen says:
    March 4, 2004 at 4:41 pm

    Um, I already did: http://weblogs.asp.net/oldnewthing/archive/2004/01/14/58579.aspx

  24. The Old New Thing says:
    June 15, 2004 at 1:30 pm
  25. Flier's Sky says:
    July 7, 2004 at 11:03 pm

    The history of calling conventions

  26. Anuncie Aqui! says:
    May 17, 2006 at 8:44 am
  27. Hamo’s World » Dive into PASSCAL call says:
    June 25, 2007 at 4:37 am

    PingBack from http://www.hamo.cn/2007/06/dive-into-passcal-call/419.html

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index