Calling conventions for different C++ compilers and operating systems

Introduction

This is the fifth in a series of five manuals:

1. Optimizing software in C++: An optimization guide for Windows, Linux, and Mac platforms.
2. Optimizing subroutines in assembly language: An optimization guide for x86 platforms.
3. The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers.
4. Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel, AMD and VIA CPUs.
5. Calling conventions for different C++ compilers and operating systems.

The latest versions of these manuals are always available from www.agner.org/optimize. Copyright conditions are listed on page 60 below.

The present manual describes technical details about compilers that are often poorly documented or not documented at all. This includes differences between various C++ compilers that affect binary compatibility, such as memory model, data storage, function calling conventions, and name mangling. These details are described in detail for each compiler or for each platform, where appropriate.

The purposes of publishing this information are:

• Point out incompatibilities between compilers.

• Make new compilers compatible with old ones.

• Solve compatibility problems between function libraries produced by different compilers.

• Facilitate linking different programming languages together.

• Facilitate the making of assembly subroutines that are compatible with multiple compilers and multiple operating systems.

• Solve compatibility problems for data stored in binary files.

• Facilitate the construction of debugging, profiling and disassembly tools.

• Facilitate the construction of object file conversion utilities.

• Provoke compiler vendors to use open standards.

• Inspire future standardization.

Hardware platforms covered:

• x86 microprocessors with 16 bit, 32 bit and 64 bit architectures from Intel, AMD, VIA and possibly other vendors.

The IA64 architecture, which is implemented in Intel’s Itanium processor, is not compatible with the x86 architecture, and is not covered in this report.

Operating systems covered:

• DOS, 16 bit.

• Windows, 16 bit, 32 bit and 64 bit.

• Linux, 32 bit and 64 bit.

• FreeBSD etc. 32 bit and 64 bit.

• Mac OS X, Intel based, 32 bit and 64 bit.

C++ compilers tested:

• Borland, 16 bit v. 3.0 and 5.0

• Microsoft, 16 bit, v. 8.0

• Watcom, 16 bit v. 1.2

• Borland 32 bit v. 5.0

• Microsoft, 32 bit, v. 9.0, 13.10, 16.3

• Gnu, 32 bit, v. 2.95, 3.3.3, 4.1.0 and several other versions under Linux, FreeBSD and Windows.

• Watcom, 32 bit, v. 1.2

• Symantec, 32 bit, v. 7.5

• Digital Mars, 32 bit, v. 8.3.8

• Codeplay VectorC, 32bit, v. 2.1.7

• Intel, 32 bit for Windows and Linux, v. 8.1 and 9.1

• Microsoft, 64 bit, v. 14.00, 16.3

• Gnu, 64 bit, v. 3.3.3, 4.1.0, 7.4.0, 9.2.0 for Linux and Windows

• Clang, 64 bit, v. 5.0, 9.0 for Linux and Windows

• Intel, 64 bit for Windows and Linux, v. 8.1 and 9.1

This document provides information that is typically difficult to find. The documentation of calling conventions and binary interfaces of compilers and operating systems is often shamefully poor and sometimes completely absent.

As most of the information given here is based on my own experiments, it is obviously not authoritative, and it is not guaranteed to be accurate or complete. This document tells how things are, not how they are supposed to be. Some details appear to be the haphazard consequences of how compilers happen to be implemented rather than results of careful planning. Calling “conventions” may not be the most appropriate term in this case, but it may be necessary to copy the quirks of existing compilers when full compatibility is desired. I have no knowledge about whether any information provided here is protected by patents or other legal restrictions, but I have found no specific patent markings on the compilers.

I have gathered this information mainly by converting C++ code to assembly. All the compilers I have tested are capable of converting C++ to assembly, either directly or via object files. The reader is encouraged to do your own research, if necessary, to get additional information needed or to clarify any questions you may have. The easiest way of doing this research is to make the compiler convert a C++ test file to assembly. Other possible methods are to use object file dump utilities, disassembly utilities, or provoke error messages from a linker. If you find any errors in this document then please let me know.

Please note that I don’t have the time and resources to help people with their programming problems. If you Email me with such questions, you will not get any answer. You may send your questions to appropriate internet forums instead.