ABI: интерфейс между двоичными модулями программ. Определяет доступ к данным в машинном коде, в отличие от API. Важно для совместимости и работы библиотек.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Бинарный интерфейс между двумя программными модулями
Binary interface between two program units
В компьютерном программном обеспечении интерфейс бинарного приложения (ABI) — это интерфейс между двумя модулями бинарной программы. Зачастую один из этих модулей представляет собой библиотеку или компонент операционной системы, а другой — программу, выполняемую пользователем. ABI определяет способ доступа к структурам данных или вычислительным подпрограммам в машинном коде, который представляет собой низкоуровневый, аппаратно-зависимый формат. В отличие от него, интерфейс прикладного программирования (API) определяет этот доступ в исходном коде, который является относительно высокоуровневым, аппаратно-независимым и часто читаемым человеком форматом. Важным аспектом ABI является соглашение о вызовах, определяющее, как данные передаются на вход или возвращаются из вычислительных подпрограмм. Примерами могут служить соглашения о вызовах x86. Соблюдение ABI (которое может быть официально стандартизировано или нет) обычно является задачей компилятора, операционной системы или разработчика библиотеки. Однако программисту приложения может потребоваться напрямую взаимодействовать с ABI при написании программы, использующей несколько языков программирования, или даже при компиляции программы, написанной на одном языке, с использованием различных компиляторов.
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.
Полные АБИ
Полный ABI, такой как Стандарт двоичной совместимости Intel (iBCS), позволяет программе, созданной для одной операционной системы, поддерживающей этот ABI, работать без изменений на любой другой системе с поддержкой того же ABI, при условии наличия необходимых общих библиотек и соблюдения других аналогичных требований. ABI также могут стандартизировать детали, такие как искажение имен в C++, распространение исключений и соглашения о вызовах между компиляторами на одной и той же платформе, но не требуют обеспечения кроссплатформенной совместимости.
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. ABIs can also 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.
Встроенные АБИ
Встроенный бинарный интерфейс приложения (EABI) определяет стандартные соглашения для форматов файлов, типов данных, использования регистров, организации стекового фрейма и передачи параметров функций встроенной программной программы, предназначенной для использования с встроенной операционной системой. Компиляторы, поддерживающие EABI, генерируют объектный код, совместимый с кодом, сгенерированным другими такими компиляторами, что позволяет разработчикам связывать библиотеки, созданные одним компилятором, с объектным кодом, сгенерированным другим компилятором. Разработчики, пишущие собственный код на языке ассемблера, также могут взаимодействовать с ассемблерным кодом, сгенерированным совместимым компилятором. EABI разрабатываются для оптимизации производительности в условиях ограниченных ресурсов встроенной системы. Поэтому EABI исключают большинство абстракций, применяемых между ядром и пользовательским кодом в сложных операционных системах. Например, динамическая компоновка может быть исключена для уменьшения размера исполняемых файлов и ускорения загрузки, фиксированное использование регистров позволяет создавать более компактные стеки и вызовы ядра, а запуск приложения в привилегированном режиме обеспечивает прямой доступ к аппаратному обеспечению без косвенного вызова драйвера устройства. Выбор EABI может влиять на производительность. Широко используемые EABI включают PowerPC и MIPS EABI. Конкретные программные реализации, такие как библиотека C, могут накладывать дополнительные ограничения для формирования более конкретных ABI; примером является GNU OABI и EABI для ARM, оба из которых являются подмножествами ARM EABI.
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. The choice of EABI can affect performance. Widely used EABIs include PowerPC, and MIPS EABI. 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 .