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
next sibling parent =?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
prev sibling parent 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=

 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=



 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
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 next 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
prev sibling 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