Binary interface between two program units
In
computer software
, an
application binary interface
(
ABI
) is an
interface
between two binary program modules. Often, one of these modules is a
library
or
operating system
facility, and the other is a program that is being run by a user.
An ABI defines how data structures or computational routines are accessed in
machine code
, which is a low-level, hardware-dependent format. In contrast, an
application programming interface
(API) defines this access in
source code
, which is a relatively high-level, hardware-independent, often
human-readable
format. A common aspect of an ABI is the
calling convention
, which determines how data is provided as input to, or read as output from, computational routines. Examples of this are the
x86 calling conventions
.
Adhering to an ABI (which may or may not be officially standardized) is usually the job of a
compiler
, operating system, or library author. However, an application programmer may have to deal with an ABI directly when writing a program in a mix of programming languages, or even compiling a program written in the same language with different compilers.
Description
[
edit
]
Details covered by an ABI include the following:
- Processor instruction set, with details like register file structure, stack organization, memory access types, etc.
- Sizes, layouts, and
alignments
of basic
data types
that the processor can directly access
- Calling convention
, which controls how the arguments of
functions
are passed, and return values retrieved; for example, it controls the following:
- Whether all parameters are passed on the stack, or some are passed in registers
- Which registers are used for which function parameters
- Whether the first function parameter passed on the stack is pushed first or last
- Whether the caller or callee is responsible for cleaning up the stack after the function call
- 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
- In the case of a complete operating system ABI, the binary format of
object files
, program libraries, etc.
Complete ABIs
[
edit
]
A complete ABI, such as the
Intel Binary Compatibility Standard
(iBCS),
[1]
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.
ABIs can also standardize details such as the
C++ name mangling
,
[2]
exception
propagation,
[3]
and calling convention between compilers on the same platform, but do not require cross-platform compatibility.
Embedded ABIs
[
edit
]
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, for use with an
embedded operating system
.
Compilers
that support the EABI create
object code
that is compatible with code generated by other such compilers, allowing developers to link libraries generated with one compiler with object code generated with another compiler. Developers writing their own
assembly language
code may also interface with assembly generated by a compliant compiler.
EABIs are designed to optimize for performance within the limited resources of an embedded system. Therefore, EABIs omit most abstractions that are made between kernel and user code in complex operating systems. For example,
dynamic linking
may be avoided to allow smaller executables and faster loading, fixed register usage allows more compact stacks and kernel calls, and running the application in privileged mode allows direct access to custom hardware operation without the indirection of calling a device driver.
[4]
The choice of EABI can affect performance.
[5]
[6]
Widely used EABIs include
PowerPC
,
[4]
Arm
EABI
[7]
and
MIPS
EABI.
[8]
Specific software implementations like the C library may impose additional limitations to form more concrete ABIs; one example is the GNU OABI and EABI for ARM, both of which are subsets of the ARM EABI .
[9]
See also
[
edit
]
References
[
edit
]
External links
[
edit
]
|
---|
Parts and
conventions
| |
---|
Related topics
| |
---|