Соглашение о вызове для Win64

[Bishop]

Как извество для архитектуры x86_64 существует 2 соглашения о вызове процедур и функций. Первое это соглашение применяемое в Linux (для написание кода на ASM оно крайне удобно) и второе - применяемое в Windows. Вспомнив win32 с его зоопарком разных соглашений о вызове, я предположил что в FPC встроен механизм генерации разных соглашений о вызове внутри одной программы.

Вопрос: Можно ли в Win64 указать компилятору что процедуру следует компилировать (для кода на паскале) и вызывать (для любой процедуры или функции) в соответствии с правилами Linux а не Windows.
Вопрос 2: Если такой возможности нету, имеет ли смысл пытаться её доработать самому и предложить в виде патча или же данная вещь противоречит политике разработки FPC.

Т.е. идея в том, чтобы добавить соглашение о вызове (к примеру L64Call). Это сильно облегчит написание asm кода для платформы x86_64 (можно писать только одну версию asm кода, а не 2).

P.S. И на будущее, где вообще обсуждаються подобные инициативы?

[Sergei I. Gorelkin]

Соглашение Win64 почти не отличается от Linux64 и не менее удобно для ассемблерного кода. Двух разных версий ассемблерных процедур как правило не требуется, достаточно разницы в несколько команд в начале (см. rtl/x86_64/x86_64.inc).

Для каждой платформы поддерживаются только те соглашения вызова, которые применимы к данной платформе. Идея поддержки "чужого" соглашения о вызове действительно как бы противоречит политике, во-первых потому что одним из достоинств x86_64 считается избавление от зоопарка вызовов, а тут предполагается фактически возврат к нему, во-вторых, на x86_64 используется байткод для описания стека вызовов (секция .pdata в win64 и DWARF CFI в Linux, оно пока не поддерживается в FPC, но работа в этом направлении ведется), вписать в формат которого "чужой" тип вызова едва ли будет возможно.

[Bishop]

Соглашение Win64 почти не отличается от Linux64 и не менее удобно для ассемблерного кода. Двух разных версий ассемблерных процедур как правило не требуется, достаточно разницы в несколько команд в начале (см. rtl/x86_64/x86_64.inc).

Тут попробую с вами не согласиться. Во первых первые параметры в RDI/RSI крайне удобно, т.к. избавляет от лишней возни при работе со строками. Но самое главное другое, отсутствие необходимости в сохранении регистров XMM (насколько мне измество FPC не поддерживает инстрики и векторизацию, поэтому весь векторный код приходиться писать на asm).

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

Для каждой платформы поддерживаются только те соглашения вызова, которые применимы к данной платформе. Идея поддержки "чужого" соглашения о вызове действительно как бы противоречит политике, во-первых потому что одним из достоинств x86_64 считается избавление от зоопарка вызовов, а тут предполагается фактически возврат к нему

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

[Sergei I. Gorelkin]

Тут попробую с вами не согласиться. Во первых первые параметры в RDI/RSI крайне удобно, т.к. избавляет от лишней возни при работе со строками.

Строковые инструкции, работающие с rsi/rdi, на x86_64 не считаются оптимальным (по скорости) способом обработки строк.

Но самое главное другое, отсутствие необходимости в сохранении регистров XMM (насколько мне измество FPC не поддерживает инстрики и векторизацию, поэтому весь векторный код приходиться писать на asm).

Это довольно-таки спорное преимущество: если все XMM регистры считаются изменяемыми, то они должны сохраняться вызывающей стороной, причем перед каждым вызовом любой процедуры. Выигрывая в одном месте, проигрываем в другом (в других?).

И, если не хватает интринсиков и векторизации, лучше работать именно над ними, а не над костылями. Какие-то наработки по векторизации, в виде поддержки MMX на i386, уже имеются.

[Bishop]

Строковые инструкции, работающие с rsi/rdi, на x86_64 не считаются оптимальным (по скорости) способом обработки строк.

Не знал.

Это довольно-таки спорное преимущество: если все XMM регистры считаются изменяемыми, то они должны сохраняться вызывающей стороной, причем перед каждым вызовом любой процедуры. Выигрывая в одном месте, проигрываем в другом (в других?).

Согласен, просто обычно код сгенерированный FPC использует лишь 3-4 XMM регистра, а вот например тотже AES требует всех 16-ти, да и работа с матрицами часто требует 10-12 регитсров чтобы обойтись без обращений в стек вообще.

И, если не хватает интринсиков и векторизации, лучше работать именно над ними, а не над костылями. Какие-то наработки по векторизации, в виде поддержки MMX на i386, уже имеются.

Боюсь для реализации такого моих знаний в архитектуре компилятора попросту нехватит. Хотя за наводку на mmx спасибо, посмотрю.

[SII]

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

[Bishop]

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

Так про неё и шла речь