Я бы прослушал некоторых людей, говорящих, что __fastcall быстрее, чем __cdecl и __stdcall заставляет его вставлять два параметра в регистр, а не один из других вызовов; но, с другой стороны, это не стандарт, используемый в C.
Я хотел бы знать, что делает __fastcall нежелательным, как стандарт в C, и когда я буду использовать его в своем коде.
Платформа x86 необычна тем, что не определяет глобальное ABI и соглашение о вызове.
Win32/x86 делает, он стандартизован на stdcall. Существуют различные компромиссы между вызывающими соглашениями - размещение параметров в регистрах происходит быстрее, но это заставляет вызывающего абонента разливать все, что ранее использовалось для этих регистров. Поэтому трудно предсказать, что дает лучшую производительность.
Важно иметь единообразное стандартное соглашение о вызове, позволяющее взаимодействовать между разными компиляторами (и даже разными языками программирования).
Другие платформы не имеют соглашений cdecl, stdcall или fastcall. У них нет одинакового набора регистров. В некоторых случаях у них даже нет регистров вообще. Но они все еще могут использовать код C.
Win32/x86_64 не использует stdcall, он использует соглашение, определенное архитектурой.
Linux/x86 также имеет соглашение.
Вы ищете соглашение о вызове для интерфейса библиотеки? Потому что для всех других функций я вообще не буду указывать соглашение о вызове. Пропуск оптимизации компилятора (например, автоинкремент), вероятно, делает бесполезным вызов.
Но в отношении fastcall: насколько я помню, он не стандартизован и поэтому не подходит для библиотечного кода. Вот хороший обзор: Соглашения о вызовах, демистифицированные