Почему я не должен использовать __fastcall вместо стандартного __cdecl?

Я бы прослушал некоторых людей, говорящих, что __fastcall быстрее, чем __cdecl и __stdcall заставляет его вставлять два параметра в регистр, а не один из других вызовов; но, с другой стороны, это не стандарт, используемый в C.

Я хотел бы знать, что делает __fastcall нежелательным, как стандарт в C, и когда я буду использовать его в своем коде.

Ответы

Ответ 1

Платформа x86 необычна тем, что не определяет глобальное ABI и соглашение о вызове.

Win32/x86 делает, он стандартизован на stdcall. Существуют различные компромиссы между вызывающими соглашениями - размещение параметров в регистрах происходит быстрее, но это заставляет вызывающего абонента разливать все, что ранее использовалось для этих регистров. Поэтому трудно предсказать, что дает лучшую производительность.

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

Другие платформы не имеют соглашений cdecl, stdcall или fastcall. У них нет одинакового набора регистров. В некоторых случаях у них даже нет регистров вообще. Но они все еще могут использовать код C.

Win32/x86_64 не использует stdcall, он использует соглашение, определенное архитектурой.

Linux/x86 также имеет соглашение.

Ответ 2

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

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