Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

Варианты [ править ]

Соглашения о вызовах могут отличаться:

  • Где размещаются параметры, возвращаемые значения и адреса возврата (в регистрах , в стеке вызовов , в сочетании того и другого или в других структурах памяти)
  • Для параметров, передаваемых в память, порядок, в котором передаются фактические аргументы для формальных параметров (или части большого или сложного аргумента).
  • Как возвращаемое значение (возможно, длинное или сложное) доставляется от вызываемого обратно вызывающему (в стеке, в регистре или в куче)
  • Как задача настройки и очистки после вызова функции распределяется между вызывающим и вызываемым
  • Передаются ли и как метаданные, описывающие аргументы
  • Где хранится предыдущее значение указателя кадра, которое используется для восстановления указателя кадра при завершении подпрограммы (в кадре стека или в каком-либо регистре)
  • Где размещаются любые ссылки статической области видимости для нелокального доступа к данным подпрограммы (обычно в одной или нескольких позициях в кадре стека, но иногда в общем регистре или, для некоторых архитектур, в регистрах специального назначения)
  • То, как выделяются локальные переменные, иногда также может быть частью соглашения о вызовах (когда вызывающий выделяет для вызываемого)

В некоторых случаях различия также включают следующее:

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

Многие архитектуры имеют только одно широко используемое соглашение о вызовах, часто предлагаемое архитектором. Для RISC, включая SPARC, MIPS и RISC-V , часто используются имена регистров, основанные на этом соглашении о вызовах. Например, MIPS регистры $4через $7иметь «ABI имен» $a0через $a3, отражая их использование для передачи параметров в стандартных вызовах. (У процессоров RISC есть много эквивалентных регистров общего назначения, поэтому обычно нет аппаратной причины давать им имена, кроме чисел.)

Хотя некоторые [ какие? ] языки программирования могут частично указывать последовательность вызовов в спецификации языка или в основной реализации, различные реализации таких языков (т. е. разные компиляторы ) могут по-прежнему использовать различные соглашения о вызовах, а реализация может предлагать выбор из более чем одного соглашения о вызовах. . Причины этого - производительность, частая адаптация к соглашениям других популярных языков с техническими причинами или без них, а также ограничения или соглашения, налагаемые различными « вычислительными платформами ».

Архитектура [ править ]

x86 (32-разрядная версия) [ править ]

Архитектура x86 используется с множеством различных соглашений о вызовах. Из-за небольшого количества архитектурных регистров и исторической ориентации на простоту и небольшой размер кода многие соглашения о вызовах x86 передают аргументы в стеке. Возвращаемое значение (или указатель на него) возвращается в регистре. Некоторые соглашения используют регистры для первых нескольких параметров, которые могут улучшить производительность, особенно для коротких и простых листовых подпрограмм, которые очень часто вызываются (то есть подпрограмм, которые не вызывают другие подпрограммы).

Пример вызова:

 нажать  EAX  ; передать результат некоторого регистра  push  dword  [ EBP + 20 ]  ; передать некоторую переменную памяти (синтаксис FASM / TASM)  push  3  ; передать некоторый постоянный  вызов  calc  ; возвращенный результат теперь в EAX

Типичная структура вызываемого объекта: ( некоторые или все (кроме ret) приведенные ниже инструкции могут быть оптимизированы с помощью простых процедур ). Некоторые соглашения оставляют пространство параметров выделенным, используя plain retвместо ret imm16. В этом случае вызывающий абонент может add esp,12в этом примере или иным образом иметь дело с изменением ESP.

calc:  push  EBP  ; сохранить указатель старого кадра  mov  EBP , ESP  ; получить новый указатель кадра  sub  ESP , localsize  ; зарезервировать место в стеке для местных жителей  .  .  ; произвести расчеты, оставить результат в EAX  .  mov  ESP , EBP  ; свободное место для местных жителей  поп  EBP  ; восстановить старый указатель кадра  ret  paramsize  ; свободное пространство параметров и возврат.

ARM (A32) [ править ]

Стандартное 32-битное соглашение о вызовах ARM выделяет 15 регистров общего назначения как:

  • r15: Программный счетчик (согласно спецификации набора команд).
  • r14: Ссылка на регистр. Инструкция BL, используемая в вызове подпрограммы, сохраняет адрес возврата в этом регистре.
  • r13: указатель стека. Команды Push / Pop в режиме работы «Thumb» используют только этот регистр.
  • r12: временный регистр внутрипроцедурного вызова.
  • от r4 до r11: локальные переменные.
  • от r0 до r3: значения аргументов, передаваемые подпрограмме, и результаты, возвращаемые подпрограммой.

Если тип возвращаемого значения слишком велик, чтобы поместиться в r0 - r3, или размер которого не может быть определен статически во время компиляции, то вызывающий должен выделить пространство для этого значения во время выполнения и передать указатель на это пространство в r0.

Подпрограммы должны сохранять содержимое от r4 до r11 и указатель стека (возможно, сохраняя их в стеке в прологе функции , затем используя их как временное пространство, а затем восстанавливая их из стека в эпилоге функции ). В частности, подпрограммы, которые вызывают другие подпрограммы, должны сохранять адрес возврата в регистре связи r14 в стек перед вызовом этих других подпрограмм. Однако таким подпрограммам не нужно возвращать это значение в r14 - им просто нужно загрузить это значение в r15, программный счетчик, чтобы вернуться.

Соглашение о вызовах ARM требует использования полного нисходящего стека. [1]

Это соглашение о вызовах заставляет "типичную" подпрограмму ARM:

  • В прологе вставьте r4 в r11 в стек и отправьте адрес возврата из r14 в стек (это можно сделать с помощью одной инструкции STM);
  • Скопируйте все переданные аргументы (от r0 до r3) в локальные временные регистры (от r4 до r11);
  • Назначьте другие локальные переменные оставшимся локальным временным регистрам (с r4 по r11);
  • Выполните вычисления и вызовите другие подпрограммы по мере необходимости с использованием BL, предполагая, что от r0 до r3, r12 и r14 не будут сохранены;
  • Результат записываем в r0;
  • В эпилоге вытащите из стека с r4 по r11, а адрес возврата - в программный счетчик r15. Это можно сделать с помощью одной инструкции LDM.

ARM (A64) [ править ]

64-битное соглашение о вызовах ARM ( AArch64 ) выделяет 31 регистр общего назначения как: [2]

  • x31 (SP): указатель стека или нулевой регистр, в зависимости от контекста.
  • x30 (LR): регистр ссылки на процедуру, используемый для возврата из подпрограмм.
  • x29 (FP): указатель кадра.
  • от x19 до x29: спасенный вызываемый.
  • x18 (PR): регистр платформы. Используется для некоторых специальных целей, связанных с операционной системой, или для дополнительного реестра, сохраненного вызывающим абонентом.
  • x16 (IP0) и x17 (IP1): временные регистры внутрипроцедурного вызова.
  • от x9 до x15: локальные переменные, вызывающий абонент сохранен.
  • x8 (XR): адрес косвенного возвращаемого значения.
  • от x0 до x7: значения аргументов, переданные в подпрограмму, и результаты, возвращаемые из нее.

Все регистры, начинающиеся с x, имеют соответствующий 32-битный регистр с префиксом w . Таким образом, 32-битный x0 называется w0.

Точно так же 32 регистра с плавающей запятой распределяются следующим образом: [3]

  • от v0 до v7: значения аргументов, передаваемые подпрограммой, и возвращаемые ею результаты.
  • от v8 до v15: сохраняется вызываемый абонент, но необходимо сохранить только нижние 64 бита.
  • от v16 до v31: локальные переменные, вызывающий абонент сохранен.

PowerPC [ править ]

Архитектура PowerPC имеет большое количество регистров, поэтому большинство функций могут передавать все аргументы в регистрах для одноуровневых вызовов. Дополнительные аргументы передаются в стек, и пространство для аргументов на основе регистров также всегда выделяется в стеке для удобства вызываемой функции в случае использования многоуровневых вызовов (рекурсивных или иных) и необходимости сохранения регистров. Это также используется в вариативных функциях , например printf(), где аргументы функции должны быть доступны как массив. Для всех процедурных языков используется единое соглашение о вызовах.

MIPS [ править ]

O32 [4] ABI является наиболее часто используется ABI, благодаря своему статусу оригинальной System V ABI для MIPS. [5] Он строго основан на стеке, и для передачи аргументов доступно только четыре регистра . Эта кажущаяся медлительность, наряду со старинной моделью с плавающей запятой только с 16 регистрами, способствовала распространению многих других соглашений о вызовах. ABI сформировался в 1990 году и никогда не обновлялся с 1994 года. Он определен только для 32-битных MIPS, но GCC создал 64-битный вариант под названием O64. [6]$a0-$a3

Для 64-битной версии чаще всего используется N64 ABI (не относящийся к Nintendo 64 ) от Silicon Graphics. Наиболее важным улучшением является то, что теперь доступно восемь регистров для передачи аргументов; Он также увеличивает количество регистров с плавающей запятой до 32. Существует также версия ILP32 под названием N32, которая использует 32-битные указатели для меньшего кода, аналогично x32 ABI . Оба работают в 64-битном режиме ЦП. [6]

Было предпринято несколько попыток заменить O32 32-битным ABI, больше напоминающим N32. Конференция 1995 года представила MIPS EABI, для которого 32-разрядная версия была очень похожей. [7] EABI вдохновил MIPS Technologies на предложение более радикального "NUBI" ABI, который дополнительно повторно использует регистры аргументов для возвращаемого значения. [8] MIPS EABI поддерживается GCC, но не LLVM; ни один из них не поддерживает NUBI.

Для всех O32 и N32 / N64 адрес возврата хранится в $raрегистре. Это автоматически устанавливается с использованием инструкций JAL(переход и ссылка) или JALR(переход и регистрация ссылки). Стек растет вниз.

SPARC [ править ]

Архитектура SPARC , в отличие от большинства архитектур RISC , построена на окнах регистров . В каждом окне регистров есть 24 доступных регистра: 8 - это входящие регистры (% i0-% i7), 8 - это «локальные» регистры (% l0-% l7), а 8 - «выходные» регистры (% о0-% о7). Регистры "in" используются для передачи аргументов вызываемой функции, и любые дополнительные аргументы должны быть помещены в стек.. Однако вызываемая функция всегда выделяет пространство для обработки потенциального переполнения окна регистров, локальных переменных и (на 32-битном SPARC) возврата структуры по значению. Чтобы вызвать функцию, нужно поместить аргументы функции, которая должна быть вызвана, в регистры «out»; когда функция вызывается, регистры "out" становятся регистрами "in", а вызываемая функция получает доступ к аргументам в своих регистрах "in". Когда вызываемая функция завершает свою работу, она помещает возвращаемое значение в первый входной регистр, который становится первым выходным регистром, когда вызываемая функция возвращается.

V System ABI , [9] , который большинство современные Unix следует -как система, передает первые шесть аргументов в «в» регистрах% i0 через% i5, оставляя% i6 для указателя кадра и% i7 для обратного адреса.

IBM System / 360 и последующие [ править ]

System / 360 IBM еще одна архитектура без аппаратного стека. Приведенные ниже примеры иллюстрируют соглашение о вызовах, используемое OS / 360 и его последователями до введения 64-разрядной архитектуры z / Architecture ; другие операционные системы для System / 360 могут иметь другие соглашения о вызовах.

Вызов программы:

 LA 1, ARGS Адрес списка аргументов загрузки L 15, = A (SUB) Загрузить адрес подпрограммы BALR 14,15 Переход к вызываемой подпрограмме 1 ...ARGS DC A (FIRST) Адрес 1-го аргумента DC A (ВТОРОЙ) ... DC A (ТРЕТИЙ) + X'80000000 'Последний аргумент 2

Вызываемая программа:

SUB EQU * Это точка входа в подпрограмму

Стандартная последовательность ввода:

 ИСПОЛЬЗОВАНИЕ *, 15 3 STM 14,12,12 (13) Сохранение регистров 4 ST 13, SAVE + 4 Сохранить адрес сохраненной области вызывающего абонента LA 12, SAVE Цепи сохранений СТ 12,8 (13) LR 13,12 ...

Стандартная последовательность возврата:

 L 13, СОХРАНИТЬ + 4 5 LM 14,12,12 (13) L 15, RETVAL 6 BR 14 Вернуться к вызывающемуСОХРАНИТЬ DS 18F Savearea 7

Заметки:

  1. В BALRмагазинах инструкции на адрес следующей команды (обратный адрес) в регистре указанного первым аргументом-регистр 14-и ветви на второй адрес аргумента в регистре 15.
  2. Вызывающий передает адрес списка адресов аргументов в регистре 1. Последний адрес имеет бит старшего разряда, установленный для обозначения конца списка. Это ограничивает программы, использующие это соглашение, до 31-битной адресации.
  3. Адрес вызываемой процедуры находится в регистре 15. Обычно он загружается в другой регистр, а регистр 15 не используется в качестве базового регистра.
  4. STMИнструкция сохраняет регистры 14, 15 и от 0 до 12 в зоне 72 байт , представленной вызывающей называется область хранения , на который указывает регистр 13. вызываемая процедура обеспечивает свою собственную область хранения для использования подпрограмм вызываемыми; адрес этой области обычно сохраняется в регистре 13 на протяжении всей процедуры. Следующие инструкции STMобновляют прямую и обратную цепочки, связывающие эту область сохранения с областью сохранения вызывающего абонента.
  5. Последовательность возврата восстанавливает регистры вызывающего абонента.
  6. Регистр 15 обычно используется для передачи возвращаемого значения.
  7. Статическое объявление области сохранения в вызываемой подпрограмме делает ее нереентерабельной и нерекурсивной ; программа с повторным входом использует динамическую область сохранения, полученную либо из операционной системы и освобождаемую при возврате, либо в памяти, передаваемой вызывающей программой.

В System / 390 ABI [10] и z / Architecture ABI, [11], используемых в Linux:

  • Регистры 0 и 1 изменчивы
  • Регистры 2 и 3 используются для передачи параметров и возврата значений.
  • Регистры 4 и 5 также используются для передачи параметров.
  • Регистр 6 используется для передачи параметров и должен быть сохранен и восстановлен вызываемым пользователем.
  • Регистры с 7 по 13 предназначены для использования вызываемым пользователем и должны быть им сохранены и восстановлены.
  • Регистр 14 используется для обратного адреса.
  • Регистр 15 используется как указатель стека
  • Регистры с плавающей запятой 0 и 2 используются для передачи параметров и возврата значений.
  • Регистры с плавающей запятой 4 и 6 предназначены для использования вызываемым пользователем и должны быть сохранены и восстановлены им.
  • В z / Architecture регистры с плавающей запятой 1, 3, 5 и с 7 по 15 предназначены для использования вызываемым пользователем.
  • Регистр доступа 0 зарезервирован для использования системой
  • Регистры доступа с 1 по 15 предназначены для использования вызываемым пользователем.

SuperH [ править ]

Примечание: «сохраненные» резервы для экономии вызываемых абонентов; то же самое и с «гарантированным».

68k [ править ]

Наиболее распространенное соглашение о вызовах для телефонов серии Motorola 68000 : [12] [13] [14] [15]

  • d0, d1, a0 и a1 - временные регистры
  • Все остальные регистры сохраняются вызываемыми
  • a6 - указатель кадра, который можно отключить с помощью параметра компилятора
  • Параметры помещаются в стек справа налево.
  • Возвращаемое значение сохраняется в d0

IBM 1130 [ править ]

IBM 1130 был небольшой 16-битным слово адресации машины. У него было всего шесть регистров плюс индикаторы состояния и не было стека. Регистры - это регистр адреса инструкции (IAR) , накопитель (ACC) , расширение накопителя (EXT) и три индексных регистра X1 – X3. Вызывающая программа отвечает за сохранение ACC, EXT, X1 и X2. [16] Есть две псевдооперации для вызова подпрограмм: CALLдля кодирования неперемещаемых подпрограмм, напрямую связанных с основной программой, и LIBFдля вызова перемещаемых библиотечных подпрограмм через вектор передачи . [17] Обе псевдооперации разрешаются в IAR филиала и магазина.( BSI) машинная инструкция, которая сохраняет адрес следующей инструкции по ее эффективному адресу (EA) и переходит к EA + 1.

Аргументы следуют за « BSIобычно это адреса аргументов из одного слова» - вызываемая процедура должна знать, сколько аргументов ожидать, чтобы она могла пропустить их при возврате. В качестве альтернативы аргументы можно передавать в регистрах. Функциональные подпрограммы возвращали результат в ACC для реальных аргументов или в области памяти, называемой псевдоаккумулятором вещественных чисел (FAC). Аргументы и адрес возврата были адресованы с использованием смещения значения IAR, хранящегося в первом месте подпрограммы.

 * Пример подпрограммы 1130 ENT SUB Объявление «SUB» внешней точкой входа SUB DC 0 Зарезервированное слово в точке входа, обычно кодируемое «DC * - *» * Код подпрограммы начинается здесь * Если были аргументы, адреса могут быть загружены косвенно из обратного адреса LDX I 1 SUB Загрузить X1 с адресом первого аргумента (например) ... * Последовательность возврата LD RES Загрузить целочисленный результат в ACC * Если аргументы не были предоставлены, косвенный переход к сохраненному адресу возврата BI SUB Если аргументы не были предоставлены КОНЕЦ ПОДПИСКИ

Подпрограммы в IBM 1130, CDC 6600 и PDP-8 (все три компьютера были представлены в 1965 году) сохраняют адрес возврата в первом месте подпрограммы. [18]

Соображения по реализации [ править ]

Эту вариативность необходимо учитывать при объединении модулей, написанных на нескольких языках, или при вызове API операционной системы или библиотеки с языка, отличного от того, на котором они написаны; в этих случаях необходимо уделять особое внимание согласованию соглашений о вызовах, используемых вызывающим и вызываемым объектами. Даже программа, использующая один язык программирования, может использовать несколько соглашений о вызовах, выбранных компилятором для оптимизации кода или указанных программистом.

Потоковый код [ править ]

Потоковый код возлагает всю ответственность за настройку и очистку после вызова функции в вызываемом коде. Вызывающий код ничего не делает, кроме списка вызываемых подпрограмм. Это помещает весь код настройки функции и очистки в одно место - пролог и эпилог функции - а не во многие места, где функция вызывается. Это делает многопоточный код наиболее компактным соглашением о вызовах.

Потоковый код передает все аргументы в стек. Все возвращаемые значения возвращаются в стек. Это делает наивные реализации медленнее, чем соглашения о вызовах, которые хранят больше значений в регистрах. Однако реализации многопоточного кода, которые кэшируют несколько верхних значений стека в регистрах, в частности адрес возврата, обычно работают быстрее, чем соглашения о вызове подпрограмм, которые всегда отправляют адрес возврата в стек. [19] [20] [21]

PL / I [ править ]

Соглашение о вызовах по умолчанию для программ, написанных на языке PL / I, передает все аргументы по ссылке , хотя при желании могут быть указаны другие соглашения. Аргументы обрабатываются по-разному для разных компиляторов и платформ, но обычно адреса аргументов передаются через список аргументов в памяти. Может быть передан окончательный скрытый адрес, указывающий на область, содержащую возвращаемое значение. Из-за большого разнообразия типов данных, поддерживаемых PL / I, дескриптор данных также может быть передан для определения, например, длины символьных или битовых строк, размера и границ массивов ( допинговых векторов ) или макета и содержимого. из структуры данных . Фиктивные аргументы создаются для аргументов, которые являются константами или не соответствуют типу аргумента, ожидаемого вызываемой процедурой.

См. Также [ править ]

  • Бинарный интерфейс приложения
  • Интерфейс прикладного программирования
  • Сравнение виртуальных машин приложений
  • Продолжение прохождения стиля
  • Интерфейс внешней функции
  • Привязка к языку
  • Изменение имени
  • Стек спагетти
  • SWIG
  • Оптимизация хвостового звонка

Ссылки [ править ]

  1. ^ «Стандарт вызова процедур для архитектуры ARM» (PDF) . 2012 г.
  2. ^ «Параметры в регистрах общего назначения» . Руководство программиста серии ARM Cortex-A для ARMv8-A . Проверено 12 ноября 2020 .
  3. ^ «Параметры в регистрах NEON и с плавающей запятой» . developer.arm.com . Проверено 13 ноября 2020 . CS1 maint: обескураженный параметр ( ссылка )
  4. ^ "Краткий справочник по набору инструкций MIPS32" .
  5. ^ Sweetman, Dominic. См. MIPS Run (2-е изд.). Издательство Морган Кауфманн . ISBN 0-12088-421-6.
  6. ^ a b "История MIPS ABI" .
  7. Кристофер, Эрик (11 июня 2003 г.). "Документация по mips eabi" . [email protected] (список рассылки) . Проверено 19 июня 2020 . CS1 maint: обескураженный параметр ( ссылка )
  8. ^ "НУБИ" .
  9. ^ Приложение System V для двоичного интерфейса SPARC Processor Supplement (3-е изд.).
  10. ^ "Приложение к двоичному интерфейсу приложения S / 390 ELF" .
  11. ^ "Дополнение к двоичному интерфейсу приложения zSeries ELF" .
  12. ^ Смит, доктор Майк. «Сравнение регистров SHARC (21k) и 68k» .
  13. ^ XGCC: Языковая система Gnu C / C ++ для встраиваемой разработки (PDF) . Корпорация встроенных средств поддержки. 2000. с. 59.
  14. ^ "COLDFIRE / 68K: ThreadX для семейства Freescale ColdFire" . Архивировано из оригинала на 2015-10-02.
  15. ^ Мошовос, Андреас. «Продолжение подпрограмм: передача аргументов, возврат значений и выделение локальных переменных» . все регистры, кроме d0, d1, a0, a1 и a7, должны сохраняться во время вызова.
  16. ^ Корпорация IBM (1967). Система IBM 1130 Disk Monitor, версия 2 - Введение в систему (C26-3709-0) (PDF) . п. 67 . Проверено 21 декабря 2014 . CS1 maint: обескураженный параметр ( ссылка )
  17. ^ Корпорация IBM (1968). Язык ассемблера IBM 1130 (C26-5927-4) (PDF) . С. 24–25.
  18. ^ Smotherman, Марк (2004). «Поддержка вызова подпрограмм и процедур: ранняя история» .
  19. ^ Родригес, Брэд. «Движение вперед, часть 1: проектные решения в ядре четвертого поколения» . На 6809 или Zilog Super8 DTC быстрее, чем STC.
  20. ^ Эртль, Антон. «Скорость различных приемов диспетчеризации переводчиков» .
  21. Перейти ↑ Zaleski, Mathew (2008). «Глава 4: Разработка и внедрение эффективной интерпретации» . YETI: ПОСТЕПЕННО расширяемый интерпретатор трассировки . Хотя известно, что у прямопоточных интерпретаторов плохие свойства предсказания ветвлений ... задержка вызова и возврата может быть больше, чем косвенный переход.

Внешние ссылки [ править ]

  • Джонсон, Стивен Кертис ; Ричи, Деннис МакАлистер (сентябрь 1981 г.). "Технический отчет по информатике № 102: Последовательность вызовов языка C" . Bell Laboratories .
  • Введение в сборку на PowerPC
  • Руководство по вызову функций ABI в Mac OS X
  • Стандарт вызова процедур для архитектуры ARM
  • Встроенное программирование с помощью GNU Toolchain, Раздел 10. Запуск C