View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2012
DMD compiler switch to set default extern() linkage?
Hi,

It is no secret that DMD is the only compiler in existence that follows 
the "D" calling convention (and even then, only on some platforms, 
seemingly?). Both GDC and LDC use the C calling convention of the 
platform by default (and don't even have options to use the "D" calling 
convention because their back ends don't support it at all).

I'm writing a virtual machine. As far as I am concerned, the "D" calling 
convention adds nothing but complexity to the configuration support 
matrix. The calling convention situation across platforms is already 
utterly insane enough as it is. I would not have a problem with 
supporting the "D" calling convention if all compilers followed it. But 
they don't. And it is only specified for x86. Even in an ideal world, 
the "D" calling convention won't exist everywhere because it isn't 
intended to.

So yes, we could just say "but eventually, those compilers should 
support it!". But realistically, it is not going to happen. Those 
compilers have no reason to implement yet another calling convention 
that is entirely specific to x86.

I don't think it's good that DMD forces all functions to use the "D" 
calling convention by default. However, I accept that it is an 
established situation, and changing is now is not an option.

That said, I believe a compiler switch to set the default extern() 
linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d

Thoughts?

-- 
- Alex
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
Le 05/04/2012 11:49, Alex Rønne Petersen a écrit :
> Hi,
>
> It is no secret that DMD is the only compiler in existence that follows
> the "D" calling convention (and even then, only on some platforms,
> seemingly?). Both GDC and LDC use the C calling convention of the
> platform by default (and don't even have options to use the "D" calling
> convention because their back ends don't support it at all).
>
> I'm writing a virtual machine. As far as I am concerned, the "D" calling
> convention adds nothing but complexity to the configuration support
> matrix. The calling convention situation across platforms is already
> utterly insane enough as it is. I would not have a problem with
> supporting the "D" calling convention if all compilers followed it. But
> they don't. And it is only specified for x86. Even in an ideal world,
> the "D" calling convention won't exist everywhere because it isn't
> intended to.
>
> So yes, we could just say "but eventually, those compilers should
> support it!". But realistically, it is not going to happen. Those
> compilers have no reason to implement yet another calling convention
> that is entirely specific to x86.
>
> I don't think it's good that DMD forces all functions to use the "D"
> calling convention by default. However, I accept that it is an
> established situation, and changing is now is not an option.
>
> That said, I believe a compiler switch to set the default extern()
> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d
>
> Thoughts?
>

Extern(XXX) change the calling convention, but also the mangling. 
Setting it by default would create a huge mess. It is, for example, sure 
to create massive mangled name collision if extern(C) is applied by 
default (C doesn't mangle argument types and doesn't support modules).

I understand the issue, but the solution would be a switch to force ABI, 
not extern.
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 12:02, deadalnix wrote:
> Le 05/04/2012 11:49, Alex Rønne Petersen a écrit :
>> Hi,
>>
>> It is no secret that DMD is the only compiler in existence that follows
>> the "D" calling convention (and even then, only on some platforms,
>> seemingly?). Both GDC and LDC use the C calling convention of the
>> platform by default (and don't even have options to use the "D" calling
>> convention because their back ends don't support it at all).
>>
>> I'm writing a virtual machine. As far as I am concerned, the "D" calling
>> convention adds nothing but complexity to the configuration support
>> matrix. The calling convention situation across platforms is already
>> utterly insane enough as it is. I would not have a problem with
>> supporting the "D" calling convention if all compilers followed it. But
>> they don't. And it is only specified for x86. Even in an ideal world,
>> the "D" calling convention won't exist everywhere because it isn't
>> intended to.
>>
>> So yes, we could just say "but eventually, those compilers should
>> support it!". But realistically, it is not going to happen. Those
>> compilers have no reason to implement yet another calling convention
>> that is entirely specific to x86.
>>
>> I don't think it's good that DMD forces all functions to use the "D"
>> calling convention by default. However, I accept that it is an
>> established situation, and changing is now is not an option.
>>
>> That said, I believe a compiler switch to set the default extern()
>> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C
>> foo.d
>>
>> Thoughts?
>>
>
> Extern(XXX) change the calling convention, but also the mangling.
> Setting it by default would create a huge mess. It is, for example, sure
> to create massive mangled name collision if extern(C) is applied by
> default (C doesn't mangle argument types and doesn't support modules).
>
> I understand the issue, but the solution would be a switch to force ABI,
> not extern.

OK, so what we really want is an option to specify what calling 
convention to use when extern(D) is used. Something like: dmd -cc=C/D foo.d

-- 
- Alex
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05.04.2012 13:49, Alex Rønne Petersen wrote:
> Hi,
>
> It is no secret that DMD is the only compiler in existence that follows
> the "D" calling convention (and even then, only on some platforms,
> seemingly?).

IMHO It's the only sane convention I've seen. C's default of caller-side 
cleanup adds nothing but a mess for years to clean up. And code size 
bloat for no good reason. I think it was just a "cool trick" to make 
printf work, bleh. And extern(D) still allows that.

Both GDC and LDC use the C calling convention of the
> platform by default (and don't even have options to use the "D" calling
> convention because their back ends don't support it at all).
>
> I'm writing a virtual machine. As far as I am concerned, the "D" calling
> convention adds nothing but complexity to the configuration support
> matrix. The calling convention situation across platforms is already
> utterly insane enough as it is. I would not have a problem with
> supporting the "D" calling convention if all compilers followed it. But
> they don't. And it is only specified for x86. Even in an ideal world,
> the "D" calling convention won't exist everywhere because it isn't
> intended to.
>
> So yes, we could just say "but eventually, those compilers should
> support it!".

Yup, let's stop being kids and copying whatever big ones are doing. 
Standards sort of happen like this:  people just start doing things 
differently, then others like it and follow suit and then it's all 
written on a bunch (virtual) paper with ISO number somewhere.

But realistically, it is not going to happen. Those
> compilers have no reason to implement yet another calling convention
> that is entirely specific to x86.

Extend it, I've seen some movement on ARM side.

>
> I don't think it's good that DMD forces all functions to use the "D"
> calling convention by default. However, I accept that it is an
> established situation, and changing is now is not an option.
>
> That said, I believe a compiler switch to set the default extern()
> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d
>
> Thoughts?
>


-- 
Dmitry Olshansky
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 12:16, Dmitry Olshansky wrote:
> On 05.04.2012 13:49, Alex Rønne Petersen wrote:
>> Hi,
>>
>> It is no secret that DMD is the only compiler in existence that follows
>> the "D" calling convention (and even then, only on some platforms,
>> seemingly?).
>
> IMHO It's the only sane convention I've seen. C's default of caller-side
> cleanup adds nothing but a mess for years to clean up. And code size
> bloat for no good reason. I think it was just a "cool trick" to make
> printf work, bleh. And extern(D) still allows that.

Right. I won't deny that the "D" calling convention is good, but 
supporting it is not practical.

>
> Both GDC and LDC use the C calling convention of the
>> platform by default (and don't even have options to use the "D" calling
>> convention because their back ends don't support it at all).
>>
>> I'm writing a virtual machine. As far as I am concerned, the "D" calling
>> convention adds nothing but complexity to the configuration support
>> matrix. The calling convention situation across platforms is already
>> utterly insane enough as it is. I would not have a problem with
>> supporting the "D" calling convention if all compilers followed it. But
>> they don't. And it is only specified for x86. Even in an ideal world,
>> the "D" calling convention won't exist everywhere because it isn't
>> intended to.
>>
>> So yes, we could just say "but eventually, those compilers should
>> support it!".
>
> Yup, let's stop being kids and copying whatever big ones are doing.
> Standards sort of happen like this: people just start doing things
> differently, then others like it and follow suit and then it's all
> written on a bunch (virtual) paper with ISO number somewhere.

Good luck convincing the GCC guys to merge your D ABI patch. ;)

>
> But realistically, it is not going to happen. Those
>> compilers have no reason to implement yet another calling convention
>> that is entirely specific to x86.
>
> Extend it, I've seen some movement on ARM side.

Extend what?

>
>>
>> I don't think it's good that DMD forces all functions to use the "D"
>> calling convention by default. However, I accept that it is an
>> established situation, and changing is now is not an option.
>>
>> That said, I believe a compiler switch to set the default extern()
>> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C
>> foo.d
>>
>> Thoughts?
>>
>
>


-- 
- Alex
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05/04/12 11:49, Alex Rønne Petersen wrote:
> Hi,
>
> It is no secret that DMD is the only compiler in existence that follows
> the "D" calling convention (and even then, only on some platforms,
> seemingly?). Both GDC and LDC use the C calling convention of the
> platform by default (and don't even have options to use the "D" calling
> convention because their back ends don't support it at all).

There are couple of separate issues here, I think. The most important 
issue is the name mangling. That MUST be supported by all compilers, on 
all platforms. The binary layout of objects MUST also be consistent 
across a processor. If any currently don't obey this, it's a bug.


That leaves parameter passing conventions, which are indeed a problem.
There are a couple of DMD oddities, like passing the last parameter in 
EAX. The DMD calling convention is not particularly efficient. It's just 
plain weird. The whole thing is rather peculiar because different OSes 
impose different restrictions -- eg, stack has to be aligned on OSX, 
Linux64 and Windows64 are radically different  -- so it isn't even 
possible to be identical on all systems.


> I'm writing a virtual machine. As far as I am concerned, the "D" calling
> convention adds nothing but complexity to the configuration support
> matrix. The calling convention situation across platforms is already
> utterly insane enough as it is. I would not have a problem with
> supporting the "D" calling convention if all compilers followed it. But
> they don't. And it is only specified for x86. Even in an ideal world,
> the "D" calling convention won't exist everywhere because it isn't
> intended to.
>
> So yes, we could just say "but eventually, those compilers should
> support it!". But realistically, it is not going to happen. Those
> compilers have no reason to implement yet another calling convention
> that is entirely specific to x86.
>
> I don't think it's good that DMD forces all functions to use the "D"
> calling convention by default. However, I accept that it is an
> established situation, and changing is now is not an option.
>
> That said, I believe a compiler switch to set the default extern()
> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d
>
> Thoughts?
>
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 5 April 2012 11:28, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
> On 05-04-2012 12:16, Dmitry Olshansky wrote:
>>
>> On 05.04.2012 13:49, Alex Rønne Petersen wrote:
>>>
>>> Hi,
>>>
>>> It is no secret that DMD is the only compiler in existence that follows
>>> the "D" calling convention (and even then, only on some platforms,
>>> seemingly?).
>>
>>
>> IMHO It's the only sane convention I've seen. C's default of caller-side
>> cleanup adds nothing but a mess for years to clean up. And code size
>> bloat for no good reason. I think it was just a "cool trick" to make
>> printf work, bleh. And extern(D) still allows that.
>
>
> Right. I won't deny that the "D" calling convention is good, but supporting
> it is not practical.
>
>
>>
>> Both GDC and LDC use the C calling convention of the
>>>
>>> platform by default (and don't even have options to use the "D" calling
>>> convention because their back ends don't support it at all).
>>>
>>> I'm writing a virtual machine. As far as I am concerned, the "D" calling
>>> convention adds nothing but complexity to the configuration support
>>> matrix. The calling convention situation across platforms is already
>>> utterly insane enough as it is. I would not have a problem with
>>> supporting the "D" calling convention if all compilers followed it. But
>>> they don't. And it is only specified for x86. Even in an ideal world,
>>> the "D" calling convention won't exist everywhere because it isn't
>>> intended to.
>>>
>>> So yes, we could just say "but eventually, those compilers should
>>> support it!".
>>
>>
>> Yup, let's stop being kids and copying whatever big ones are doing.
>> Standards sort of happen like this: people just start doing things
>> differently, then others like it and follow suit and then it's all
>> written on a bunch (virtual) paper with ISO number somewhere.
>
>
> Good luck convincing the GCC guys to merge your D ABI patch. ;)
>

They were equally mortified when I mentioned 'naked' functions. :~)


Point 2: If I were to be picky, the spec says that 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.

So as far as I am concerned GDC follows the specification of the D
language to the letter, except maybe for Windows x86 - but I don't
think MinGW counts as the same platform - so it is all still
debatable. ;)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 12:57, Don Clugston wrote:
> On 05/04/12 11:49, Alex Rønne Petersen wrote:
>> Hi,
>>
>> It is no secret that DMD is the only compiler in existence that follows
>> the "D" calling convention (and even then, only on some platforms,
>> seemingly?). Both GDC and LDC use the C calling convention of the
>> platform by default (and don't even have options to use the "D" calling
>> convention because their back ends don't support it at all).
>
> There are couple of separate issues here, I think. The most important
> issue is the name mangling. That MUST be supported by all compilers, on
> all platforms. The binary layout of objects MUST also be consistent
> across a processor. If any currently don't obey this, it's a bug.

Right. I understand I should have been clearer here. What I want to do 
is force C calling convention but still use D name mangling.

>
>
> That leaves parameter passing conventions, which are indeed a problem.
> There are a couple of DMD oddities, like passing the last parameter in
> EAX. The DMD calling convention is not particularly efficient. It's just
> plain weird. The whole thing is rather peculiar because different OSes
> impose different restrictions -- eg, stack has to be aligned on OSX,
> Linux64 and Windows64 are radically different -- so it isn't even
> possible to be identical on all systems.
>
>
>> I'm writing a virtual machine. As far as I am concerned, the "D" calling
>> convention adds nothing but complexity to the configuration support
>> matrix. The calling convention situation across platforms is already
>> utterly insane enough as it is. I would not have a problem with
>> supporting the "D" calling convention if all compilers followed it. But
>> they don't. And it is only specified for x86. Even in an ideal world,
>> the "D" calling convention won't exist everywhere because it isn't
>> intended to.
>>
>> So yes, we could just say "but eventually, those compilers should
>> support it!". But realistically, it is not going to happen. Those
>> compilers have no reason to implement yet another calling convention
>> that is entirely specific to x86.
>>
>> I don't think it's good that DMD forces all functions to use the "D"
>> calling convention by default. However, I accept that it is an
>> established situation, and changing is now is not an option.
>>
>> That said, I believe a compiler switch to set the default extern()
>> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C
>> foo.d
>>
>> Thoughts?
>>
>


-- 
- Alex
April 05, 2012
Re: DMD compiler switch to set default extern() linkage?
On 05-04-2012 11:49, Alex Rønne Petersen wrote:
> Hi,
>
> It is no secret that DMD is the only compiler in existence that follows
> the "D" calling convention (and even then, only on some platforms,
> seemingly?). Both GDC and LDC use the C calling convention of the
> platform by default (and don't even have options to use the "D" calling
> convention because their back ends don't support it at all).
>
> I'm writing a virtual machine. As far as I am concerned, the "D" calling
> convention adds nothing but complexity to the configuration support
> matrix. The calling convention situation across platforms is already
> utterly insane enough as it is. I would not have a problem with
> supporting the "D" calling convention if all compilers followed it. But
> they don't. And it is only specified for x86. Even in an ideal world,
> the "D" calling convention won't exist everywhere because it isn't
> intended to.
>
> So yes, we could just say "but eventually, those compilers should
> support it!". But realistically, it is not going to happen. Those
> compilers have no reason to implement yet another calling convention
> that is entirely specific to x86.
>
> I don't think it's good that DMD forces all functions to use the "D"
> calling convention by default. However, I accept that it is an
> established situation, and changing is now is not an option.
>
> That said, I believe a compiler switch to set the default extern()
> linkage is not an unreasonable thing to ask for, e.g.: dmd -extern=C foo.d
>
> Thoughts?
>

https://github.com/D-Programming-Language/dmd/pull/868

-- 
- Alex
April 07, 2012
Re: DMD compiler switch to set default extern() linkage?
Am Thu, 5 Apr 2012 12:15:28 +0100
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:

> They were equally mortified when I mentioned 'naked' functions. :~)

I don't remember the response to be univocal. At least one guy tried to convince the others, that support for naked functions would benefit other platforms/languages as well.

As for the D calling convention, it needs an entry here: http://en.wikipedia.org/wiki/X86_calling_conventions :D
There are other callee-cleans-up conventions, too: Pascal, stdcall, fastcall

-- 
Marco
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home