Thread overview
Can someone decipher this moon speak for me? (abi - calling conventions)
Mar 01, 2012
Bernard Helyer
Mar 01, 2012
Bernard Helyer
Mar 01, 2012
Martin Nowak
Mar 01, 2012
Bernard Helyer
Mar 01, 2012
Martin Nowak
Mar 01, 2012
Jacob Carlborg
March 01, 2012
http://dlang.org/abi.html

"The extern (C) and extern (D) calling convention matches the C calling convention used by the supported C compiler on the host system. Except that the extern (D) calling convention for Windows x86 is described here."

Was this written by someone slamming their face onto the keyboard repeatedly? Is the calling convention just C on non-windows platforms? What about AMD64? Why should I, as someone writing a D implementation, burn cycles on trying to decypher this madness? Didn't this section _used_ to make sense?

To summarise:





fucking what?






</rant>
March 01, 2012
So as near as I can tell, it's trying to say

"On non-Windows platforms, both extern (C) and extern (D) match the calling convention of the platforms C compiler. On Windows,  the extern (D) calling convention differs, and is documented below:"

Is this accurate?

If so, there's is no way I am wasting my time with the D calling convention. I'm not wrangling LLVM into producing DM OMF, so binary compatibility isn't going to happen anyway.

If not, then I have no idea.
March 01, 2012
On Thu, 01 Mar 2012 06:26:28 +0100, Bernard Helyer <b.helyer@gmail.com> wrote:

> So as near as I can tell, it's trying to say
>
> "On non-Windows platforms, both extern (C) and extern (D) match the calling convention of the platforms C compiler. On Windows,  the extern (D) calling convention differs, and is documented below:"
>
> Is this accurate?
>
> If so, there's is no way I am wasting my time with the D calling convention. I'm not wrangling LLVM into producing DM OMF, so binary compatibility isn't going to happen anyway.
>
> If not, then I have no idea.

For x86-32 dmd uses a fastcall, where EAX can contain a parameter, for Windows AND all other supported OSes.
This is different from cdecl where parameters are always passed on the stack.

For x86-64 D follows the SysV AMD64 ABI, don't know about Windows.
March 01, 2012
On Thursday, 1 March 2012 at 06:07:40 UTC, Martin Nowak wrote:
> For x86-32 dmd uses a fastcall, where EAX can contain a parameter, for Windows AND all other supported OSes.

._.;

Well, that's nice to know, thanks. Because we (SDC) use fastcall for D, just (we thought) as a temporary measure.

But seriously, I don't think one can gather that information even if they can recognise fastcall from the technical description.

March 01, 2012
On 2012-03-01 07:07, Martin Nowak wrote:
> On Thu, 01 Mar 2012 06:26:28 +0100, Bernard Helyer <b.helyer@gmail.com>
> wrote:
>
>> So as near as I can tell, it's trying to say
>>
>> "On non-Windows platforms, both extern (C) and extern (D) match the
>> calling convention of the platforms C compiler. On Windows, the extern
>> (D) calling convention differs, and is documented below:"
>>
>> Is this accurate?
>>
>> If so, there's is no way I am wasting my time with the D calling
>> convention. I'm not wrangling LLVM into producing DM OMF, so binary
>> compatibility isn't going to happen anyway.
>>
>> If not, then I have no idea.
>
> For x86-32 dmd uses a fastcall, where EAX can contain a parameter, for
> Windows AND all other supported OSes.

From the documentation it sounds like it's ONLY on Windows.

> This is different from cdecl where parameters are always passed on the
> stack.
>
> For x86-64 D follows the SysV AMD64 ABI, don't know about Windows.


-- 
/Jacob Carlborg
March 01, 2012
On Thu, 01 Mar 2012 07:14:17 +0100, Bernard Helyer <b.helyer@gmail.com> wrote:

> On Thursday, 1 March 2012 at 06:07:40 UTC, Martin Nowak wrote:
>> For x86-32 dmd uses a fastcall, where EAX can contain a parameter, for Windows AND all other supported OSes.
>
> ._.;
>
> Well, that's nice to know, thanks. Because we (SDC) use fastcall for D, just (we thought) as a temporary measure.
>
> But seriously, I don't think one can gather that information even if they can recognise fastcall from the technical description.
>

Be aware though, that fastcall means vendor specific,
so LLVM's understanding of fastcall could be different.