Application binary interface
ABIs cover details such as:
- the sizes, layout, and alignment of data types
- the calling convention, which controls how functions' arguments are passed and return values retrieved; for example, whether all parameters are passed on the stack or some are passed in registers, which registers are used for which function parameters, and whether the first function parameter passed on the stack is pushed first or last onto the stack
- how an application should make system calls to the operating system and, if the ABI specifies direct system calls rather than procedure calls to system call stubs, the system call numbers
- and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on.
A complete ABI, such as the Intel Binary Compatibility Standard (iBCS), allows a program from one operating system supporting that ABI to run without modifications on any other such system, provided that necessary shared libraries are present, and similar prerequisites are fulfilled.
Other ABIs standardize details such as the C++ name mangling, exception propagation, and calling convention between compilers on the same platform, but do not require cross-platform compatibility.
An ABI should not be confused with an application programming interface (API) which defines a library of routines to call, data structures to manipulate, and/or object classes to use in the construction of an application using that particular (often language specific) API.
An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.
Compilers that support the EABI create object code that is compatible with code generated by other such compilers, thus allowing developers to link libraries generated with one compiler with object code generated with a different compiler. Developers writing their own assembly language code may also use the EABI to interface with assembly generated by a compliant compiler.
The main differences of an EABI with respect to an ABI for general purpose operating systems are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes it is completely disallowed), and a more compact stack frame organization is used to save memory.
Compiler details 
- Microsoft Visual C++ ABI details
See also 
- Binary compatibility
- ABI Compliance Checker
- Comparison of application virtual machines
- Foreign function interface
- Language binding
- Opaque pointer
- PowerOpen Environment
- Upstream Tracker
- Intel Binary Compatibility Standard (iBCS)
- Itanium C++ ABI (compatible with multiple architectures)
- Itanium C++ ABI: Exception Handling (compatible with multiple architectures)
- "EABI Summary". PowerPC Embedded Application Binary Interface: 32-Bit Implementation (Version 1.0 ed.). Freescale Semiconductor, Inc. 1995-10-01. pp. 28–30.
- "PowerPC Embedded Processors Application Note"
- "Debian ARM accelerates via EABI port". Linuxdevices.com. 2007-01-19. Retrieved 2007-10-11.
- Andrés Calderón and Nelson Castillo (2007-03-14). "Why ARM's EABI matters". Linuxdevices.com. Archived from the original on 22 October 2007. Retrieved 2007-10-11.
- KDE Techbase Policies - Good compendium of development rules of thumb (with some examples) for not breaking binary compatibility between releases of your library.
- Mac OS X ABI Function Call Guide
- Debian ARM EABI port
- µClib: Motorola 8/16-bit embedded ABI
- AMD64 (x86-64) Application Binary Interface
- Application Binary Interface (ABI) for the ARM Architecture
- MIPS EABI documentation
- Sun Studio 10 Compilers and the AMD64 ABI - Good summary and comparison about some popular ABIs
- "M•CORE Applications Binary Interface Standards Manual" for the Freescale M·CORE processors