www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD compiler switch to set default extern() linkage?

reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 05 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Apr 05 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 05 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Apr 05 2012
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 05 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 5 April 2012 11:28, Alex R=F8nne Petersen <xtzgzorex gmail.com> wrote:

 On 05-04-2012 12:16, Dmitry Olshansky wrote:

 On 05.04.2012 13:49, Alex R=F8nne 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 supporti=


ng

 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" callin=






g

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


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 05 2012
parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
Apr 06 2012
parent bearophile <bearophileHUGS lycos.com> writes:
Marco Leise:


 As for the D calling convention, it needs an entry here:
http://en.wikipedia.org/wiki/X86_calling_conventions :D


I agree. Any one qualified to add to that page?

Bye,
bearophile
Apr 06 2012
prev sibling next sibling parent reply Don Clugston <dac nospam.com> writes:
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?
Apr 05 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 05 2012
prev sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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
Apr 05 2012