x86 and x86-64 ABIs and calling conventions

An application binary interface, or ABI, is the set of rules that compiled code follows so that it can be combined with other compiled code: a program with the libraries it calls, C with hand-written assembly, the output of one compiler with that of another. The C standard leaves these details to each platform, and the x86-64 and x86 platforms settled on a handful of ABIs. Each has its own page here, which names every platform that uses it.

What an ABI decides#

Data layout

The size and alignment of each type, and so how structs are padded. long has 8 bytes on Linux and 4 on Windows, so one struct declaration can describe two different layouts.

Calling convention

Which registers or stack slots carry the arguments and the result, which registers a called function must give back unchanged, how the stack is aligned at a call, and how a variadic function such as printf finds its arguments.

Stack frames and unwinding

How debuggers, profilers and exception handlers walk from a function back to its callers.

System calls

Which instruction enters the kernel, and where the call number and its arguments go.

Object files and linking

The file format (ELF, PE/COFF or Mach-O), relocations, how symbol names are decorated, and how code reaches thread-local variables.

C++

Name mangling, the layout of virtual tables, how this is passed and how exceptions unwind the stack.

For ELF systems, the processor supplements of the System V ABI, the psABIs, define most of this: the x86-64 psABI goes from type sizes to ELF relocations and unwind tables, and has an informative chapter on Linux system calls. Microsoft documents its conventions for Windows, and Apple documents where macOS departs from the x86-64 psABI.

The same C code shows the difference. Listing 1 has two small functions compiled for three ABIs.

/* Two functions, compiled for every ABI: where do the arguments
   arrive, and where does the result go? */
long diff(long a, long b)
{
	return a - b;
}

double axpy(double a, double x, double y)
{
	return a * x + y;
}

diff:
        movq    %rdi, %rax
        subq    %rsi, %rax
        ret

axpy:
        mulsd   %xmm1, %xmm0
        addsd   %xmm2, %xmm0
        ret

diff:
        mov     rax, rdi
        sub     rax, rsi
        ret

axpy:
        mulsd   xmm0, xmm1
        addsd   xmm0, xmm2
        ret

diff:
        movl    %ecx, %eax
        subl    %edx, %eax
        retq

axpy:
        mulsd   %xmm1, %xmm0
        addsd   %xmm2, %xmm0
        retq

diff:
        mov     eax, ecx
        sub     eax, edx
        ret

axpy:
        mulsd   xmm0, xmm1
        addsd   xmm0, xmm2
        ret

diff:
        movl    4(%esp), %eax
        subl    8(%esp), %eax
        ret

axpy:
        fldl    4(%esp)
        fmull   12(%esp)
        faddl   20(%esp)
        ret

diff:
        mov     eax, DWORD PTR 4[esp]
        sub     eax, DWORD PTR 8[esp]
        ret

axpy:
        fld     QWORD PTR 4[esp]
        fmul    QWORD PTR 12[esp]
        fadd    QWORD PTR 20[esp]
        ret

On System V x86-64, the two long arguments of diff arrive in RDI and RSI, and the result leaves in RAX. Microsoft x64 passes them in RCX and RDX, and since long has only 32 bits there, the code works on ECX, EDX and EAX. The 32-bit i386 ABI passes both on the stack, just above the return address. The three double arguments of axpy arrive in XMM0 to XMM2 on both 64-bit ABIs, and the result returns in XMM0; i386 passes them on the stack as well and returns the result on the x87 register stack, in ST0.

Every listing on these pages is the output of a real compiler: Clang 23.1.2, GCC 14.2.0 (Debian 14.2.0-19) and MinGW-w64 GCC 14.2.0 (Debian 14.2.0-19+27+b1), each pinned to an exact version and shown with the command that produced it. The AT&T and Intel buttons switch the syntax of every listing, and the choice is remembered. The site’s tests compile each listing again and fail if the output has changed.

Which platform uses which ABI#

A few rows need a word of explanation:

• UEFI firmware calls its services with the Microsoft x64 convention. EDK II, the reference implementation, marks every interface function with GCC’s and Clang’s ms_abi attribute when it builds for x64 with them, and Clang’s x86_64-unknown-uefi target compiles with the Microsoft registers and type sizes.
• Cygwin, and MSYS2’s MSYS environment, which is built on Cygwin, keep the Windows calling convention but use the LP64 model of Linux, so long has 64 bits. MSYS2’s other environments, such as UCRT64 and CLANG64, use Microsoft’s C runtimes and the Windows data model.
• macOS on Intel processors follows the x86-64 psABI except for a few differences that Apple documents, listed on the System V page. Apple has not supported 32-bit Intel code since macOS Catalina, so the table has no 32-bit row for it.

Data models#

The names of LP64 and LLP64 list the types that have 64 bits: long and pointers, or long long and pointers. ILP32 lists those with 32: int, long and pointers. long long has 64 bits everywhere. Code that keeps a pointer in an integer should use intptr_t or uintptr_t, which fit on every platform, rather than long, which does not on 64-bit Windows.

Sizes of C types#

Tables 3 and 4 give the size and alignment of the basic C types as the compilers of each platform see them. On every platform in them, _Bool and char take 1 byte, short 2, and int and float 4, and char is signed; the tables leave these types out.

The numbers come from compiling sizeof and _Alignof of each type with the compilers of each platform and reading the results back from the assembly. Each column was measured for all the targets listed under its table, and the site’s build fails if they disagree.

long double

It differs most between platforms. The System V ABIs, MinGW-w64 and Cygwin use the x87 80-bit format, stored in 16 bytes on x86-64 and in 12 bytes aligned to 4 on 32-bit x86. Android on x86-64 uses the 128-bit IEEE format instead, while MSVC, UEFI and Android on 32-bit x86 make long double the same as double.

double and long long on 32-bit x86

System V aligns them to 4 bytes and Windows to 8, so a struct of an int and a double takes 12 bytes on 32-bit Linux and 16 on 32-bit Windows.

wchar_t

It has 4 bytes on the System V platforms and 2 on Windows and Cygwin.

va_list

A pointer on Windows and on 32-bit x86, but a 24-byte structure on System V x86-64 (16 bytes in x32), because a variadic function’s arguments may still be in the registers they arrived in.

__int128

Available on every 64-bit platform here, x32 included, and on none of the 32-bit ones. On Windows it is Clang’s: MSVC’s own integer types end at 64 bits.

The pages#

One page for each ABI, naming every platform that uses it:

• System V x86-64, with Linux x32 and macOS
• Microsoft x64
• System V i386
• Windows x86

Pages that compare the ABIs:

• Calling conventions compared
• Stack frames
• Vector extensions and the ABIs
• System calls, with the Linux system call tables
• Thread-local storage
• Unwinding and exceptions
• C++ ABIs