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