On Monday, 18 December 2017 at 14:31:38 UTC, Kagamin wrote:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Function-Attributes.html#index-functions-that-pop-the-argument-stack-on-x86-32-3
looks like gcc doesn't see it as OS dependent.
Thanks. I was playing around on asm.dlang.org and found
From https://gcc.godbolt.org/
__attribute__((stdcall))
int square(int num) {
return num * num;
}
_Z6squarei:
push ebp
mov ebp, esp
mov eax, DWORD PTR [ebp+8]
imul eax, DWORD PTR [ebp+8]
pop ebp
ret 4
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Function-Attributes.html#index-functions-that-pop-the-argument-stack-on-x86-32-3
looks like gcc doesn't see it as OS dependent.
On Monday, 18 December 2017 at 10:52:22 UTC, Kagamin wrote:
On Sunday, 17 December 2017 at 13:36:15 UTC, Mike Parker wrote:
My limited testing on a 64-bit Linux VM shows no problems when
binding a C function as extern(C) or extern(Windows), and the
disassembly looks the same.
64-bit ABI
On Sunday, 17 December 2017 at 13:36:15 UTC, Mike Parker wrote:
My limited testing on a 64-bit Linux VM shows no problems when
binding a C function as extern(C) or extern(Windows), and the
disassembly looks the same.
64-bit ABI fixed calling convention proliferation, only one cc is
used
For years now, I've been under the impression that the
distinction between extern(Windows) and extern(System) actually
mattered. I recall extern(System) was first added to the language
to resolve this situation for C bindings:
version(Windows) extern(Windows):
else extern(C):
Which, or
