Соглашения о вызовах X86 - X86 calling conventions

В этой статье описывается соглашения о вызовах используется при программировании x86 архитектура микропроцессоры.

Соглашения о вызовах описывают интерфейс вызываемого кода:

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

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

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

Историческое прошлое

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

Ранние микрокомпьютеры до Commodore Pet и Яблоко II обычно поставляется без ОС и компиляторов. В IBM PC пришел с предшественником Microsoft Windows, Дисковой Операционной Системой (ДОС ), но в комплекте не было компилятора. Единственное оборудование стандарт за IBM PC-совместимый машин был определен Процессоры Intel (8086, 80386) и буквально поставляемое IBM оборудование. Расширения оборудования и все стандарты программного обеспечения (за исключением BIOS Call Convention) были открыты для рыночной конкуренции.

Множество независимых фирм по разработке программного обеспечения предлагали операционные системы, компиляторы для многих языков программирования и приложения. Фирмы реализовали множество различных схем вызова, часто взаимоисключающих, на основе различных требований, исторической практики и творческого потенциала программистов.

После потрясения IBM-совместимого рынка Microsoft операционные системы и инструменты программирования (с разными соглашениями) преобладали, в то время как фирмы второго уровня, такие как Borland и Novell, и проекты с открытым исходным кодом, такие как GCC, по-прежнему сохраняли свои стандарты. Положения для совместимость между поставщиками и продуктами в конечном итоге были приняты, что упростило проблему выбора жизнеспособного соглашения.^[1]

Очистка вызывающего абонента

В этих соглашениях вызывающий объект очищает аргументы из стека.

cdecl

В cdecl (что означает Декларация C) - это соглашение о вызовах, исходящее от компилятора Microsoft для Язык программирования C и используется многими компиляторами C для архитектура x86.^[1] В cdecl аргументы подпрограммы передаются в куча. Целочисленные значения и адреса памяти возвращаются в EAX. регистр, значения с плавающей запятой в ST0 x87 регистр. Регистры EAX, ECX и EDX сохраняются для вызывающего абонента, а остальные - для вызываемого абонента. В x87 Регистры с плавающей запятой от ST0 до ST7 должны быть пустыми (извлечены или освобождены) при вызове новой функции, а регистры ST1 до ST7 должны быть пустыми при выходе из функции. ST0 также должен быть пустым, если не используется для возврата значения.

В контексте языка программирования C аргументы функции помещаются в стек в порядке справа налево, то есть последний аргумент помещается первым.

Рассмотрим следующий фрагмент исходного кода C:

int вызываемый(int, int, int);int звонящий(пустота){	возвращаться вызываемый(1, 2, 3) + 5;}

На x86, это может привести к следующему код сборки (Синтаксис Intel ):

звонящий:    ; сделать новый кадр вызова    ; (некоторые компиляторы могут вместо этого выдавать команду ввода)    толкать    ebp       ; сохранить старую рамку вызова    mov     ebp, особенно  ; инициализировать новый кадр вызова    ; аргументы push-вызова в обратном порядке    ; (некоторые компиляторы могут вычитать необходимое пространство из указателя стека,    ; затем напишите каждый аргумент напрямую, см. ниже.    ; Инструкция 'enter' тоже может делать нечто подобное)    ; sub esp, 12: инструкция 'enter' может сделать это за нас    ; mov [ebp-4], 3: или mov [esp + 8], 3    ; mov [ebp-8], 2: или mov [esp + 4], 2    ; mov [ebp-12], 1: или mov [esp], 1    толкать    3    толкать    2    толкать    1    вызов    вызываемый    ; вызов подпрограммы "вызываемый"    Добавить     особенно, 12   ; удалить аргументы вызова из кадра    Добавить     eax, 5    ; изменить результат подпрограммы                      ; (eax - это возвращаемое значение нашего вызываемого,                      ; поэтому нам не нужно перемещать его в локальную переменную)    ; восстановить старую рамку вызова    ; (некоторые компиляторы могут вместо этого выдавать инструкцию выхода)    mov     особенно, ebp  ; большинство соглашений о вызовах диктуют, что ebp должен быть сохранен вызываемым,                      ; т.е. сохраняется после вызова вызываемого абонента.                      ; поэтому он по-прежнему указывает на начало нашего кадра стека.                      ; нам нужно убедиться                      ; вызываемый абонент не изменяет (и не восстанавливает) ebp,                      ; поэтому нам нужно убедиться                      ; он использует соглашение о вызовах, которое делает это    поп     ebp       ; восстановить старую рамку вызова    Ret               ; возвращаться

Вызывающий очищает стек после возврата из вызова функции.

В cdecl соглашение о вызовах обычно является соглашением о вызовах по умолчанию для x86 C компиляторы, хотя многие компиляторы предоставляют опции для автоматического изменения используемых соглашений о вызовах. Чтобы вручную определить функцию как cdecl, некоторые поддерживают следующий синтаксис:

return_type __cdecl func_name();

Вариации

Есть несколько вариантов интерпретации cdecl. В результате программы x86, скомпилированные для разных платформ операционных систем и / или разными компиляторами, могут быть несовместимы, даже если они оба используют соглашение «cdecl» и не обращаются к базовой среде.

Что касается того, как возвращать значения, некоторые компиляторы возвращают простые структуры данных с длиной 2 или менее регистров в паре регистров EAX: EDX, а также более крупные структуры и объекты классов, требующие специальной обработки обработчиком исключений (например, определенный конструктор, деструктор или присваивание) возвращаются в память. Для передачи «в память» вызывающий объект выделяет память и передает на нее указатель в качестве скрытого первого параметра; вызываемый объект заполняет память и возвращает указатель, выдвигая скрытый указатель при возврате.^[2]

В Linux, GCC устанавливает де-факто стандарт для соглашений о вызовах. Начиная с версии 4.5 GCC, стек должен быть выровнен по 16-байтовой границе при вызове функции (предыдущие версии требовали только 4-байтового выравнивания).^[1][3]

Версия cdecl описан в System V ABI для систем i386.^[4]

системный вызов

Это похоже на cdecl в том, что аргументы сдвигаются справа налево. EAX, ECX и EDX не сохраняются. Размер списка параметров в двойных словах передается в AL.

Системный вызов - это стандартное соглашение о вызовах для 32-битных OS / 2 API.

optlink

Аргументы сдвигаются справа налево. Три первых (крайних левых) аргумента передаются в EAX, EDX и ECX, и до четырех аргументов с плавающей запятой передаются в ST0 по ST3, хотя место для них зарезервировано в списке аргументов в стеке. Результаты возвращаются в EAX или ST0. Регистры EBP, EBX, ESI и EDI сохраняются.

Optlink используется IBM VisualAge компиляторы.

Очистка Callee

В этих соглашениях вызываемый объект очищает аргументы из стека. Функции, использующие эти соглашения, легко распознать в коде ASM, потому что они раскручивают стек после возврата. X86 Ret Инструкция позволяет использовать необязательный 16-битный параметр, который указывает количество байтов стека, которые нужно освободить после возврата к вызывающей стороне. Такой код выглядит так:

Ret 12

Конвенции под названием быстрый звонок или же регистр не были стандартизированы и были реализованы по-разному, в зависимости от поставщика компилятора.^[1] Обычно соглашения о вызовах на основе регистров передают в регистры один или несколько аргументов, что сокращает количество обращений к памяти, необходимых для вызова, и, таким образом, обычно делает их быстрее.

паскаль

На основе Borland Pascal В соответствии с соглашением о вызовах языка программирования параметры помещаются в стек в порядке слева направо (в противоположность cdecl), а вызываемый объект отвечает за их удаление из стека.

Возврат результата работает следующим образом:

• Порядковые значения возвращаются в форматах AL (8-битные значения), AX (16-битные значения), EAX (32-битные значения) или DX: AX (32-битные значения в 16-битных системах).
• Реальные значения возвращаются в формате DX: BX: AX.
• Значения с плавающей запятой (8087) возвращаются в ST0.
• Указатели возвращаются в EAX в 32-битных системах и в AX в 16-битных системах.
• Строки возвращаются во временном месте, указанном символом @Result.

Это соглашение о вызовах было распространено в следующих 16-битных API: OS / 2 1.x, Майкрософт Виндоус 3.x и Borland Delphi версия 1.x. Современные версии использования Windows API stdcall, в котором вызываемый объект по-прежнему восстанавливает стек, как в соглашении Паскаля, но параметры теперь сдвигаются справа налево.

stdcall

Стандартный вызов^[5] Соглашение о вызовах - это вариант соглашения о вызовах Паскаля, в котором вызываемый объект отвечает за очистку стека, но параметры помещаются в стек в порядке справа налево, как в соглашении о вызовах _cdecl. Регистры EAX, ECX и EDX предназначены для использования в функции. Возвращаемые значения хранятся в регистре EAX.

stdcall - стандартное соглашение о вызовах для Microsoft Win32 API и для Откройте Watcom C ++.

Microsoft fastcall

Microsoft __fastcall конвенция (ака __msfastcall) передает первые два аргумента (оцениваемые слева направо), которые подходят для ECX и EDX.^[6] Остальные аргументы помещаются в стек справа налево. Когда компилятор компилируется для IA64 или же AMD64, он игнорирует __fastcall ключевое слово и использует одно 64-битное соглашение о вызовах вместо.

Как очень распространенное соглашение о вызовах, другие компиляторы, такие как GCC, Clang и ICC, также поддерживают fastcall.^[7]

Microsoft vectorcall

В Visual Studio 2013 Microsoft представила __vectorcall соглашение о вызовах в ответ на вопросы эффективности разработчиков игр, графики, видео / аудио и кодеков. Схема позволяет использовать векторные типы большего размера (плавать, двойной, __m128, __m256) для передачи в регистры, а не в стек.^[8]

Для кода IA-32 и x64, __vectorcall похоже на __fastcall и оригинальный x64 соглашения о вызовах соответственно, но расширяет их для поддержки передачи векторных аргументов с использованием SIMD регистры. В IA-32 целые значения передаются как обычно, а первые шесть SIMD (XMM /YMM 0-5) регистры содержат до шести значений с плавающей запятой, векторов или значений HVA последовательно слева направо, независимо от фактических позиций, вызванных, например, между ними возникает аргумент типа int. В x64, однако, по-прежнему применяется правило исходного соглашения x64, так что XMM / YMM0-5 содержат только аргументы с плавающей запятой, векторные или HVA, когда они оказываются с первого по шестой.^[9]

__vectorcall Добавлена ​​поддержка передачи значений однородных векторных агрегатов (HVA), которые являются составными типами (структурами), состоящими только из четырех идентичных векторных типов с использованием одних и тех же шести регистров. После того, как регистры были выделены для аргументов векторного типа, неиспользуемые регистры назначаются аргументам HVA слева направо. Правила позиционирования по-прежнему действуют. Результирующий векторный тип и значения HVA возвращаются с использованием первых четырех регистров XMM / YMM.^[9]

Компилятор clang и компилятор Intel C ++ также реализуют vectorcall.^[10] Компилятор Intel C ++ имел аналогичное ранее соглашение, называемое __regcall; он также поддерживается clang.^[11]

Регистр Borland

Оценивая аргументы слева направо, он передает три аргумента через EAX, EDX, ECX. Остальные аргументы помещаются в стек, также слева направо.^[12] Это стандартное соглашение о вызовах 32-разрядного компилятора Delphi, где он известен как регистр. Это соглашение о вызовах также используется Embarcadero C ++ Builder, где оно называется __fastcall.^[13] В этом компиляторе Microsoft быстрый звонок может использоваться как __msfastcall.^[14]

GCC и Clang можно заставить использовать аналогичное соглашение о вызовах, используя __stdcall с перегруппировать атрибут функции или -mregparm = 3 выключатель. (Порядок стека инвертируется.) Также можно создать вариант очистки вызывающего абонента, используя cdecl или расширить это, чтобы также использовать регистры SSE.^[15] А cdeclВерсия на основе Linux используется ядром Linux на i386, начиная с версии 2.6.20 (выпущена в феврале 2007 г.).^[16]

Регистр Watcom

Watcom не поддерживает __fastcall ключевое слово, кроме присвоения ему псевдонима null. Соглашение о вызове регистра может быть выбрано переключателем командной строки. (Тем не мение, ИДА использует __fastcall во всяком случае для единообразия.)

Аргументам назначается до 4 регистров в порядке EAX, EDX, EBX, ECX. Аргументы присваиваются регистрам слева направо. Если какой-либо аргумент не может быть назначен регистру (например, он слишком велик), он и все последующие аргументы назначаются стеку. Аргументы, присвоенные стеку, сдвигаются справа налево. Имена искажаются добавлением суффикса подчеркивания.

Функции Variadic возвращаются к соглашению о вызовах на основе стека Watcom.

Компилятор Watcom C / C ++ также использует #pragma aux^[17] директива, которая позволяет пользователю указать собственное соглашение о вызовах. Как говорится в руководстве, «этот метод, вероятно, понадобится очень немногим пользователям, но если он понадобится, он может быть спасением».

TopSpeed ​​/ Clarion / JPI

Первые четыре целочисленных параметра передаются в регистры eax, ebx, ecx и edx. Параметры с плавающей запятой передаются в стек с плавающей запятой - регистры st0, st1, st2, st3, st4, st5 и st6. Параметры структуры всегда передаются в стек. Дополнительные параметры передаются в стек после того, как регистры исчерпаны. Целочисленные значения возвращаются в eax, указатели - в edx, а типы с плавающей запятой - в st0.

безопасный звонок

В Delphi и Free Pascal на Майкрософт Виндоус, соглашение о вызовах safecall инкапсулирует COM (Компонентная объектная модель ) обработки ошибок, поэтому исключения не передаются вызывающему, а сообщаются в HRESULT возвращаемое значение, как того требует COM / OLE. При вызове функции safecall из кода Delphi Delphi также автоматически проверяет возвращенное значение HRESULT и при необходимости вызывает исключение.

Соглашение о вызове safecall такое же, как соглашение о вызове stdcall, за исключением того, что исключения передаются обратно вызывающей стороне в EAX как HResult (вместо FS: [0]), а результат функции передается по ссылке в стеке как хотя это был последний параметр "out". При вызове функции Delphi из Delphi это соглашение о вызовах будет выглядеть так же, как любое другое соглашение о вызовах, потому что, хотя исключения передаются обратно в EAX, они автоматически преобразуются вызывающим обратно в соответствующие исключения. При использовании COM-объектов, созданных на других языках, HResults будут автоматически возникать как исключения, а результат для функций Get будет в результате, а не в параметре. При создании COM-объектов в Delphi с помощью safecall нет необходимости беспокоиться о HResults, поскольку исключения могут возникать как обычно, но на других языках они будут отображаться как HResults.

функция имя_функции(а: DWORD): DWORD; безопасный звонок;

Возвращает результат и вызывает исключения, как обычная функция Delphi, но передает значения и исключения, как если бы это было:

функция имя_функции(а: DWORD; из Результат: DWORD): HResult; stdcall;

Очистка вызывающего или вызываемого абонента

этот звонок

Это соглашение о вызовах используется для вызова нестатических функций-членов C ++. Есть две основные версии этот звонок используется в зависимости от компилятора и от того, использует ли функция переменное количество аргументов.

Для компилятора GCC, этот звонок почти идентичен cdecl: Вызывающий объект очищает стек, и параметры передаются в порядке справа налево. Разница заключается в добавлении это указатель, который помещается в стек последним, как если бы он был первым параметром в прототипе функции.

В компиляторе Microsoft Visual C ++ это указатель передается в ECX, и это вызываемый очищает стек, отражая stdcall соглашение, используемое в C для этого компилятора и в функциях Windows API. Когда функции используют переменное количество аргументов, именно вызывающая сторона очищает стек (см. cdecl).

В этот звонок соглашение о вызовах может быть явно указано только в Microsoft Visual C ++ 2005 и более поздних версиях. На любом другом компиляторе этот звонок не ключевое слово. (Однако дизассемблеры, такие как ИДА, необходимо указать это. Итак, IDA использует ключевое слово __thiscall за это.)

Регистрация сохранения

Другая часть соглашения о вызовах заключается в том, что регистры гарантированно сохранят свои значения после вызова подпрограммы.

Сохраненные (энергозависимые) регистры вызывающего абонента

Согласно Intel ABI, которому соответствует подавляющее большинство компиляторов, EAX, EDX и ECX должны быть бесплатными для использования в рамках процедуры или функции и не должны сохраняться.^{[нужна цитата ]}.

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

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

Сохраненные вызываемым абонентом (энергонезависимые) регистры

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

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

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

соглашения о вызовах x86-64

Соглашения о вызовах x86-64 используют дополнительное пространство регистров для передачи большего количества аргументов в регистры. Также было уменьшено количество несовместимых соглашений о вызовах. Обычно используются два.

Соглашение о вызовах Microsoft x64

Соглашение о вызовах Microsoft x64^[18][19] следует на Windows и перед загрузкой UEFI (за длинный режим на x86-64 ). Первые четыре аргумента помещаются в регистры. Это означает RCX, RDX, R8, R9 для целочисленных аргументов, аргументов структуры или указателя (в этом порядке) и XMM0, XMM1, XMM2, XMM3 для аргументов с плавающей запятой. Дополнительные аргументы помещаются в стек (справа налево). Целочисленные возвращаемые значения (аналогичные x86) возвращаются в RAX, если 64 бита или меньше. Возвращаемые значения с плавающей запятой возвращаются в XMM0. Параметры длиной менее 64 бит не расширяются до нуля; старшие биты не обнуляются.

Структуры и объединения с размерами, соответствующими целым числам, передаются и возвращаются, как если бы они были целыми числами. В противном случае они заменяются указателем при использовании в качестве аргумента. Когда требуется возврат слишком большой структуры, в качестве первого аргумента добавляется другой указатель на пространство, предоставленное вызывающей стороной, сдвигая все остальные аргументы вправо на одно место.^[20]

При компиляции для архитектуры x64 в контексте Windows (с использованием инструментов Microsoft или сторонних производителей) stdcall, thiscall, cdecl и fastcall разрешают использование этого соглашения.

Согласно соглашению о вызовах Microsoft x64, вызывающий должен выделить 32 байта «теневого пространства» в стеке прямо перед вызовом функции (независимо от фактического количества используемых параметров) и вставить стек после вызова. Теневое пространство используется для разлива RCX, RDX, R8 и R9,^[21] но должен быть доступен для всех функций, даже для тех, у которых меньше четырех параметров.

Регистры RAX, RCX, RDX, R8, R9, R10, R11 считаются энергозависимыми (сохранены вызывающими).^[22]

Регистры RBX, RBP, RDI, RSI, RSP, R12, R13, R14 и R15 считаются энергонезависимыми (с сохранением вызываемого).^[22]

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

В x86-64, Visual Studio 2008 хранит числа с плавающей запятой в XMM6 и XMM7 (а также от XMM8 до XMM15); следовательно, для x86-64, подпрограммы на языке ассемблера, написанные пользователем, должны сохранять XMM6 и XMM7 (по сравнению с x86 при этом написанные пользователем подпрограммы на языке ассемблера не нуждались в сохранении XMM6 и XMM7). Другими словами, подпрограммы на языке ассемблера, написанные пользователем, должны быть обновлены для сохранения / восстановления XMM6 и XMM7 до / после функции при переносе из x86 к x86-64.

Начиная с Visual Studio 2013, Microsoft представила __vectorcall соглашение о вызовах, расширяющее соглашение x64.

Система V AMD64 ABI

Соглашение о вызовах Система V AMD64 ABI следует на Солярис, Linux, FreeBSD, macOS,^[23] и является стандартом де-факто среди Unix и Unix-подобных операционных систем. Первые шесть целочисленных аргументов или аргументов-указателей передаются в регистры RDI, RSI, RDX, RCX, R8, R9 (R10 используется как статический указатель цепочки в случае вложенных функций^[24]:21), тогда как XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6 и XMM7 используются для первых аргументов с плавающей запятой.^[24]:22 Как и в соглашении о вызовах Microsoft x64, в стек передаются дополнительные аргументы.^[24]:22 Целочисленные возвращаемые значения размером до 64 бит хранятся в RAX, а значения до 128 битов хранятся в RAX и RDX. Возвращаемые значения с плавающей запятой аналогичным образом сохраняются в XMM0 и XMM1.^[24]:25 Более широкие регистры YMM и ZMM используются для передачи и возврата более широких значений вместо XMM, когда они существуют.^[24]:26,55

Если вызываемый желает использовать регистры RBX, RSP, RBP и R12 – R15, он должен восстановить их исходные значения перед возвратом управления вызывающему. Все остальные регистры должны быть сохранены вызывающей стороной, если она желает сохранить их значения.^[24]:16

Для функций листовых узлов (функций, которые не вызывают никаких других функций) 128-байтовое пространство хранится сразу под указателем стека функции. Пространство называется Красная зона. Эта зона не будет заблокирована обработчиками сигналов или прерываний. Таким образом, компиляторы могут использовать эту зону для сохранения локальных переменных. Компиляторы могут пропустить некоторые инструкции при запуске функции (настройка RSP, RBP), используя эту зону. Однако другие функции могут сбивать эту зону. Следовательно, эту зону следует использовать только для функций листовых узлов. gcc и лязгать предложить -мно-красная-зона флаг, чтобы отключить оптимизацию красной зоны.

Если вызываемый вариативная функция, то количество аргументов с плавающей запятой, переданных функции в векторных регистрах, должно быть предоставлено вызывающей стороной в регистре AL.^[24]:55

В отличие от соглашения о вызовах Microsoft, теневое пространство не предусмотрено; при входе в функцию адрес возврата находится рядом с седьмым целочисленным аргументом в стеке.

Список соглашений о вызовах x86

Это список соглашений о вызовах x86.^[1] Это соглашения, в основном предназначенные для компиляторов C / C ++ (особенно для 64-битной части ниже) и, следовательно, в основном для особых случаев. Другие языки могут использовать другие форматы и соглашения в своих реализациях.

Архитектура	Имя	Операционная система, компилятор	Параметры		Очистка стека	Примечания
			Регистры	Порядок стека
8086	cdecl			RTL (К)	Звонящий
	Паскаль			LTR (Паскаль)	Callee
	fastcall (не член)	Microsoft	AX, DX, BX	LTR (Паскаль)	Callee	Указатель возврата в BX.
	fastcall (функция-член)	Microsoft	AX, DX	LTR (Паскаль)	Callee	это по младшему адресу стека. Указатель возврата в AX.
	быстрый звонок	Турбо С[25]	AX, DX, BX	LTR (Паскаль)	Callee	это по младшему адресу стека. Указатель возврата на верхний адрес стека.
		Watcom	AX, DX, BX, CX	RTL (К)	Callee	Указатель возврата в SI.
IA-32	cdecl	Unix-подобный (GCC )		RTL (К)	Звонящий	При возврате структуры / класса вызывающий код выделяет пространство и передает указатель на это пространство через скрытый параметр в стеке. Вызываемая функция записывает возвращаемое значение по этому адресу. Стек выровнен по 16-байтовой границе из-за ошибки.
	cdecl	Microsoft		RTL (К)	Звонящий	При возврате структуры / класса Обычные старые данные (POD) возвращаемые значения 32 бита или меньше находятся в регистре EAX Возвращаемые значения POD размером 33–64 бита возвращаются через регистры EAX: EDX. Значения, не возвращаемые POD, или значения, превышающие 64-битные, вызывающий код выделяет пространство и передает указатель на это пространство через скрытый параметр в стеке. Вызываемая функция записывает возвращаемое значение по этому адресу. Стек выровнен по 4-байтовой границе.
	stdcall	Microsoft		RTL (К)	Callee	Также поддерживается GCC.
	быстрый звонок	Microsoft	ECX, EDX	RTL (К)	Callee	Указатель возврата в стеке, если не функция-член. Также поддерживается GCC.
	регистр	Delphi и Free Pascal	EAX, EDX, ECX	LTR (Паскаль)	Callee
	этот звонок	Windows (Microsoft Visual C ++ )	ECX	RTL (К)	Callee	По умолчанию для функций-членов.
	вектор	Windows (Microsoft Visual C ++ )	ECX, EDX, [XY] MM0–5	RTL (К)	Callee	Расширенный от fastcall. Также поддерживается ICC и Clang.[9]
		Компилятор Watcom	EAX, EDX, EBX, ECX	RTL (К)	Callee	Указатель возврата в ESI.
x86-64	Соглашение о вызовах Microsoft x64[18]	Windows (Microsoft Visual C ++, GCC, Компилятор Intel C ++, Delphi ), UEFI	RCX / XMM0, RDX / XMM1, R8 / XMM2, R9 / XMM3	RTL (К)	Звонящий	Стек выровнен по 16 байтам. 32 байта теневого пространства в стеке. Указанные 8 регистров могут использоваться только для параметров с 1 по 4. Для классов C ++ скрытый это Параметр является первым параметром и передается в RCX.[26]
	вектор	Windows (Microsoft Visual C ++, Clang, ICC)	RCX / [XY] MM0, RDX / [XY] MM1, R8 / [XY] MM2, R9 / [XY] MM3 + [XY] MM4–5	RTL (К)	Звонящий	Расширен с MS x64.[9]
	Система V AMD64 ABI[24]	Солярис, Linux, BSD, OS X (GCC, Компилятор Intel C ++ )	RDI, RSI, RDX, RCX, R8, R9, [XYZ] MM0–7	RTL (К)	Звонящий	Стек выровнен по границе 16 байт. 128 байт Красная зона под стеком. Интерфейс ядра использует RDI, RSI, RDX, R10, R8 и R9. В C ++ это это первый параметр.

Рекомендации

Сноски

1. Агнер Туман (2010-02-16). Соглашения о вызовах для разных компиляторов C ++ и операционных систем (PDF).
2. де Бойн Поллар, Джонатан (2010). «Генеральные соглашения о вызове функций». Часто задаваемые ответы.
3. «GCC Bugzilla - ошибка 40838 - gcc не должен предполагать, что стек выровнен». 2009.
4. «ДВОИЧНЫЙ ИНТЕРФЕЙС ПРИЛОЖЕНИЯ SYSTEM V Intel 386, четвертое издание» (PDF).
5. «__stdcall (C ++)». MSDN. Microsoft. Архивировано из оригинал на 2008-04-10. Получено 2019-02-13.
6. «__fastcall». MSDN. Получено 2013-09-26.
7. Осе, Уве. "Обзор атрибута gcc: функция fastcall". ohse.de. Получено 2010-09-27.
8. «Знакомство с системой векторных вызовов»'". MSDN. Получено 2014-12-31.
9. "__vectorcall". MSDN. Получено 2014-12-31.
10. «Атрибуты в Clang: условные обозначения». Документация Clang. Получено 8 октября 2019.
11. "_vectorcall и __regcall демистифицированы". software.intel.com. 7 июня 2017.
12. «Управление программой: соглашение о регистрах». docwiki.embarcadero.com. 2010-06-01. Получено 2010-09-27.
13. "_fastcall, __fastcall". docwiki.embarcadero.com.
14. "__msfastcall". docwiki.embarcadero.com.
15. «Атрибуты функции x86». Использование коллекции компиляторов GNU (GCC).
16. "i386: всегда включать регпарм".
17. "Calling_Conventions: Указание_Calling_Conventions_the_Watcom_Way". openwatcom.org. 2010-04-27. Получено 2018-08-31.
18. «Соглашения о программном обеспечении x64: соглашения о вызовах». msdn.microsoft.com. 2010 г.. Получено 2010-09-27.
19. «Архитектура x64». msdn.microsoft.com.
20. «Соглашение о вызовах x64: возвращаемые значения». docs.microsoft.com. Получено 2020-01-17.
21. «Соглашения о программном обеспечении x64 - Размещение стека». Microsoft. Получено 2010-03-31.
22. «Сохраненные регистры вызывающего / вызываемого абонента». Документы Microsoft. Microsoft.
23. "Модель кода x86-64". Библиотека разработчика Mac. Apple Inc. В архиве из оригинала от 10.03.2016. Получено 2016-04-06. Среда x86-64 в OS X имеет только одну модель кода для кода пользовательского пространства. Она больше всего похожа на небольшую модель PIC, определенную x86-64 System V ABI.
24. Майкл Матц; Ян Губичка; Андреас Йегер; и др., ред. (2018-01-28). «Двоичный интерфейс приложения System V: Дополнение к процессору архитектуры AMD64 (с моделями программирования LP64 и ILP32), версия 1.0» (PDF). 1.0.
25. Руководство пользователя Borland C / C ++ версии 3.1 (PDF). Borland. 1992. С. 158, 189–191.
26. «Регистрация использования». Документы Microsoft. Microsoft. Получено 15 сентября 2017.

Другие источники

• "Приложение" СИСТЕМА V "ДВОИЧНЫЙ ИНТЕРФЕЙС Архитектура Intel386, процессорное приложение" (PDF) (4-е изд.). Операция Санта-Крус, Inc. 19 марта 1997 г.
• Неманья Трифунович (22 июля 2001 г.). Шон Юингтон (ред.). "Обозначения условностей демистифицированы". Проект кода.
• Стивен Дж. Фридл. «Соглашения о вызове функций Intel x86 - представление сборки». Технические советы Стива Фридла по Unixwiz.net.
• «Visual Studio 2010 - Соглашение о вызовах Visual C ++». Библиотека MSDN. Microsoft. 2010 г.
• Андреас Йонссон (13 февраля 2005 г.). «Соглашения о вызовах на платформе x86».
• Раймонд Чен (2004-01-02). «История звонков, часть 1». Старая новая вещь.
• Раймонд Чен (2004-01-07). «История звонков, часть 2». Старая новая вещь.
• Раймонд Чен (2004-01-08). «История звонков, часть 3». Старая новая вещь.
• Раймонд Чен (13 января 2004). «История соглашений о вызовах, часть 4: ia64». Старая новая вещь.
• Раймонд Чен (2004-01-14). "История соглашений о вызовах, часть 5; amd64". Старая новая вещь.

дальнейшее чтение

• Джонатан де Бойн Поллард (2010). «Генеральные соглашения о вызове функций». Часто задаваемые ответы.
• Кип Р. Ирвин (2011). «Расширенные процедуры (Глава 8)». Язык ассемблера для процессоров x86 (6-е изд.). Прентис Холл. ISBN  978-0-13-602212-1.
• Руководство пользователя Borland C / C ++ версии 3.1 (PDF). Borland. 1992. С. 158, 189–191.
• Томас Лауэр (1995). «Новая последовательность вызовов __stdcall». Перенос на Win32: руководство по подготовке приложений к 32-разрядному будущему Windows. Springer. ISBN  978-0-387-94572-9.