Introduction<\/p>\n
This is the fifth in a series of five manuals:<\/p>\n
The latest versions of these manuals are always available from www.agner.org\/optimize. Copyright conditions are listed on page 60 below.<\/p>\n
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.<\/p>\n
The purposes of publishing this information are:<\/p>\n
\u2022 Point out incompatibilities between compilers.<\/p>\n
\u2022 Make new compilers compatible with old ones.<\/p>\n
\u2022 Solve compatibility problems between function libraries produced by different compilers.<\/p>\n
\u2022 Facilitate linking different programming languages together.<\/p>\n
\u2022 Facilitate the making of assembly subroutines that are compatible with multiple compilers and multiple operating systems.<\/p>\n
\u2022 Solve compatibility problems for data stored in binary files.<\/p>\n
\u2022 Facilitate the construction of debugging, profiling and disassembly tools.<\/p>\n
\u2022 Facilitate the construction of object file conversion utilities.<\/p>\n
\u2022 Provoke compiler vendors to use open standards.<\/p>\n
\u2022 Inspire future standardization.<\/p>\n
Hardware platforms covered:<\/p>\n
\u2022 x86 microprocessors with 16 bit, 32 bit and 64 bit architectures from Intel, AMD, VIA and possibly other vendors.<\/p>\n
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.<\/p>\n
Operating systems covered:<\/p>\n
\u2022 DOS, 16 bit.<\/p>\n
\u2022 Windows, 16 bit, 32 bit and 64 bit.<\/p>\n
\u2022 Linux, 32 bit and 64 bit.<\/p>\n
\u2022 FreeBSD etc. 32 bit and 64 bit.<\/p>\n
\u2022 Mac OS X, Intel based, 32 bit and 64 bit.<\/p>\n
C++ compilers tested:<\/p>\n
\u2022 Borland, 16 bit v. 3.0 and 5.0<\/p>\n
\u2022 Microsoft, 16 bit, v. 8.0<\/p>\n
\u2022 Watcom, 16 bit v. 1.2<\/p>\n
\u2022 Borland 32 bit v. 5.0<\/p>\n
\u2022 Microsoft, 32 bit, v. 9.0, 13.10, 16.3<\/p>\n
\u2022 Gnu, 32 bit, v. 2.95, 3.3.3, 4.1.0 and several other versions under Linux, FreeBSD and Windows.<\/p>\n
\u2022 Watcom, 32 bit, v. 1.2<\/p>\n
\u2022 Symantec, 32 bit, v. 7.5<\/p>\n
\u2022 Digital Mars, 32 bit, v. 8.3.8<\/p>\n
\u2022 Codeplay VectorC, 32bit, v. 2.1.7<\/p>\n
\u2022 Intel, 32 bit for Windows and Linux, v. 8.1 and 9.1<\/p>\n
\u2022 Microsoft, 64 bit, v. 14.00, 16.3<\/p>\n
\u2022 Gnu, 64 bit, v. 3.3.3, 4.1.0, 7.4.0, 9.2.0 for Linux and Windows<\/p>\n
\u2022 Clang, 64 bit, v. 5.0, 9.0 for Linux and Windows<\/p>\n
\u2022 Intel, 64 bit for Windows and Linux, v. 8.1 and 9.1<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"