WikiDer > Бинарный интерфейс приложения

Application binary interface

Высокоуровневое сравнение API-интерфейсов и ABI в ядре и между ядром и пользователем.
В Ядро Linux и Библиотека GNU C определить Linux API. После компиляции двоичные файлы предлагают ABI. Поддержание стабильности этого ABI в течение длительного времени важно для Независимые поставщики ПО.

В программное обеспечение, двоичный интерфейс приложения (ABI) является интерфейс между двумя двоичными программными модулями. Часто одним из этих модулей является библиотека или Операционная система объект, а другой - программа, запускаемая пользователем.

An ABI определяет способ доступа к структурам данных или вычислительным процедурам в Машинный код, который является низкоуровневым форматом, зависящим от оборудования. Напротив, API определяет этот доступ в исходный код, который является относительно высокоуровневым, аппаратно-независимым, часто человек читаемый формат. Общим аспектом ABI является соглашение о вызовах, который определяет, как данные предоставляются в качестве входных данных или считываются в качестве выходных данных вычислительных процедур. Примеры этого: соглашения о вызовах x86.

Соблюдение ABI (который может быть, а может и не быть официально стандартизированным) обычно является задачей компилятор, операционная система или автор библиотеки. Однако прикладному программисту, возможно, придется иметь дело с ABI напрямую при написании программы на смеси языков программирования или даже в разных компиляторах для одного и того же языка.

Описание

ABI охватывают такие детали, как:

  • набор инструкций процессора (с деталями, такими как структура файла регистров, организация стека, типы доступа к памяти, ...)
  • размеры, макеты и выравнивания основных типы данных что процессор может получить прямой доступ
  • то соглашение о вызовах, который контролирует, как аргументы функции передаются и возвращаются значения. Например, он контролирует:
    • все ли параметры передаются в стек, или некоторые передаются в регистрах;
    • какие регистры используются для каких параметров функции;
    • и будет ли первый или последний переданный в стек параметр функции помещается в стек первым или последним.
  • как приложение должно делать системные вызовы в операционную систему и, если ABI указывает прямые системные вызовы, а не вызовы процедур для заглушек системных вызовов, номера системных вызовов
  • а в случае полной операционной системы ABI, двоичный формат объектные файлы, программные библиотеки и так далее.

Полные ABI

Полный ABI, такой как Стандарт двоичной совместимости Intel (iBCS),[1] позволяет программе из одной операционной системы, поддерживающей этот ABI, запускаться без модификаций в любой другой такой системе при условии, что присутствуют необходимые разделяемые библиотеки и выполняются аналогичные предварительные условия.

Другой[который?] ABI стандартизируют такие детали, как Изменение имени C ++,[2] исключение распространение[3] и соглашение о вызовах между компиляторами на одной платформе, но не требуют кроссплатформенной совместимости.

Встроенные ABI

An двоичный интерфейс встроенного приложения (EABI) определяет стандартные соглашения для форматы файлов, типы данных, использование регистров, кадр стека организация и передача параметров функции встроенный программное обеспечение для использования с встроенная операционная система.

Компиляторы которые поддерживают создание EABI объектный код который совместим с кодом, созданным другими такими компиляторами, что позволяет разработчикам связывать библиотеки, созданные одним компилятором, с объектным кодом, созданным другим компилятором. Разработчики пишут свои собственные язык ассемблера код также может взаимодействовать со сборкой, созданной совместимым компилятором.

EABI предназначены для оптимизации производительности в рамках ограниченных ресурсов встроенной системы. Следовательно, EABI опускает большинство абстракций, которые делаются между ядром и пользовательским кодом в сложных операционных системах. Например, динамическое связывание можно избежать, чтобы позволить исполняемые файлы меньшего размера и более быструю загрузку, использование фиксированных регистров позволяет использовать более компактные стеки и вызовы ядра, а запуск приложения в привилегированном режиме обеспечивает прямой доступ к пользовательским операциям оборудования без косвенного вызова драйвера устройства.[4] Выбор EABI может повлиять на производительность.[5][6]

Широко используемые EABI включают: PowerPC,[4] Рука EABI[7] и MIPS EABI.[8] Конкретные программные реализации, такие как библиотека C, могут налагать дополнительные ограничения для формирования более конкретных ABI; одним из примеров является GNU OABI и EABI для ARM, которые являются подмножествами ARM EABI.[9]

Смотрите также

использованная литература

  1. ^ Стандарт двоичной совместимости Intel (iBCS)
  2. ^ "Itanium C ++ ABI". (совместим с несколькими архитектурами)
  3. ^ «Itanium C ++ ABI: обработка исключений». (совместим с несколькими архитектурами)
  4. ^ а б «Резюме EABI». Двоичный интерфейс встроенного приложения PowerPC: 32-разрядная реализация (PDF) (Версия 1.0 ред.). Freescale Semiconductor, Inc., 1 октября 1995 г., стр. 28–30.
  5. ^ «Debian ARM ускоряется через порт EABI». Linuxdevices.com. 16 октября 2016 г. Архивировано с оригинал 21 января 2007 г.. Получено 11 октября 2007.
  6. ^ Андрес Кальдерон и Нельсон Кастильо (14 марта 2007 г.). "Почему ARM EABI имеет значение". Linuxdevices.com. Архивировано из оригинал 31 марта 2007 г.. Получено 11 октября 2007.
  7. ^ «ABI для архитектуры Arm». Developer.arm.com. Получено 4 февраля 2020.
  8. ^ Эрик Кристофер (11 июня 2003 г.). "документация mips eabi". [email protected] (Список рассылки). Получено 19 июн 2020.
  9. ^ «АрмЭабиПорт». Debian Wiki. Строго говоря, и старый, и новый ARM ABI являются подмножествами спецификации ARM EABI, но в повседневном использовании термин «EABI» используется для обозначения описанного здесь нового, а «OABI» или «старый-ABI» - для обозначения старого. один.

внешние ссылки