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

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.

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

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

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

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?
>

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';

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

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

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