Application binary interface

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.

A high-level comparison of in-kernel and kernel-to-userspace APIs and ABIs
Linux kernel and GNU C Library define the Linux API. After compilation, the binaries offer an ABI; keeping this ABI stable over a long time is important for ISVs.

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 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 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 different compilers for the same language).

Description

ABIs cover details such as:

  • a processor instruction set (with details like register file structure, stack organization, memory access types, ...)
  • the sizes, layouts, and alignments of basic data types that the processor can directly access
  • the calling convention, which controls how functions' arguments are passed and return values are 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.

Complete ABIs

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.

Other ABIs 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

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 is 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]

gollark: And they're actively working to decrease power consumption since it costs them things, while, again, mining basically just consumes as much as possible.
gollark: It's possible, but they're much more efficient in terms of things done per joule.
gollark: Proof of work is directly a competition to waste the most power.
gollark: Servers are actually really efficient nowadays.
gollark: No.

See also

References
  1. Intel Binary Compatibility Standard (iBCS)
  2. "Itanium C++ ABI". (compatible with multiple architectures)
  3. "Itanium C++ ABI: Exception Handling". (compatible with multiple architectures)
  4. "EABI Summary". PowerPC Embedded Application Binary Interface: 32-Bit Implementation (PDF) (Version 1.0 ed.). Freescale Semiconductor, Inc. 1 October 1995. pp. 28–30.
  5. "Debian ARM accelerates via EABI port". Linuxdevices.com. 16 October 2016. Archived from the original on 21 January 2007. Retrieved 11 October 2007.
  6. Andrés Calderón and Nelson Castillo (14 March 2007). "Why ARM's EABI matters". Linuxdevices.com. Archived from the original on 31 March 2007. Retrieved 11 October 2007.
  7. "ABI for the Arm Architecture". Developer.arm.com. Retrieved 4 February 2020.
  8. Eric Christopher (11 June 2003). "mips eabi documentation". binutils@sources.redhat.com (Mailing list). Retrieved 19 June 2020.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.