Content deleted Content added
Stevebroshar (talk | contribs) eliminate 'complete ABI' section since only the 1st paragraph was about that; moved that to intro and merged 2nd para into description list |
Guy Harris (talk | contribs) Multiple compilers for the *same* language, presumably; multiple compilers for multiple languages is usually the case. |
||
(12 intermediate revisions by 4 users not shown) | |||
Line 8:
An ABI is at a relatively low-level of [[abstraction (computer science)|abstraction]]. Interface compatibility depends on the target [[computer hardware|hardware]] and the [[software build]] [[toolchain]]. In contrast, an [[application programming interface]] (API) defines access in [[source code]] which is a relatively high-level, hardware-independent, and [[human-readable]] format. An API defines interface at the source code level, before compilation, whereas an ABI defines an interface to compiled code.
API compatibility is generally the concern for [[system design]] and of the toolchain. However, a [[programmer]] may have to deal with an ABI directly when writing a program in
A complete ABI
▲API compatibility is generally the concern for [[system design]] and of the toolchain. However, a [[programmer]] may have to deal with an ABI directly when writing a program in a multiple [[programming language|languages]] or [[compiler]]s.
▲A complete ABI, such as the [[Intel Binary Compatibility Standard]] (iBCS),<ref>[http://www.everything2.com/index.pl?node=iBCS Intel Binary Compatibility Standard (iBCS)]</ref> enables a program that supports an ABI to run without modification on multiple operating systems that provide the ABI. The target system must provide any required libraries (that implement the ABI), and there may be other prerequisites.
== Description ==
Interface aspects covered by an ABI include:
* [[Processor (computing)|Processor]] [[instruction set]], with details like register file structure,
* Size, layout, and [[Data structure alignment|alignment]] of basic [[data type]]s that the processor can directly access
* [[Calling convention]], which controls how the arguments of [[function (programming)|function]]s are passed, and return values retrieved; for example, it controls the following:
** How the [[call stack]] is organized
** Whether all parameters are passed on the call stack, or some are passed in registers ** Which registers are used for which function parameters
** Whether the first function parameter passed on the call stack is pushed first or last
** Whether the caller or callee is responsible for cleaning up the call stack after the function call
* [[
* [[exception handling|Exception]] propagation<ref>{{cite web|url=http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html|title=Itanium C++ ABI: Exception Handling}} (compatible with multiple architectures)</ref>
* How an application should make [[system call]]s to the operating system, and if the ABI specifies direct system calls rather than procedure calls to system call [[Method stub|stubs]], the system call numbers
* In the case of a complete operating system ABI, the binary format of [[object file]]s, program libraries, etc.
ABIs include the [[Intel Binary Compatibility Standard]] (iBCS)<ref>{{cite web |url=http://www.everything2.com/index.pl?node=iBCS |title=Intel Binary Compatibility Standard (iBCS)}}</ref> and the [[System V Release 4]] ABIs for various instruction sets.
== {{Anchor|EABI}}Embedded ABI ==
Line 62 ⟶ 63:
}}</ref>
Widely used EABIs include the [[PowerPC]],<ref name="ppc-eabi"/> [[Arm architecture|Arm]]
== See also ==
{{Portal|Computer programming}}
* {{Annotated link|Bytecode}}
▲* [[Binary-code compatibility]]
▲* [[Comparison of application virtualization software]]
▲* [[Debug symbol]]
▲* [[Foreign function interface]]
▲* [[Language binding]]
▲* [[Native (computing)]]
▲* [[Opaque pointer]]
▲* [[PowerOpen Environment]]
* {{Annotated link|SWIG}}
▲* [[Symbol table]]
▲* [[Visual C++#Compatibility|Visual C++ ABI instability details]]
==References==
|