Почему Windows64 использует другое соглашение о вызовах, чем все другие операционные системы на x86-64?

У AMD есть спецификация ABI, в которой описывается соглашение о вызовах для использования на x86-64. Все операционные системы следуют ему, за исключением Windows, которая имеет собственное соглашение о вызовах x86-64. Зачем?

Кто-нибудь знает технические, исторические или политические причины этой разницы, или это чисто синдром NIH?

Я понимаю, что разные ОС могут иметь разные потребности в вещах более высокого уровня, но это не объясняет, почему, например, порядок передачи параметров реестра в Windows такой, rcx - rdx - r8 - r9 - rest on stackкак все остальные rdi - rsi - rdx - rcx - r8 - r9 - rest on stack.

PS Я знаю , как эти соглашения о вызовах в целом отличаются , и я знаю , где найти информацию , если мне нужно. Я хочу знать почему .

Изменить: чтобы узнать как, см., Например, запись в Википедии и ссылки оттуда.

Выбор четырех регистров аргументов на x64 - общий для UN * X / Win64

При использовании x86 следует помнить, что имя регистра в кодировке "reg number" неочевидно; с точки зрения кодирования инструкций ( байт MOD R / M , см. http://www.c-jump.com/CIS77/CPU/x86/X77_0060_mod_reg_r_m_byte.htm ), номера регистров 0 ... 7 - в таком порядке - ?AX, ?CX, ?DX, ?BX, ?SP, ?BP, ?SI, ?DI.

Следовательно, выбор A / C / D (regs 0..2) для возвращаемого значения и первых двух аргументов (что является «классическим» 32-битным __fastcallсоглашением) является логическим выбором. Что касается перехода на 64-битную версию, то заказываются «более высокие» регистры, и Microsoft и UN * X / Linux выбрали R8/ R9как первые.

Имея это в виде, выбор Microsoft по RAX(возвращаемое значение) и RCX, RDX, R8, R9(Arg [0..3]) является понятным выбором , если вы выбираете четыре регистра для аргументов.

Я не знаю, почему AMD64 UN * X ABI выбрал RDXраньше RCX.

Выбор шести регистров аргументов на x64 - для UN * X

UN * X на архитектурах RISC традиционно выполняет передачу аргументов в регистрах - в частности, для первых шести аргументов (по крайней мере, для PPC, SPARC, MIPS). Это может быть одной из основных причин, по которой разработчики AMD64 (UN * X) ABI решили использовать шесть регистров и в этой архитектуре.

Так что если вы хотите шесть регистров для передачи аргументов в, и это логично выбрать RCX, RDX, R8и R9четыре из них, которые других двух вы должны выбрать?

«Старшие» регистры требуют дополнительного байта префикса инструкций для их выбора и, следовательно, имеют больший размер инструкции, поэтому вы не захотите выбирать какой-либо из них, если у вас есть опции. Из классических регистров, из - за неявный смысл RBPи RSPони не доступны, и RBXтрадиционно имеет особое применение на ООН * X (глобальная таблица смещений) , которые , казалось бы , дизайнеры AMD64 ABI не хотели понапрасну стать несовместимым с.
Ergo, единственным выбором были RSI/ RDI.

Итак, если вам нужно использовать RSI/ в RDIкачестве регистров аргументов, какими аргументами они должны быть?

Изготовление их arg[0]и arg[1]имеет ряд преимуществ. См. Комментарий cHao.
?SIи ?DIявляются операндами источника / назначения строковых инструкций, и, как упоминалось в cHao, их использование в качестве регистров аргументов означает, что с соглашениями о вызовах AMD64 UN * X простейшая возможная strcpy()функция, например, состоит только из двух инструкций ЦП, repz movsb; retпоскольку источник / цель адреса были помещены вызывающим абонентом в правильные регистры. Есть, в частности, в низкоуровневом и сгенерированном компилятором "связующем" коде (подумайте, например, о некоторых распределителях кучи C ++, заполняющих объекты нулями при создании, или страницы кучи ядра с нулевым заполнением наsbrk(), или ошибки страницы копирования при записи) огромное количество блоков копирования / заполнения, поэтому это будет полезно для кода, который так часто используется для сохранения двух или трех инструкций ЦП, которые в противном случае загружали бы такие аргументы исходного / целевого адреса в "правильные" регистры.

Таким образом , в некотором смысле, UN * X и Win64 отличаются только тем , что UN * X «помещает» два дополнительных аргумента, в целенаправленно выбранных RSI/ RDIрегистров, к естественному выбору четырех аргументов в RCX, RDX, R8и R9.

За гранью этого ...

Между UN * X и Windows x64 ABI есть больше различий, чем просто отображение аргументов в определенные регистры. Для обзора Win64 проверьте:

http://msdn.microsoft.com/en-us/library/7kcdt6fy.aspx

Win64 и AMD64 UN * X также разительно отличаются по способу использования пространства стека; в Win64, например, вызывающий должен выделить пространство стека для аргументов функции, даже если в регистрах передаются аргументы 0 ... 3. В UN * X, с другой стороны, листовая функция (то есть та, которая не вызывает другие функции) даже не требуется для выделения пространства стека вообще, если ей требуется не более 128 байтов (да, вы владеете и можете использовать определенное количество стека без выделения его ... ну, если вы не код ядра, источник изящных ошибок). Все это конкретные варианты оптимизации, большая часть обоснования которых объясняется в полных ссылках на ABI, на которые указывает ссылка в Википедии исходного постера.

IDK, почему Windows сделала то, что они сделали. Смотрите в конце этого ответа, чтобы предположить. Мне было любопытно, как было принято решение о вызовах SysV, поэтому я покопался в архиве списков рассылки и нашел кое-что интересное.

Интересно читать некоторые из этих старых веток в списке рассылки AMD64, поскольку архитекторы AMD активно участвовали в этом. например, выбор имен регистров был одной из сложных частей: AMD рассматривала переименование исходных 8 регистров r0-r7 или вызов новых регистров вродеUAX .

Кроме того , обратная связь с ядром УБС идентифицированные вещи , которые сделали оригинальный дизайн syscallи swapgsнепригодным для использования . Вот как AMD обновила инструкцию, чтобы разобраться с этим перед выпуском каких-либо реальных чипов. Также интересно, что в конце 2000 года предполагалось, что Intel, вероятно, не станет использовать AMD64.

Соглашение о вызовах SysV (Linux) и решение о том, сколько регистров следует сохранять для вызываемого абонента по сравнению с сохранением для вызывающего, было принято первоначально в ноябре 2000 года Яном Хубицкой (разработчиком gcc). Он скомпилировал SPEC2000 и посмотрел на размер кода и количество инструкций. В этой дискуссии обсуждаются некоторые из тех же идей, что и ответы и комментарии на этот вопрос SO. Во втором потоке он предложил текущую последовательность как оптимальную и, надеюсь, окончательную, генерируя меньший код, чем некоторые альтернативы .

Он использует термин «глобальный» для обозначения регистров с сохранением вызовов, которые должны быть выталкиваются / выталкиваются, если используются.

Выбор rdi, rsi, rdxкак первые три арг был мотивирован:

• незначительная экономия размера кода в функциях, которые вызывают memsetили другую строковую функцию C в своих аргументах (где gcc встраивает операцию строки rep?)
• rbxсохраняется вызов, потому что наличие двух регистров с сохранением вызовов, доступных без префиксов REX (rbx и rbp), является выигрышем. Предположительно выбран, потому что это единственный другой регистр, который неявно не используется ни одной инструкцией. (строка повторения, количество сдвигов и выходы / входы multi / div касаются всего остального).
• Ни один из регистров специального назначения не сохраняется при вызове (см. Предыдущий пункт), поэтому функции, которая хочет использовать инструкции строки реплики или сдвиг подсчета переменных, может потребоваться переместить аргументы функции в другое место, но не нужно сохранять / восстановить значение вызывающего абонента.

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

  (фон: syscall/ sysretнеизбежно уничтожает rcx(с rip) и r11(с RFLAGS), поэтому ядро ​​не может видеть, что было изначально rcxпри syscallзапуске.)

ABI системного вызова ядра был выбран для соответствия вызову функции ABI, за исключением r10вместо rcx, поэтому функции оболочки libc, такие как mmap(2)can, просто mov %rcx, %r10/ mov $0x9, %eax/ syscall.

Обратите внимание, что соглашение о вызовах SysV, используемое i386 Linux, отстойно по сравнению с 32-битным __vectorcall в Windows. Он передает все в стеке и возвращается только edx:eaxдля int64, а не для небольших структур . Неудивительно, что для обеспечения совместимости с ним было приложено мало усилий. Когда нет причин не делать этого, они делали такие вещи, как сохранение rbxвызовов с сохранением, так как они решили, что иметь другой в исходной 8 (для которого не нужен префикс REX) было бы хорошо.

Оптимизация ABI гораздо важнее в долгосрочной перспективе, чем любые другие соображения. Думаю, они проделали довольно хорошую работу. Я не совсем уверен в возвращении структур, упакованных в регистры, вместо разных полей в разных регистрах. Я думаю, что код, который передает их по значению, не работая с полями, таким образом побеждает, но дополнительная работа по распаковке кажется глупой. У них могло быть больше целочисленных регистров возврата, больше, чем просто rdx:rax, поэтому возвращение структуры с 4 членами могло вернуть их в rdi, rsi, rdx, rax или что-то в этом роде.

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

Я подозреваю, что разработчики Windows ABI, возможно, стремились минимизировать различия между 32 и 64 битами в интересах людей, которым приходится переносить asm с одного на другой или которые могут использовать пару #ifdefв некоторых ASM, чтобы один и тот же источник мог легче создавать 32- или 64-битная версия функции.

Сведение к минимуму изменений в цепочке инструментов кажется маловероятным. Компилятору x86-64 нужна отдельная таблица, в которой указывается, какой регистр для чего используется и каково соглашение о вызовах. Небольшое перекрытие с 32-битной версией вряд ли приведет к значительной экономии в размере / сложности кода инструментальной цепочки.

Помните, что Microsoft изначально «официально не возлагала никаких обязательств на первые попытки AMD64» (из «Истории современных 64-битных вычислений» Мэтью Кернера и Нила Пэджетта), потому что они были сильными партнерами Intel по архитектуре IA64. Я думаю, это означало, что даже если бы они в противном случае были бы открыты для работы с инженерами GCC над ABI для использования как в Unix, так и в Windows, они бы этого не сделали, поскольку это означало бы публичную поддержку усилий AMD64, когда они этого не сделали. Тем не менее официально это сделано (и, вероятно, расстроило бы Intel).

Вдобавок к этому, в те дни Microsoft не стремилась дружить с проектами с открытым исходным кодом. Уж точно не Linux или GCC.

Так зачем им сотрудничать по ABI? Я предполагаю, что ABI отличаются просто потому, что они были разработаны более или менее в одно и то же время и изолированно.

Еще одна цитата из «Истории современных 64-битных вычислений»:

Параллельно с сотрудничеством с Microsoft AMD также привлекла сообщество разработчиков открытого кода к подготовке этого чипа. AMD заключила контракт с Code Sorcery и SuSE на работу по цепочке инструментов (Red Hat уже была привлечена Intel к портированию цепочки инструментов IA64). Рассел объяснил, что SuSE выпускает компиляторы C и FORTRAN, а Code Sorcery выпускает компилятор Pascal. Вебер объяснил, что компания также взаимодействовала с сообществом Linux для подготовки порта Linux. Это усилие было очень важным: оно послужило стимулом для Microsoft продолжать инвестировать в усилия AMD64 Windows, а также гарантировало, что Linux, которая в то время становилась важной ОС, будет доступна после выпуска чипов.

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

Это указывает на то, что даже AMD не считала, что сотрудничество между MS и Unix обязательно является самым важным, но поддержка Unix / Linux была очень важной. Может быть, даже попытка убедить одну или обе стороны пойти на компромисс или сотрудничать не стоит усилий или риска (?) Разозлить кого-либо из них? Возможно, AMD думала, что даже предложение общего ABI может задержать или подорвать более важную цель - просто подготовить поддержку программного обеспечения, когда чип будет готов.

Предположения с моей стороны, но я думаю, что основная причина, по которой ABI отличаются, была политическая причина, по которой MS и стороны Unix / Linux просто не работали вместе над этим, и AMD не считала это проблемой.

Win32 имеет собственное использование для ESI и EDI и требует, чтобы они не изменялись (или, по крайней мере, восстанавливались перед вызовом API). Я предполагаю, что 64-битный код делает то же самое с RSI и RDI, что объясняет, почему они не используются для передачи аргументов функций.

Однако я не могу сказать вам, почему переключаются RCX и RDX.