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.

-- 
- Alex

There are lots of times, when a specialized custom calling convention
is necessary.
For instance, I need a dynamic typing subsystem, to create abstract
state machines, which can be effortlessly adapted to run-time
heterogeneous data.
I already made a function, that takes arbitrary arguments and tightly
packs them in a single chunk of memory, making a run-time defined
structures.
A new calling convention would normalize the ABI of all functions,
making them all take a single pointer to such a structure. This will
allow to safely discard the static type info of the functions,
allowing them to be stored in and called from statically homogeneous
containers (like the ones inside an abstract state machine).
Currently, in order to do that, you'd need to define a function in a
very weird way and use tons of mixins to inject naked function
assembly to do this without the overhead of going through the current
static-only type system and calling conventions.

A simple option of allowing to define custom calling convention would already lead to library solutions, that make D equally effective static and dynamic typed language simultaneously (which would be beautifully integrated with each other).

On Tue, Apr 24, 2012 at 1:10 PM, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 24 April 2012 10:08, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>> On 24 April 2012 09:42, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>>> 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.
>>>
>>
>> extern(System) would be a more accurate description of what GDC does,
>> as it uses the default calling convention for the target/platform you
>> are running on, which may not neccessarily be extern(C).
>>
>
> s/ running on / compiling for /
>
>
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';



-- 
Bye,
Gor Gyolchanyan.

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.

On 24-04-2012 11:41, Gor Gyolchanyan wrote:
> There are lots of times, when a specialized custom calling convention
> is necessary.
> For instance, I need a dynamic typing subsystem, to create abstract
> state machines, which can be effortlessly adapted to run-time
> heterogeneous data.
> I already made a function, that takes arbitrary arguments and tightly
> packs them in a single chunk of memory, making a run-time defined
> structures.
> A new calling convention would normalize the ABI of all functions,
> making them all take a single pointer to such a structure. This will
> allow to safely discard the static type info of the functions,
> allowing them to be stored in and called from statically homogeneous
> containers (like the ones inside an abstract state machine).
> Currently, in order to do that, you'd need to define a function in a
> very weird way and use tons of mixins to inject naked function
> assembly to do this without the overhead of going through the current
> static-only type system and calling conventions.
>
> A simple option of allowing to define custom calling convention would
> already lead to library solutions, that make D equally effective
> static and dynamic typed language simultaneously (which would be
> beautifully integrated with each other).
>
> On Tue, Apr 24, 2012 at 1:10 PM, Iain Buclaw<ibuclaw@ubuntu.com>  wrote:
>> On 24 April 2012 10:08, Iain Buclaw<ibuclaw@ubuntu.com>  wrote:
>>> On 24 April 2012 09:42, Alex Rønne Petersen<xtzgzorex@gmail.com>  wrote:
>>>> 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.
>>>>
>>>
>>> extern(System) would be a more accurate description of what GDC does,
>>> as it uses the default calling convention for the target/platform you
>>> are running on, which may not neccessarily be extern(C).
>>>
>>
>> s/ running on / compiling for /
>>
>>
>> --
>> Iain Buclaw
>>
>> *(p<  e ? p++ : p) = (c&  0x0f) + '0';
>
>
>

I'm not sure what that has to do with the state of extern(D), but yes, I agree that custom calling conventions could be useful in some specialized cases.

-- 
- Alex

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".

-- 
- Alex

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.

-- 
Iain Buclaw

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

On 24-04-2012 16:39, 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.
>

It just gets better and better! :)

-- 
- Alex

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).

As D is more than just C or C++ it may take account for providing it's own calling convention.

_BUT_ (That's the point, I agree to Alex), it needs to be consistent across _different compilers for the same plattform_.

Maybe someone can point out the benefits of having a different calling convention on linux and windows for the same target machine.

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.