On 24 April 2012 17:05, Erik Jensen <eriksjunk@rkjnsn.net> wrote:
> On Tuesday, 24 April 2012 at 14:40:05 UTC, Iain Buclaw wrote:
>>
>> On 24 April 2012 11:29, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>>
>>> On 24-04-2012 11:42, Kagamin wrote:
>>>>
>>>>
>>>> Speaking about GDC, you can't link to omf files directly - so there
>>>> shouldn't be any binary incompatibility.
>>>> If the assembler code is unportable across compilers, it's a developer's
>>>> mistake or intention.
>>>
>>>
>>>
>>> The point is just that: Right now I can write assembly that will work on GDC, LDC, and DMD on non-Windows. It will not work for DMD on Windows. Something has to change here.
>>>
>>> You're missing the point if you think this is a "developer mistake".
>>>
>>
>> Is not just Windows, the DMD calling convention on Linux differs from the system calling convention.  For example, some of the naked functions in std.math returning floating point values assumes caller clean up.  Where as the C calling convention is callee clean up.
>
>
> That is incorrect. The cdecl calling convention is caller clean-up (see http://en.wikipedia.org/wiki/X86_calling_conventions). Otherwise, variable argument functions would not be possible (the called function doesn't know what to clean up).
>
>

I forget which, but I'm pretty certain the CDecl calling convention does not call 'ret PARAMSIZE;'  when returning floats. =)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 24-04-2012 19:54, Paulo Pinto wrote:
> This means that in the end we have the same ABI issues between
> D compilers, as in other languages I suppose, right?
>
> --
> Paulo
>
> On Tuesday, 24 April 2012 at 14:40:05 UTC, Iain Buclaw wrote:
>> On 24 April 2012 11:29, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>> On 24-04-2012 11:42, Kagamin wrote:
>>>>
>>>> Speaking about GDC, you can't link to omf files directly - so there
>>>> shouldn't be any binary incompatibility.
>>>> If the assembler code is unportable across compilers, it's a
>>>> developer's
>>>> mistake or intention.
>>>
>>>
>>> The point is just that: Right now I can write assembly that will work on
>>> GDC, LDC, and DMD on non-Windows. It will not work for DMD on Windows.
>>> Something has to change here.
>>>
>>> You're missing the point if you think this is a "developer mistake".
>>>
>>
>> Is not just Windows, the DMD calling convention on Linux differs from
>> the system calling convention. For example, some of the naked
>> functions in std.math returning floating point values assumes caller
>> clean up. Where as the C calling convention is callee clean up.
>
>

Exactly. We can do better, and we really should.

-- 
- Alex

On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
> The point is just that: Right now I can write assembly that will work on GDC, LDC, and DMD on non-Windows. It will not work for DMD on Windows. Something has to change here.

If it doesn't work on Windows, it should be versioned out. What we have: http://dlang.org/version.html#PredefinedVersions - versions for LDC, GDC, DMD and Windows - all what you want.

On 25-04-2012 15:06, Kagamin wrote:
> On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
>> The point is just that: Right now I can write assembly that will work
>> on GDC, LDC, and DMD on non-Windows. It will not work for DMD on
>> Windows. Something has to change here.
>
> If it doesn't work on Windows, it should be versioned out. What we have:
> http://dlang.org/version.html#PredefinedVersions - versions for LDC,
> GDC, DMD and Windows - all what you want.

Yes, I added them. :)

You're missing the point. D is providing (or trying to provide) a standard inline assembler, but calling conventions are not standardized enough for it to be useful across compilers. If you're writing inline assembly because you *have* to, you don't just "version it out", you have to write different logic for different compilers, which is a maintenance nightmare.

-- 
- Alex

On Wednesday, 25 April 2012 at 14:32:13 UTC, Alex Rønne Petersen wrote:
> On 25-04-2012 15:06, Kagamin wrote:
>> On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
>>> The point is just that: Right now I can write assembly that will work
>>> on GDC, LDC, and DMD on non-Windows. It will not work for DMD on
>>> Windows. Something has to change here.
>>
>> If it doesn't work on Windows, it should be versioned out. What we have:
>> http://dlang.org/version.html#PredefinedVersions - versions for LDC,
>> GDC, DMD and Windows - all what you want.
>
> Yes, I added them. :)
>
> You're missing the point. D is providing (or trying to provide) a standard inline assembler, but calling conventions are not standardized enough for it to be useful across compilers. If you're writing inline assembly because you *have* to, you don't just "version it out", you have to write different logic for different compilers, which is a maintenance nightmare.

This is exactly what C++ gets blamed for, yet most people fail to realize that the situation is common to all languages that generate native code.

The only reason it works out for C, is that the C ABI is actually the OS ABI, as such all C compilers tend to have a common ABI.

It would be nice if I could use D libraries without having to worry which compiler was used to generate them.

On 25/04/12 17:05, Paulo Pinto wrote:
> On Wednesday, 25 April 2012 at 14:32:13 UTC, Alex Rønne Petersen wrote:
>> On 25-04-2012 15:06, Kagamin wrote:
>>> On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
>>>> The point is just that: Right now I can write assembly that will work
>>>> on GDC, LDC, and DMD on non-Windows. It will not work for DMD on
>>>> Windows. Something has to change here.
>>>
>>> If it doesn't work on Windows, it should be versioned out. What we have:
>>> http://dlang.org/version.html#PredefinedVersions - versions for LDC,
>>> GDC, DMD and Windows - all what you want.
>>
>> Yes, I added them. :)
>>
>> You're missing the point. D is providing (or trying to provide) a
>> standard inline assembler, but calling conventions are not
>> standardized enough for it to be useful across compilers. If you're
>> writing inline assembly because you *have* to, you don't just "version
>> it out", you have to write different logic for different compilers,
>> which is a maintenance nightmare.
>
> This is exactly what C++ gets blamed for, yet most people fail to
> realize that the situation is common to all languages that generate
> native code.

No, it's totally the fault of C++. C++ failed to specify it, so everyone did something different. Then you get this very unfortunate mindset where everyone is so used to it, they don't find it unacceptable any more.

> The only reason it works out for C, is that the C ABI is actually the OS
> ABI, as such all C compilers tend to have a common ABI.

Not true. The ABI for Win32 is __stdcall, not C. Pascal and Fortran calling conventions were always well standardized, too.

> It would be nice if I could use D libraries without having to worry
> which compiler was used to generate them.

Yes. This is mandatory.

It'd be fantastic if we had a calling convention that depended ONLY on the CPU, not on the OS. But I don't know if it is feasible. The Windows64 calling convention is standardized, and it's different to the Linux64 one.

I don't know if it's even possible to use a different calling convention on Win64, there are interactions with system exception handling.

On Wednesday, 25 April 2012 at 15:20:31 UTC, Don Clugston wrote:
> On 25/04/12 17:05, Paulo Pinto wrote:
>> On Wednesday, 25 April 2012 at 14:32:13 UTC, Alex Rønne Petersen wrote:
>>> On 25-04-2012 15:06, Kagamin wrote:
>>>> On Tuesday, 24 April 2012 at 10:29:52 UTC, Alex Rønne Petersen wrote:
>>>>> The point is just that: Right now I can write assembly that will work
>>>>> on GDC, LDC, and DMD on non-Windows. It will not work for DMD on
>>>>> Windows. Something has to change here.
>>>>
>>>> If it doesn't work on Windows, it should be versioned out. What we have:
>>>> http://dlang.org/version.html#PredefinedVersions - versions for LDC,
>>>> GDC, DMD and Windows - all what you want.
>>>
>>> Yes, I added them. :)
>>>
>>> You're missing the point. D is providing (or trying to provide) a
>>> standard inline assembler, but calling conventions are not
>>> standardized enough for it to be useful across compilers. If you're
>>> writing inline assembly because you *have* to, you don't just "version
>>> it out", you have to write different logic for different compilers,
>>> which is a maintenance nightmare.
>>
>> This is exactly what C++ gets blamed for, yet most people fail to
>> realize that the situation is common to all languages that generate
>> native code.
>
> No, it's totally the fault of C++. C++ failed to specify it, so everyone did something different. Then you get this very unfortunate mindset where everyone is so used to it, they don't find it unacceptable any more.
>

As far as I am aware this is the same in all languages. I am not
aware of any ISO or ANSI language standard that specifies ABIs.

>> The only reason it works out for C, is that the C ABI is actually the OS
>> ABI, as such all C compilers tend to have a common ABI.
>
> Not true. The ABI for Win32 is __stdcall, not C. Pascal and Fortran calling conventions were always well standardized, too.
>

For me this is the same, as all C compilers in Win32 are required
to generate __stdcall entry points. Plus since C is nothing more
than a glorified assembler, there is not much to speak about an ABI.
In a way the operating system can be seen as the C language runtime
(I am exaggerating a bit here).

Taking your language's example, which two FORTRAN or Pascal compilers,
in a given OS, are able to mix object or library files?

I am just defending that I should be able to combine a mix of libraries
compiled with DMD, LDC and GDC, without having to worry which is which.

--
Paulo

Am 24.04.2012 10:42, schrieb Alex Rønne Petersen:
> Writing portable code is hard enough as it is. Why do we have to have some random, D-specialized calling convention (only on Win32 and only in DMD)? The result of the current state of things is that extern(D) is essentially useless - it has completely different meanings across compilers. You cannot rely on it at all. If memory serves me right, both LDC and GDC just alias it to extern(C), but DMD insists on using this magical D calling convention on Win32.
> 
> I'm not attacking the D ABI (name mangling) here, but I do think this calling convention needs to either go away, or be optional (i.e. as some extern() argument). We *have* to make extern(D) consistent across compilers, or we'll be no better than the mess that is C and C++; we're advertising a standard inline assembler with support for naked functions, but that support is useless if we don't have a consistent default calling convention.
> 

Introducing a commen calling convention would be one approach. The other would be to templatize D's inline assembler?

On 25-04-2012 19:44, mta`chrono wrote:
> Am 24.04.2012 10:42, schrieb Alex Rønne Petersen:
>> Writing portable code is hard enough as it is. Why do we have to have
>> some random, D-specialized calling convention (only on Win32 and only in
>> DMD)? The result of the current state of things is that extern(D) is
>> essentially useless - it has completely different meanings across
>> compilers. You cannot rely on it at all. If memory serves me right, both
>> LDC and GDC just alias it to extern(C), but DMD insists on using this
>> magical D calling convention on Win32.
>>
>> I'm not attacking the D ABI (name mangling) here, but I do think this
>> calling convention needs to either go away, or be optional (i.e. as some
>> extern() argument). We *have* to make extern(D) consistent across
>> compilers, or we'll be no better than the mess that is C and C++; we're
>> advertising a standard inline assembler with support for naked
>> functions, but that support is useless if we don't have a consistent
>> default calling convention.
>>
>
> Introducing a commen calling convention would be one approach. The other
> would be to templatize D's inline assembler?

All the big compiler back ends are not realistically going to implement some random calling convention because we tell them to.

-- 
- Alex

On Wednesday, 25 April 2012 at 17:51:45 UTC, Alex Rønne Petersen wrote:
>> Introducing a commen calling convention would be one approach. The other
>> would be to templatize D's inline assembler?
>
> All the big compiler back ends are not realistically going to implement some random calling convention because we tell them to.

Hmmm... actually, only the symbols marked with 'export' would matter, we could have our own super optimized calling convention internally... no?