Thread overview | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gor Gyolchanyan | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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.
|
Copyright © 1999-2021 by the D Language Foundation