Why should I not use __fastcall instead the standard __cdecl?

Question

I'd listening some people saying __fastcall is faster than __cdecl and __stdcall cause it puts two parameters in register, instead of the one of other calls; but, in other hand, this is not the standard used in C.

I would like to know what makes __fastcall undesirable like a standard in C and when I will use this in my code.

Docket

This is very platform specific. You'd best list architecture, OS, and tool versions. – Homerhomere

stdcall and cdecl put no parameters in registers, while fastcall puts 4 parameters in registers when it can. – Steeplechase

@Lucas see https://mcmap.net/q/371376/-is-fastcall-really-faster – Koval

"this is not the standard used in C" - None of them are the standard used in C. The C standard makes no mention of calling convention, nor of these keywords. – Nagel

Answer 1

The x86 platform is unusual in that it doesn't define a global ABI and calling convention.

Win32/x86 does, it standardizes on stdcall. There are various tradeoffs between calling conventions -- placing parameters in registers is faster, but it forces the caller to spill whatever was previously using those registers. So it's hard to predict which gives better performance.

The important thing is to have a uniform standard calling convention to enable interoperability between different compilers (and even different programming languages).

Other platforms don't have cdecl, stdcall, or fastcall conventions. They don't have the same set of registers. In some cases, they don't even have registers at all. But they still can use C code.

Win32/x86_64 doesn't use stdcall, it uses a 64-bit extension of fastcall.

Linux/x86 has a convention also.

Homerhomere

It was what i wanted to know. Thanks for the answer. – Docket

I wouldn't call this unusual. No ISA has an inherent calling convention; calling convention is a contract you construct on top of the ISA, and for unix-like systems, it usually follows the psABI for the particular arch, which builds upon the gABI that evolved out of Unix System V. Some ISAs like ARM have one or more ABIs developed, promoted, and/or sponsored by the creator of the ISA, but there's still no fundamental reason they have to be used. I would say x86 is the norm, not the exception, in this regard. – Lubin

@R..: "ABI developed, promoted, and/or sponsored by the creator of the ISA" is definitely the norm. ARM does. Alpha does. Itanium does. AMD64 does. I seem to recall that MIPS and Motorola 68xx and PowerPC all do. Which isn't to say that the instruction set is incapable of other calling conventions, but there is one defined in the architecture reference manual. – Homerhomere

MIPS has countless different ABIs, all of which are very bad and none of which seem to be official. Sparc had an official ABI but only because a single vendor was responsible for the whole ecosystem. That was largely the case for Alpha too. PPC seems to have several ABIs. No idea about m68k. The Itanic seems to have been the first ISA where the company behind the ISA was not also responsible for the operating system to be used on it. Newer ISAs like x86_64 and ARM promoting official ABIs seems to be a new trend that grew out of this. – Lubin

@R..: Anyway, it's unusual today to not have a standardized ABI. And the reason is that x86 is a relic from a bygone era where the benefits weren't recognized. – Homerhomere

Today there is a standardized ABI on x86; it's the psABI. The only system not using it is Windows, and Windows also rejects the standard ABI on x86_64. My only point is that this standard is a convention adopted by parties using the ISA and is not specified along with the ISA. – Lubin

@R..: I could equally say that the Win32 ABI is the standard on x86, and that System V are causing trouble by making a new one instead of following the standard. Fact is, x86 has no official ABI. Other architectures do. – Homerhomere

I think my point that Windows also ignored the standard ABI for x86_64, combined with the fact that Windows did not exist when the now-standard x86 ABI was created, speak to the fact that this is just a case of Windows not following standards. – Lubin

let us continue this discussion in chat – Homerhomere

what would be the linux convention? – Sexism

but it forces the caller to spill whatever was previously using those registers. - No, ECX and EDX are call-clobbered in stdcall and cdecl as well. If the caller needs a value to survive a call, it always needs it in a different register, or memory, whether you use fastcall or not. – Homely

The Windows x64 calling convention isn't "architecture defined". It was developed purely in-house by MS. The x86-64 System V ABI was designed by GCC devs, and isn't officially endorsed by either Intel or AMD either. It was discussed by GCC devs on the same public mailing list that AMD64 architects and Linux kernel devs were also on, though. See my answer on Why does Windows64 use a different calling convention from all other OSes on x86-64? for some links to the archives. – Homely

Answer 2

Are you looking for a calling convention to specify for a library interface? Because for all other functions, I wouldn't specify a calling convention at all. The compiler's optimization pass (auto-inlining for instance) probably renders the calling convention useless.

But regarding fastcall: as far as I remember, it's not standardized, and therefore not suitable for library code. Here is nice overview: Calling Conventions Demystified

Lemal

I think all the major x86 compilers that can target Windows can mark a function prototype as fastcall. MSVC can, and other compilers support GNU C __attribute__((fastcall)). BTW, the article you linked showed the debug-mode asm. No wonder they didn't find it any faster; the callee was spilling the register args to the stack and then reloading them, completely defeating the purpose vs. just lea / ret. (It also claims that MS reserves the right to change fastcall to use different regs. If that's true, it would make it unsuitable for libraries, but IDK if it is.) – Homely