View mode: basic / threaded / horizontal-split · Log in · Help
April 24, 2012
Can we kill the D calling convention already?
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
April 24, 2012
Re: Can we kill the D calling convention already?
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.
April 24, 2012
Re: Can we kill the D calling convention already?
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.
April 24, 2012
Re: Can we kill the D calling convention already?
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
April 24, 2012
Re: Can we kill the D calling convention already?
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
April 24, 2012
Re: Can we kill the D calling convention already?
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';
April 24, 2012
Re: Can we kill the D calling convention already?
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
April 24, 2012
Re: Can we kill the D calling convention already?
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).
April 24, 2012
Re: Can we kill the D calling convention already?
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.
April 24, 2012
Re: Can we kill the D calling convention already?
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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home