Hi,

Had round one of the code review process, so I'm going to post the main issues here that most affect D users / the platforms they want to run on / the compiler version they want to use.



1) D Inline Asm and naked function support is raising far too many alarm bells. So would just be easier to remove it and avoid all the other comments on why we need middle-end and backend headers in gdc.


2) Code with #if V1 and V2 raised another bell with the request to remove all code that relies on internal macros with proper if() conditions. If something is always going to be turned off, remove it.

So, we shall also be saying bye bye D1 in GDC.  We'll miss you!


3) For anyone who has submitted patches for Mingw and Apple - sorry, but I'm going to have to yank out or alter certain bits.  Apple GCC is irrelevant now, and some Mingw checks look for if(target) when it should really be checking if(host) and vice versa!


Most discussion I would imagine be on the decision to remove D inline assembler support from gdc.  So, nay sayers, do your worst, but unfortunately there is a +1 here for removal.


Regards
Iain

On 19-06-2012 20:19, Iain Buclaw wrote:
> Hi,
>
> Had round one of the code review process, so I'm going to post the main
> issues here that most affect D users / the platforms they want to run on
> / the compiler version they want to use.
>
>
>
> 1) D Inline Asm and naked function support is raising far too many alarm
> bells. So would just be easier to remove it and avoid all the other
> comments on why we need middle-end and backend headers in gdc.
>
>
> 2) Code with #if V1 and V2 raised another bell with the request to
> remove all code that relies on internal macros with proper if()
> conditions. If something is always going to be turned off, remove it.
>
> So, we shall also be saying bye bye D1 in GDC. We'll miss you!
>
>
> 3) For anyone who has submitted patches for Mingw and Apple - sorry, but
> I'm going to have to yank out or alter certain bits. Apple GCC is
> irrelevant now, and some Mingw checks look for if(target) when it should
> really be checking if(host) and vice versa!
>
>
> Most discussion I would imagine be on the decision to remove D inline
> assembler support from gdc. So, nay sayers, do your worst, but
> unfortunately there is a +1 here for removal.
>
>
> Regards
> Iain

+1 for removal of inline asm.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

Iain Buclaw:

> Most discussion I would imagine be on the decision to remove D inline assembler support from gdc.  So, nay sayers, do your worst, but unfortunately there is a +1 here for removal.

I suggest to try to do the opposite, that it to try to increase
the current conformance of GDC to D/DMD specs (like introducing D
calling conventions, if they are missing).

Bye,
bearophile

On 19-06-2012 20:44, bearophile wrote:
> Iain Buclaw:
>
>> Most discussion I would imagine be on the decision to remove D inline
>> assembler support from gdc. So, nay sayers, do your worst, but
>> unfortunately there is a +1 here for removal.
>
> I suggest to try to do the opposite, that it to try to increase
> the current conformance of GDC to D/DMD specs (like introducing D
> calling conventions, if they are missing).
>
> Bye,
> bearophile

Not gonna happen. The D calling convention is Windows/32-bit only. Implementing a new calling convention in all major compiler back ends is not something you do trivially. Further, I doubt the GCC maintainers would actually approve of doing this.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 19 June 2012 19:44, bearophile <bearophileHUGS@lycos.com> wrote:
> Iain Buclaw:
>
>
>> Most discussion I would imagine be on the decision to remove D inline assembler support from gdc.  So, nay sayers, do your worst, but unfortunately there is a +1 here for removal.
>
>
> I suggest to try to do the opposite, that it to try to increase the current conformance of GDC to D/DMD specs (like introducing D calling conventions, if they are missing).
>
> Bye,
> bearophile

The D spec states:

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.  </insert D calling convention>


So GDC already conforms to the spec on all platforms except Windows x86.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 19 June 2012 19:51, Alex Rønne Petersen <alex@lycus.org> wrote:
> On 19-06-2012 20:44, bearophile wrote:
>>
>> Iain Buclaw:
>>
>>> Most discussion I would imagine be on the decision to remove D inline assembler support from gdc. So, nay sayers, do your worst, but unfortunately there is a +1 here for removal.
>>
>>
>> I suggest to try to do the opposite, that it to try to increase the current conformance of GDC to D/DMD specs (like introducing D calling conventions, if they are missing).
>>
>> Bye,
>> bearophile
>
>
> Not gonna happen. The D calling convention is Windows/32-bit only. Implementing a new calling convention in all major compiler back ends is not something you do trivially. Further, I doubt the GCC maintainers would actually approve of doing this.
>

To quote from one of the i386 backend maintainers:
---
"Does D *really* require a new calling convention?  Also does it *really* require naked support?  I think naked support is a bad idea and people who require naked support should be writing an assembly function wrapper."
---


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Alex Rønne Petersen:

>Further, I doubt the GCC maintainers would actually approve of doing this.

I know nothing about how GCC maintainers do their work. Can you explain why they have accepted a D front-end but refuse a change like that? Are they believing that D is a kind of re-syntaxed C/C++ that requires zero back-end changes?

Are LLVM developers sharing the same opinions? In the LLVM blog I have read plenty about small but significant changes in LLVM needed to implement an efficient back-end for GHC (the main Haskell compiler), so are LLVM developers different and more gentle than the GCC devs?

Thank you for your answers,
bearophile

Iain Buclaw:

> "Does D *really* require a new calling convention?
> Also does it *really* require naked support?

I guess the answers are yes and yes.


> I think naked support is a bad idea

Maybe he/she's wrong, and it's a good idea. Where are the deep discussions that justify his/her words?


> and people who require naked support should be writing an assembly function wrapper."

Why? And why they have to impose a design on another language they haven't designed? They are the oweners of their compilers and D is a guest, but imposing too much of your customs on a guest is not polite.

Bye,
bearophile

On 19-06-2012 21:05, bearophile wrote:
> Iain Buclaw:
>
>> "Does D *really* require a new calling convention?
>> Also does it *really* require naked support?
>
> I guess the answers are yes and yes.
>
>
>> I think naked support is a bad idea
>
> Maybe he/she's wrong, and it's a good idea. Where are the deep
> discussions that justify his/her words?
>
>
>> and people who require naked support should be writing an assembly
>> function wrapper."
>
> Why? And why they have to impose a design on another language they
> haven't designed? They are the oweners of their compilers and D is a
> guest, but imposing too much of your customs on a guest is not polite.
>
> Bye,
> bearophile

Because the guest wants to rearrange the host's home.

D better have a good reason to do so. So far, I have seen none.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Tue, 2012-06-19 at 20:19 +0200, Iain Buclaw wrote:
[…]
> 1) D Inline Asm and naked function support is raising far too many alarm bells. So would just be easier to remove it and avoid all the other comments on why we need middle-end and backend headers in gdc.

I can do without inline assembly language.  If I need assembly language code, I can write a function in assembly language.

> 2) Code with #if V1 and V2 raised another bell with the request to remove all code that relies on internal macros with proper if() conditions. If something is always going to be turned off, remove it.
> 
> So, we shall also be saying bye bye D1 in GDC.  We'll miss you!

I never used V1 (though I do have the Tango book) so enforcing V2 will
nto be a problem. Actually this means I can delete 65% of the SCons D
tool :-)))))))))

> 3) For anyone who has submitted patches for Mingw and Apple - sorry, but I'm going to have to yank out or alter certain bits. Apple GCC is irrelevant now, and some Mingw checks look for if(target) when it should really be checking if(host) and vice versa!

Is Apple GCC irrelevant? Apple itself has switched to Clang but GCC is still available via MacPorts – or am I missing something obvious, I am only an occasional Mac OS X user.

> Most discussion I would imagine be on the decision to remove D inline assembler support from gdc.  So, nay sayers, do your worst, but unfortunately there is a +1 here for removal.

I could put in a -1 if pushed, but +1 is fine by me!

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder