View mode: basic / threaded / horizontal-split · Log in · Help
June 19, 2012
GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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';
June 19, 2012
Re: GDC review process.
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';
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
June 19, 2012
Re: GDC review process.
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home