www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Milestone - DMD front end is now 100% D!

reply Walter Bright <newshound2 digitalmars.com> writes:
The last one:

https://github.com/dlang/dmd/pull/6310
Dec 14 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
ACHIEVEMENT UNLOCKED!
Dec 14 2016
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 15 December 2016 at 01:04:54 UTC, Walter Bright 
wrote:

 The last one:

 https://github.com/dlang/dmd/pull/6310


Great!  I see you've started moving the backend to D too, about 
5% done so far.

How far do you plan to go in bringing D idioms to the compiler 
itself?  A simple grep shows 3 C-style `for` loops in the 
frontend for every D `foreach`.  Do you plan on using ranges and 
algorithms, which likely means relying on Phobos at some point?  
Any plans to turn on the GC someday?  Please enlighten us on your 
roadmap for how far you want to take the D conversion process.
Dec 14 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2016 7:21 PM, Joakim wrote:

 How far do you plan to go in bringing D idioms to the compiler itself?  A
simple
 grep shows 3 C-style `for` loops in the frontend for every D `foreach`.  Do you
 plan on using ranges and algorithms, which likely means relying on Phobos at
 some point?  Any plans to turn on the GC someday?  Please enlighten us on your
 roadmap for how far you want to take the D conversion process.


I plan to go eventually all the way. But it really needs to be 100% D first.
Dec 14 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 15 December 2016 at 05:03:20 UTC, Walter Bright 
wrote:

 On 12/14/2016 7:21 PM, Joakim wrote:

 How far do you plan to go in bringing D idioms to the compiler 
 itself?  A simple
 grep shows 3 C-style `for` loops in the frontend for every D 
 `foreach`.  Do you
 plan on using ranges and algorithms, which likely means 
 relying on Phobos at
 some point?  Any plans to turn on the GC someday?  Please 
 enlighten us on your
 roadmap for how far you want to take the D conversion process.


 I plan to go eventually all the way. But it really needs to be 
 100% D first.


Please, no :-(
Mir needs betterC DMD FE
Dec 14 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko 
wrote:

 Please, no :-(
 Mir needs betterC DMD FE


What for ?
Are you using the compiler frontend ?
And the frontend is not only using the betterC subset.
So you could not be using it right now.
Dec 15 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 15 December 2016 at 13:46:36 UTC, Stefan Koch wrote:

 On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko 
 wrote:

 Please, no :-(
 Mir needs betterC DMD FE


 What for ?
 Are you using the compiler frontend ?
 And the frontend is not only using the betterC subset.
 So you could not be using it right now.


Yes, I hope I will be able to use ldc/gdc on new targets, which 
do not have DRuntime.
Dec 15 2016
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On Thursday, 15 December 2016 at 14:14:41 UTC, Ilya Yaroshenko 
wrote:

 On Thursday, 15 December 2016 at 13:46:36 UTC, Stefan Koch 
 wrote:

 On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko 
 wrote:

 Please, no :-(
 Mir needs betterC DMD FE


 What for ?
 Are you using the compiler frontend ?
 And the frontend is not only using the betterC subset.
 So you could not be using it right now.


 Yes, I hope I will be able to use ldc/gdc on new targets, which 
 do not have DRuntime.


There is nothing wrong with dmd then.
Most of the code related to -betterC is in the glue code which 
means you need to bug the ldc and gdc devs. Either way, if they 
don't have a working druntime don't expect codegen to be valid 
for said target.
Dec 15 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 15 December 2016 at 14:40:55 UTC, Rikki Cattermole 
wrote:

 On Thursday, 15 December 2016 at 14:14:41 UTC, Ilya Yaroshenko 
 wrote:

 On Thursday, 15 December 2016 at 13:46:36 UTC, Stefan Koch 
 wrote:

 On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya 
 Yaroshenko wrote:

 Please, no :-(
 Mir needs betterC DMD FE


 What for ?
 Are you using the compiler frontend ?
 And the frontend is not only using the betterC subset.
 So you could not be using it right now.


 Yes, I hope I will be able to use ldc/gdc on new targets, 
 which do not have DRuntime.


 There is nothing wrong with dmd then.
 Most of the code related to -betterC is in the glue code which 
 means you need to bug the ldc and gdc devs. Either way, if they 
 don't have a working druntime don't expect codegen to be valid 
 for said target.


If  DMD FE is a betterC library, then DRuntime is not required to 
build a betterC D program with LDC/GCC, is no it?
Dec 15 2016
parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 15 December 2016 at 18:43, Ilya Yaroshenko via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 15 December 2016 at 14:40:55 UTC, Rikki Cattermole wrote:

 On Thursday, 15 December 2016 at 14:14:41 UTC, Ilya Yaroshenko wrote:

 On Thursday, 15 December 2016 at 13:46:36 UTC, Stefan Koch wrote:

 On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko wrote:

 Please, no :-(
 Mir needs betterC DMD FE



 What for ?
 Are you using the compiler frontend ?
 And the frontend is not only using the betterC subset.
 So you could not be using it right now.



 Yes, I hope I will be able to use ldc/gdc on new targets, which do not
 have DRuntime.



 There is nothing wrong with dmd then.
 Most of the code related to -betterC is in the glue code which means you
 need to bug the ldc and gdc devs. Either way, if they don't have a working
 druntime don't expect codegen to be valid for said target.



 If  DMD FE is a betterC library, then DRuntime is not required to build a
 betterC D program with LDC/GCC, is no it?


I think I understand what you are trying to say, but I've had to
re-read it at least a dozen times because you' either grok very little
about how the internals are threaded together, or fully grok that but
invented your own words to describe them.

In either case, you're complaints are easily resolved by using a
cross-compiler.  You don't need to building D programs for new targets
on the same CPU that will be running the program.

And I think this is the point that you are missing.  Even though you
are alluding to wanting a D compiler that does not depend on druntime
(what you call betterC, which is at best a gross misunderstanding of
what betterC actually does).

To almost prove a point, there are 26 cross compilers for GDC in
Debian, almost all of which do not have druntime library support
(yet).

https://packages.debian.org/search?suite=stretch§ion=all&arch=any&searchon=names&keywords=gdc-6-
Dec 15 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 15 December 2016 at 19:15:41 UTC, Iain Buclaw wrote:

 On 15 December 2016 at 18:43, Ilya Yaroshenko via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:

 [...]


 I think I understand what you are trying to say, but I've had 
 to re-read it at least a dozen times because you' either grok 
 very little about how the internals are threaded together, or 
 fully grok that but invented your own words to describe them.

 In either case, you're complaints are easily resolved by using 
 a cross-compiler.  You don't need to building D programs for 
 new targets on the same CPU that will be running the program.

 And I think this is the point that you are missing.  Even 
 though you are alluding to wanting a D compiler that does not 
 depend on druntime (what you call betterC, which is at best a 
 gross misunderstanding of what betterC actually does).

 To almost prove a point, there are 26 cross compilers for GDC 
 in Debian, almost all of which do not have druntime library 
 support (yet).

 https://packages.debian.org/search?suite=stretch§ion=all&arch=any&searchon=names&keywords=gdc-6-


Ah, this is awesome! Thank you!
I though that we have not easy way for cross-compilation. If 
cross-compilation is not a problem then I am OK about DMD FE 
depends on DRuntime.

BTW, when the next GDC release will be available?
Dec 15 2016
parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 15 December 2016 at 20:46, Ilya Yaroshenko via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 15 December 2016 at 19:15:41 UTC, Iain Buclaw wrote:

 On 15 December 2016 at 18:43, Ilya Yaroshenko via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 [...]



 I think I understand what you are trying to say, but I've had to re-read
 it at least a dozen times because you' either grok very little about how the
 internals are threaded together, or fully grok that but invented your own
 words to describe them.

 In either case, you're complaints are easily resolved by using a
 cross-compiler.  You don't need to building D programs for new targets on
 the same CPU that will be running the program.

 And I think this is the point that you are missing.  Even though you are
 alluding to wanting a D compiler that does not depend on druntime (what you
 call betterC, which is at best a gross misunderstanding of what betterC
 actually does).

 To almost prove a point, there are 26 cross compilers for GDC in Debian,
 almost all of which do not have druntime library support (yet).


 https://packages.debian.org/search?suite=stretch§ion=all&arch=any&searchon=names&keywords=gdc-6-



 Ah, this is awesome! Thank you!
 I though that we have not easy way for cross-compilation. If
 cross-compilation is not a problem then I am OK about DMD FE depends on
 DRuntime.

 BTW, when the next GDC release will be available?


GCC will release 6.3 before Christmas, I'll try to co-ordinate getting
downloadable binaries for travisCI out at the same time also.

Bear in mind that GDC will be feature complete up to 2.068.2, but
includes a number of bug fixes from latter versions.  This will be the
direction that I anticipate to head in until a time comes where the
frontend exposes everything GDC depends upon in order to bootstrap to
the latest stable branch.
Dec 15 2016
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 15 December 2016 at 19:58:50 UTC, Iain Buclaw wrote:

 This will be the direction that I anticipate to head in until a 
 time comes where the frontend exposes everything GDC depends 
 upon in order to bootstrap to the latest stable branch.


Is there a good list of what is necessary somewhere publicly 
visible?
Dec 15 2016
parent Iain Buclaw via Digitalmars-d-announce writes:
On 15 December 2016 at 21:03, John Colvin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 15 December 2016 at 19:58:50 UTC, Iain Buclaw wrote:

 This will be the direction that I anticipate to head in until a time comes
 where the frontend exposes everything GDC depends upon in order to bootstrap
 to the latest stable branch.



 Is there a good list of what is necessary somewhere publicly visible?


Not really, as I will only know the full extent when either I or
someone else sits down and tries it out.

I can of course update the GDC on-going projects page that someone
reminds me to do on a yearly basis before GSOC comes round the corner,
but that quickly goes out of date within a month or two.

I can say that I anticipate the following will need fixing though:

- Backport CTFloat from upstream.
- Remove 'import ddmd.mars' from all frontend modules.
- Add many more static create functions - TypeStruct::create,
StructDeclaration::create, there are probably a dozen or so more.

Here's the wiki that needs TLC. http://wiki.dlang.org/GDC/ProjectIdeas

Regards.
Dec 15 2016
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 15 December 2016 at 01:04:54 UTC, Walter Bright 
wrote:

 The last one:

 https://github.com/dlang/dmd/pull/6310



Wow! That *is* something!
Great news and well-done!
Dec 15 2016
prev sibling parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 15 December 2016 at 01:04:54 UTC, Walter Bright 
wrote:

 https://github.com/dlang/dmd/pull/6310


Great work!
Dec 15 2016