Speaking of C++
-
What is the theory behind making the default calling convention
cdecl? It leads to larger code and it's fundamentally incompatible with OS APIs. What were they thinking?The difficult we do right away... ...the impossible takes slightly longer.
I thought C++ preferred stdcall, whereas C was always cdecl. Fast call is a head fuck though, using registers for the first arguments!
-
When Windows 1.0 was released, most PCs used 8088s. A high-performance machine used an 80286, and the 80386 was just coming on the market. We looked for every possible way to eke out some extra performance. Microsoft's decision made sense at the time from both the technical and the production standpoints - saving three bytes and one instruction for each function call, and shipping Windows on one less diskette. Windows was from the beginning designed to be programmed in C. Unless you were writing code in Assembly language (mostly device drivers), the difference between the calling conventions was handled by the compiler and so was transparent to the programmer. At the C level, it makes no more difference than big-endian vs. little-endian. (Now, let the Religious Wars resume... :) )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Very good information! :)
The difficult we do right away... ...the impossible takes slightly longer.
-
I thought C++ preferred stdcall, whereas C was always cdecl. Fast call is a head fuck though, using registers for the first arguments!
Read reply of every single one and it was nice that people still care about it. Just as you can drive either on Left side or on Right side of road, in computer world, there are two primary directions to read or write data from. For higher level languages, compiler encapsulates all this complexity and provides user a neat option to switch the calling conventions. C language adopted PDP convention as its de-facto and coined the term cdecl to encapsulate the idea. The original name for opposite calling convention was PASCAL and if you go thru some old Windows API books, you will find that word. all over the place. cdecl convention allows variadic parameters very easily whereas PASCAL convention makes stack management easier. Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
-
What is the theory behind making the default calling convention
cdecl? It leads to larger code and it's fundamentally incompatible with OS APIs. What were they thinking?The difficult we do right away... ...the impossible takes slightly longer.
C-compatibility. Loads of issues with C++ stem from C-compatibility.
-
Read reply of every single one and it was nice that people still care about it. Just as you can drive either on Left side or on Right side of road, in computer world, there are two primary directions to read or write data from. For higher level languages, compiler encapsulates all this complexity and provides user a neat option to switch the calling conventions. C language adopted PDP convention as its de-facto and coined the term cdecl to encapsulate the idea. The original name for opposite calling convention was PASCAL and if you go thru some old Windows API books, you will find that word. all over the place. cdecl convention allows variadic parameters very easily whereas PASCAL convention makes stack management easier. Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
Quote:
Reason why cdecl causes generates more code is usually because the underlying hardware has opposite convention and hence the compiler has to emit more opcodes to compensate for it.
x86 specific, RISC architectures probably have similar constraints for registers used to push arguments. cdecl causes more code because the caller is responsible for cleaning up the pushed arguments. Since cdecl allows variable argument count, only the caller knows how many arguments were actually pushed.
printf("Hello", unused1, unused2);
Hence the extra instruction mentioned on another post; after the call returns, the stack must be adjusted to remove the pushed arguments. std call/Pascal is a fixed argument list and the callee can adjust the argument list. On the x86 processers, "return from subroutine" has a form that allows for the stack to be adjusted to remove the pushed arguments. The std call/Pascal convention used this form to "return and adjust" as a single opcode + operand.
-
When Windows 1.0 was released, most PCs used 8088s. A high-performance machine used an 80286, and the 80386 was just coming on the market. We looked for every possible way to eke out some extra performance. Microsoft's decision made sense at the time from both the technical and the production standpoints - saving three bytes and one instruction for each function call, and shipping Windows on one less diskette. Windows was from the beginning designed to be programmed in C. Unless you were writing code in Assembly language (mostly device drivers), the difference between the calling conventions was handled by the compiler and so was transparent to the programmer. At the C level, it makes no more difference than big-endian vs. little-endian. (Now, let the Religious Wars resume... :) )
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
That's a very interesting point, because I just assumed that C's default convention was
stdapi. The reason I assumed that is that when you want to export a function from a C++ DLL, you usually enclose the declaration inextern "C". But I never considered that C's default convention was cdecl. Well played. :)The difficult we do right away... ...the impossible takes slightly longer.
-
Quote:
Windows was from the beginning designed to be programmed in C.
That is true if you never opened a window before it became 32 bits. The native calling convention of the original 16 bits Windows was the Pascal way of doing it.
1. The Windows SDK was always published first in C. If any ports to other languages occurred (e.g. Borland's Borland Pascal), they were delayed by some months. 2. As my OP said, the calling convention is handled by the C compiler, so unless you are programming in Assembly language, it is irrelevant. I stand by my statement.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
What is the theory behind making the default calling convention
cdecl? It leads to larger code and it's fundamentally incompatible with OS APIs. What were they thinking?The difficult we do right away... ...the impossible takes slightly longer.
C existed during 16 bit period and I am almost sure that
RETinstruction did not take argument back then. Your computer most likely start in real mode, which is 16 bit, so it is still in use today. I suppose that is why they do not want to change the calling convention. P.S. fastcall prolog is usually optimized (under /O2 or more) to use arguments directly from registers when possible. -
extern "C" indicates that C++ name mangling should not be used - just the plain function name, not decorated with the types of the function arguments for overload resolution.
Your partly correct, indeed it indicates that C++ name mangling should not be used. But this does not mean plain function names. It's mangling the way c get's mangled. For example a function returning a 32 bit int would be something like function@4 and if u take stdcall c function by a microsoft vc compiler u often get even more mangling on the function name.
