www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ARM first & default LDC

reply 9il <ilyayaroshenko gmail.com> writes:
ARM is going to conquer laptop and PC markets in the next few 
years.

Making LDC a default compiler looks like a more rational 
solution. By default, I mean a branch where we do the main work 
on the compiler and DRuntime and what is used to make the first 
release of the new version of the compiler.

I just realized why we still have DMD as the default compiler and 
why probably we would have it in the near future.

D Foundation wants to have full power to make all key decisions. 
Making LDC a default compiler would also mean they would need to 
share their authority with others. That is only my opinion, I 
don't pretend it is right.

Kind regards,
Ilya
Dec 13 2020
next sibling parent Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution. By default, I mean a branch where we do the main work 
 on the compiler and DRuntime and what is used to make the first 
 release of the new version of the compiler.

 I just realized why we still have DMD as the default compiler 
 and why probably we would have it in the near future.

 D Foundation wants to have full power to make all key 
 decisions. Making LDC a default compiler would also mean they 
 would need to share their authority with others. That is only 
 my opinion, I don't pretend it is right.

 Kind regards,
 Ilya


+1
Dec 13 2020
prev sibling next sibling parent M.M. <matus email.cz> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution. By default, I mean a branch where we do the main work 
 on the compiler and DRuntime and what is used to make the first 
 release of the new version of the compiler.

 I just realized why we still have DMD as the default compiler 
 and why probably we would have it in the near future.

 D Foundation wants to have full power to make all key 
 decisions. Making LDC a default compiler would also mean they 
 would need to share their authority with others. That is only 
 my opinion, I don't pretend it is right.

 Kind regards,
 Ilya


There are several points you made in your comment. I freely 
paraphrase the content:
i) ARM will dominate the consumer laptop market in the short 
future
ii) make LDC the compiler where language development happens (and 
other compilers take it from there)
iii) allow a more decentralized work on the default D compiler 
(currently dmd)

I agree that these are interesting points to discuss; yet I also 
think that they do not necessarily depend on each other(?), and 
they are interesting discussion points on their own.

Ad i): this might indeed be true (as observed by the efforts of 
Microsoft several years ago with their operating system, and 
currently with the success of the apple M1 processor), yet there 
are also open-source efforts on the horizon (risc-v and power), 
but I agree this battle might be decided in the next 1-2 years.

Ad ii): isn't it that having dmd the development branch allows 
GDC and LDC to follow? Also, why would one prefer LDC over GDC? 
GDC is part of GCC, which is huge. I think here an opinion from 
the compiler maintainers/developers is needed, and I would be 
delighted to  hear their (even very short) opinion.

Ad iii): Isn't it true that contributions to dmd are welcome? Are 
there technical obstacles in contributing? Philosophical ones?
Dec 14 2020
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Mon, Dec 14, 2020 at 5:40 AM 9il via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 ARM is going to conquer laptop and PC markets in the next few
 years.


Yes, that is something I can agree with. But it will take 3-5 years.



 Making LDC a default compiler looks like a more rational
 solution. By default, I mean a branch where we do the main work
 on the compiler and DRuntime and what is used to make the first
 release of the new version of the compiler.


No, I do not see any benefit from this.



 I just realized why we still have DMD as the default compiler and
 why probably we would have it in the near future.

 D Foundation wants to have full power to make all key decisions.
 Making LDC a default compiler would also mean they would need to
 share their authority with others. That is only my opinion, I
 don't pretend it is right.


If D  Foundation would selected LDC as a default compiler I believe LDC
would need to accept D Foundation as their leadership
Dec 14 2020
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Mon, Dec 14, 2020 at 10:22 AM Daniel Kozak <kozzi11 gmail.com> wrote:


 On Mon, Dec 14, 2020 at 5:40 AM 9il via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:


 ARM is going to conquer laptop and PC markets in the next few
 years.


 Yes, that is something I can agree with. But it will take 3-5 years.


So from my POV DMD should add support for ARM64 in next few years and
everything will be ok
Dec 14 2020
prev sibling next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution. By default, I mean a branch where we do the main work 
 on the compiler and DRuntime and what is used to make the first 
 release of the new version of the compiler.

 I just realized why we still have DMD as the default compiler 
 and why probably we would have it in the near future.

 D Foundation wants to have full power to make all key 
 decisions. Making LDC a default compiler would also mean they 
 would need to share their authority with others. That is only 
 my opinion, I don't pretend it is right.

 Kind regards,
 Ilya


I think you're mixing up two things here.

DMD is Walter's baby and he's going to continue with that, having 
power over it is secondary to that.

D Foundation of course want to retain control over what they have 
built, it's years and years of their hard work, decades even. Why 
should they give control to someone else and why think that that 
other group would do any better? Arguably it would be 
irresponsible to do that.
Dec 14 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 14 December 2020 at 09:57:05 UTC, Abdulhaq wrote:

 I think you're mixing up two things here.

 DMD is Walter's baby and he's going to continue with that, 
 having power over it is secondary to that.

 D Foundation of course want to retain control over what they 
 have built, it's years and years of their hard work, decades 
 even. Why should they give control to someone else and why 
 think that that other group would do any better? Arguably it 
 would be irresponsible to do that.


There is one thing that worries me. GCC and LLVM contains 
primitives for optimizations and help for certain features. These 
primitives are often complicated and takes time to duplicate in 
the DMD backend. The result is that D will not use the helpful 
primitives in LLVM and therefore skip certain features that would 
otherwise be simpler to implement.

The DMD backend might be Walter's darling but what if he could 
move to LLVM, discover all the helpful primitives which perhaps 
increase the productivity and new ideas might emerge. It's a 
selling point.
Dec 14 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Monday, 14 December 2020 at 10:48:43 UTC, IGotD- wrote:

 On Monday, 14 December 2020 at 09:57:05 UTC, Abdulhaq wrote:

 [...]


 There is one thing that worries me. GCC and LLVM contains 
 primitives for optimizations and help for certain features. 
 These primitives are often complicated and takes time to 
 duplicate in the DMD backend. The result is that D will not use 
 the helpful primitives in LLVM and therefore skip certain 
 features that would otherwise be simpler to implement.

 The DMD backend might be Walter's darling but what if he could 
 move to LLVM, discover all the helpful primitives which perhaps 
 increase the productivity and new ideas might emerge. It's a 
 selling point.


What optimisation primitives?
Dec 14 2020
parent reply IGotD- <nise nise.com> writes:
On Monday, 14 December 2020 at 12:54:23 UTC, Max Haughton wrote:

 On Monday, 14 December 2020 at 10:48:43 UTC, IGotD- wrote:

 On Monday, 14 December 2020 at 09:57:05 UTC, Abdulhaq wrote:

 [...]


 There is one thing that worries me. GCC and LLVM contains 
 primitives for optimizations and help for certain features. 
 These primitives are often complicated and takes time to 
 duplicate in the DMD backend. The result is that D will not 
 use the helpful primitives in LLVM and therefore skip certain 
 features that would otherwise be simpler to implement.

 The DMD backend might be Walter's darling but what if he could 
 move to LLVM, discover all the helpful primitives which 
 perhaps increase the productivity and new ideas might emerge. 
 It's a selling point.


 What optimisation primitives?


One recent example are the LLVM primitives for coroutines posted 
in this thread. Look at the seminar video.
https://forum.dlang.org/thread/rr0jju$eub$1 digitalmars.com
Dec 14 2020
parent Guillaume Piolat <first.name guess.com> writes:
On Monday, 14 December 2020 at 13:23:47 UTC, IGotD- wrote:

 What optimisation primitives?


 One recent example are the LLVM primitives for coroutines 
 posted in this thread. Look at the seminar video.
 https://forum.dlang.org/thread/rr0jju$eub$1 digitalmars.com


Well. It's the job of the library to let people gloss over 
compiler differences.
It's not _that_ hard to support LDC, GDC, and DMD.

Also maybe LLVM is not the last backend of all times.
Dec 14 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 14 December 2020 at 10:48:43 UTC, IGotD- wrote:

 There is one thing that worries me. GCC and LLVM contains 
 primitives for optimizations and help for certain features. 
 These primitives are often complicated and takes time to 
 duplicate in the DMD backend. The result is that D will not use 
 the helpful primitives in LLVM and therefore skip certain 
 features that would otherwise be simpler to implement.


I think your feelings are misguided, a primitive does not mean it 
must be implemented in the compiler.  Take core.bitop.rol() and 
ror() as one example, these are implemented as a function in 
druntime for DMD and LDC, but are primitives to GDC (LROTATE_EXPR 
and RROTATE_EXPR respectively).  Same also applies to the entire 
core.checkedint module, or the core.varargs module, both of which 
are treated as primitives for GDC as well.


 The DMD backend might be Walter's darling but what if he could 
 move to LLVM, discover all the helpful primitives which perhaps 
 increase the productivity and new ideas might emerge. It's a 
 selling point.


Moving main development to LDC will be the death of D.
Dec 14 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Monday, 14 December 2020 at 17:45:01 UTC, Iain Buclaw wrote:

 On Monday, 14 December 2020 at 10:48:43 UTC, IGotD- wrote:

 There is one thing that worries me. GCC and LLVM contains 
 primitives for optimizations and help for certain features. 
 These primitives are often complicated and takes time to 
 duplicate in the DMD backend. The result is that D will not 
 use the helpful primitives in LLVM and therefore skip certain 
 features that would otherwise be simpler to implement.


 I think your feelings are misguided, a primitive does not mean 
 it must be implemented in the compiler.  Take core.bitop.rol() 
 and ror() as one example, these are implemented as a function 
 in druntime for DMD and LDC, but are primitives to GDC 
 (LROTATE_EXPR and RROTATE_EXPR respectively).  Same also 
 applies to the entire core.checkedint module, or the 
 core.varargs module, both of which are treated as primitives 
 for GDC as well.


 The DMD backend might be Walter's darling but what if he could 
 move to LLVM, discover all the helpful primitives which 
 perhaps increase the productivity and new ideas might emerge. 
 It's a selling point.


 Moving main development to LDC will be the death of D.


The last point in particular should shut this idea down. 
Discussion of D is still somewhat infested by people mentioning 
Phobos and Tango, D2/D1 etc, moving compilers would be a bit mad.

Besides, having 3 compilers is healthy (Isn't GCC on the cusp of 
getting an up to date frontend, too?) for the language and it's 
users.

Even if everyone who really understands the current dmd backend 
got hit by a bus, I think it would still be worth having a simple 
dmd backend rather than canning it.
Dec 14 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 14, 2020 at 08:53:19PM +0000, Max Haughton via Digitalmars-d wrote:
[...]

 Besides, having 3 compilers is healthy (Isn't GCC on the cusp of
 getting an up to date frontend, too?) for the language and it's users.


Walter has said this before: before we had 3 compilers, the naysayers
were saying, "what's wrong with D? how come it only has 1 compiler? Bus
factor, yadda yadda yadda".  Now that we have 3 compilers, and the
naysayers are saying "why is D so divided? Why are there 3 compilers
instead of one official compiler? Yadda yadda yadda"

This is one of those games where the only way to win is not to play.


T

-- 
A programming language should be a toolbox for the programmer to draw upon, not
a minefield of dangerous explosives that you have to very carefully avoid
touching in the wrong way.
Dec 14 2020
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Monday, 14 December 2020 at 21:22:25 UTC, H. S. Teoh wrote:

 On Mon, Dec 14, 2020 at 08:53:19PM +0000, Max Haughton via 
 Digitalmars-d wrote: [...]

 Besides, having 3 compilers is healthy (Isn't GCC on the cusp 
 of getting an up to date frontend, too?) for the language and 
 it's users.


 Walter has said this before: before we had 3 compilers, the 
 naysayers were saying, "what's wrong with D? how come it only 
 has 1 compiler? Bus factor, yadda yadda yadda".  Now that we 
 have 3 compilers, and the naysayers are saying "why is D so 
 divided? Why are there 3 compilers instead of one official 
 compiler? Yadda yadda yadda"


That's a strawman. The OP didn't say multiple compilers were bad. 
He said the "master" compiler should have ARM support for the 
language to survive, and moving to LDC would be the most rational 
way to achieve that.


 This is one of those games where the only way to win is not to 
 play.


 T
Dec 14 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 14, 2020 at 10:15:38PM +0000, Max Samukha via Digitalmars-d wrote:

 On Monday, 14 December 2020 at 21:22:25 UTC, H. S. Teoh wrote:

 On Mon, Dec 14, 2020 at 08:53:19PM +0000, Max Haughton via Digitalmars-d
 wrote: [...]

 Besides, having 3 compilers is healthy (Isn't GCC on the cusp of
 getting an up to date frontend, too?) for the language and it's
 users.


 
 Walter has said this before: before we had 3 compilers, the
 naysayers were saying, "what's wrong with D? how come it only has 1
 compiler? Bus factor, yadda yadda yadda".  Now that we have 3
 compilers, and the naysayers are saying "why is D so divided? Why
 are there 3 compilers instead of one official compiler? Yadda yadda
 yadda"


 
 That's a strawman. The OP didn't say multiple compilers were bad. He
 said the "master" compiler should have ARM support for the language to
 survive, and moving to LDC would be the most rational way to achieve
 that.


Why does there need to be a "master" compiler anyway?  The whole reason
for having multiple compilers is so that people can *choose* between
alternatives.  Want ARM support?  Pick LDC.  It's as simple as that.
All it takes is for the download page to have a table of target
architectures mapped to a list of compilers that support that
architecture.  That's all.


T

-- 
Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder
Dec 14 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2020 9:45 AM, Iain Buclaw wrote:

 I think your feelings are misguided, a primitive does not mean it must be 
 implemented in the compiler.  Take core.bitop.rol() and ror() as one example, 
 these are implemented as a function in druntime for DMD and LDC, but are 
 primitives to GDC (LROTATE_EXPR and RROTATE_EXPR respectively).


DMD recognizes the code pattern in rol() and ror() and replaces it with OProl 
and OPror intermediate code primitives.
Dec 16 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2020 1:57 AM, Abdulhaq wrote:

 DMD is Walter's baby and he's going to continue with that, having power over
it 
 is secondary to that.
 
 D Foundation of course want to retain control over what they have built, it's 
 years and years of their hard work, decades even. Why should they give control 
 to someone else and why think that that other group would do any better? 
 Arguably it would be irresponsible to do that.



Having DMD means we can support whatever target we want to, we are not 
constrained by a community we don't really have a voice in.

For example, DMD moved to support Win64 years before LLVM supported it.

I don't see how LDC and GDC are impaired in any way by DMD.
Dec 16 2020
next sibling parent reply claptrap <clap trap.com> writes:
On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
wrote:

 On 12/14/2020 1:57 AM, Abdulhaq wrote:

 DMD is Walter's baby and he's going to continue with that, 
 having power over it is secondary to that.
 
 D Foundation of course want to retain control over what they 
 have built, it's years and years of their hard work, decades 
 even. Why should they give control to someone else and why 
 think that that other group would do any better? Arguably it 
 would be irresponsible to do that.



 Having DMD means we can support whatever target we want to, we 
 are not constrained by a community we don't really have a voice 
 in.


That's a specious argument.

"Having DMD means we can add whatever optimisations we want to, 
we arnt constrained by a community we dont really have a voice 
in."

And yet why does DMD suck at optimising code? Because a freedom 
to do something that nobody has the resources to do is next to 
useless.

And lets be honest if LLVM doesnt support it, it's pretty small 
potatoes, who's going to go to that kind of effort to add some 
niche architecture to DMD?
Dec 17 2020
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
 wrote:

 On 12/14/2020 1:57 AM, Abdulhaq wrote:

 [...]



 Having DMD means we can support whatever target we want to, we 
 are not constrained by a community we don't really have a 
 voice in.


 That's a specious argument.

 "Having DMD means we can add whatever optimisations we want to, 
 we arnt constrained by a community we dont really have a voice 
 in."

 And yet why does DMD suck at optimising code? Because a freedom 
 to do something that nobody has the resources to do is next to 
 useless.

 And lets be honest if LLVM doesnt support it, it's pretty small 
 potatoes, who's going to go to that kind of effort to add some 
 niche architecture to DMD?


LLVM still doesn't support plenty of embedded targets that GCC 
does.

Small potatoes like million of 8 and 16 bit devices sold per year.
Dec 17 2020
next sibling parent 9il <ilyayaroshenko gmail.com> writes:
On Thursday, 17 December 2020 at 10:34:33 UTC, Paulo Pinto wrote:

 On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
 wrote:

 [...]


 That's a specious argument.

 "Having DMD means we can add whatever optimisations we want 
 to, we arnt constrained by a community we dont really have a 
 voice in."

 And yet why does DMD suck at optimising code? Because a 
 freedom to do something that nobody has the resources to do is 
 next to useless.

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 LLVM still doesn't support plenty of embedded targets that GCC 
 does.

 Small potatoes like million of 8 and 16 bit devices sold per 
 year.


The point is to have a master/default compiler that supports the 
main notebook/PC CPU architectures. LLVM and GCC are equal there.
Dec 17 2020
prev sibling parent claptrap <clap trap.com> writes:
On Thursday, 17 December 2020 at 10:34:33 UTC, Paulo Pinto wrote:

 On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
 wrote:

 On 12/14/2020 1:57 AM, Abdulhaq wrote:

 [...]



 Having DMD means we can support whatever target we want to, 
 we are not constrained by a community we don't really have a 
 voice in.


 That's a specious argument.

 "Having DMD means we can add whatever optimisations we want 
 to, we arnt constrained by a community we dont really have a 
 voice in."

 And yet why does DMD suck at optimising code? Because a 
 freedom to do something that nobody has the resources to do is 
 next to useless.

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 LLVM still doesn't support plenty of embedded targets that GCC 
 does.

 Small potatoes like million of 8 and 16 bit devices sold per 
 year.


There are probably more ARM chips sold than anything else, DMD 
doesnt support them, so the idea that it will support these 8 and 
16 bit micro controllers is ludicrous.

So in spite of what you say my point still stands. Arguing that 
DMD gives us a freedom to target whatever architecture we want is 
specious.

With enough effort I can fly to the moon, except that I cant.
Dec 17 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name guess.com> writes:
On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 And yet why does DMD suck at optimising code? Because a freedom 
 to do something that nobody has the resources to do is next to 
 useless.


DMD builds fast, and is small, it has some value and it would be 
more used if you could somehow rely on code generation. (for 
example, raylib ships with a tinycc compiler for speed of 
compile-run loop)

However I think an ARM backend may be just too much debt when we 
don't have a reliable x86 backend in DMD. And I don't know why 
it's the case, it has been a constant over years.

(for info: the particular issue that irks me is 
https://issues.dlang.org/show_bug.cgi?id=21474)

I'd be really wary to release something built with DMD and 
optimizations on.
This is not _only_ about speed imho.
Dec 17 2020
next sibling parent claptrap <clap trap.com> writes:
On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat 
wrote:

 On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 And yet why does DMD suck at optimising code? Because a 
 freedom to do something that nobody has the resources to do is 
 next to useless.


 DMD builds fast, and is small, it has some value and it would 
 be more used if you could somehow rely on code generation. (for 
 example, raylib ships with a tinycc compiler for speed of 
 compile-run loop)


Oh yeah I agree, it's clear a lot of people value DMDs fast 
compile times. I remember using Delphi years and years ago, and 
it was like 1 second compile, every time. It was so fast it took 
no more time to recompile and let it go to the first error, than 
it did to locate it yourself. There's definite value in that.



 However I think an ARM backend may be just too much debt when 
 we don't have a reliable x86 backend in DMD. And I don't know 
 why it's the case, it has been a constant over years.

 (for info: the particular issue that irks me is 
 https://issues.dlang.org/show_bug.cgi?id=21474)

 I'd be really wary to release something built with DMD and 
 optimizations on.
 This is not _only_ about speed imho.


Yeah, thats not good.
Dec 17 2020
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Dec 17, 2020 at 04:02:05PM +0000, Guillaume Piolat via Digitalmars-d
wrote:
[...]

 However I think an ARM backend may be just too much debt when we don't
 have a reliable x86 backend in DMD. And I don't know why it's the
 case, it has been a constant over years.
 
 (for info: the particular issue that irks me is
 https://issues.dlang.org/show_bug.cgi?id=21474)
 
 I'd be really wary to release something built with DMD and
 optimizations on.  This is not _only_ about speed imho.


See, it's bugs like these that eventually convinced me no longer to use
DMD for production builds.  For development or small projects where
speed is not important, DMD fine, I just don't use -O or -inline; DMD
compiles lightning fast compared to the other compilers, it's
lightweight and easy to install and run, it's even easy to build (I
build DMD from git master), and really boosts your code-compile-test
cycle.

For production builds of non-trivial projects, though, I can't depend on
it. Over the years I've run into codegen bugs, usually triggered by -O,
-inline, or both. Which unfortunately exacerbates the already well-known
suboptimal output.  Plus cross-compilation is not supported right now.
LDC gives me reliable codegen, very good optimizations, and built-in
cross-compilation.  Plus good CPU targeting, which in some applications
make a big difference (e.g., issuing POPCOUNT instructions on CPUs that
support it, can really boost certain algorithms).  And LDC has been
tracking DMD releases very closely since a year or two ago, so it's not
lacking in the new features department either.  Overall, LDC works much
better for me in the production department.  In this area DMD isn't even
on my radar anymore.


T

-- 
Не дорог подарок, дорога любовь.
Dec 17 2020
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat 
wrote:

 I'd be really wary to release something built with DMD and 
 optimizations on.


My view is the -O, -inline, and -release switches should all 
become no-ops in dmd. They're slow and dangerous. I already 
advise people to never use them* and they weaken dmd rather than 
strengthen it.

* There is one exception: building druntime. It actually makes a 
difference there and since it is fairly better controlled it 
actually can use them and since druntime it not fully compatible 
across compilers you can't really mix and match. But that's it.
Dec 17 2020
prev sibling next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 17 December 2020 at 16:02:05 UTC, Guillaume Piolat 
wrote:

 On Thursday, 17 December 2020 at 10:02:56 UTC, claptrap wrote:

 And yet why does DMD suck at optimising code? Because a 
 freedom to do something that nobody has the resources to do is 
 next to useless.


 DMD builds fast, and is small, it has some value and it would 
 be more used if you could somehow rely on code generation. (for 
 example, raylib ships with a tinycc compiler for speed of 
 compile-run loop)

 However I think an ARM backend may be just too much debt when 
 we don't have a reliable x86 backend in DMD. And I don't know 
 why it's the case, it has been a constant over years.

 (for info: the particular issue that irks me is 
 https://issues.dlang.org/show_bug.cgi?id=21474)

 I'd be really wary to release something built with DMD and 
 optimizations on.
 This is not _only_ about speed imho.


If we really wanted an ARM backend in DMD it would probably be 
simpler to just build one from scratch. The basic optimizations 
needed to get vaguely acceptable performance for a fast/test 
build aren't all that complicated, especially if you build SSA 
(massively simplfies quite a few optimizations). It's still a big 
job, but it would also probably be useful to speed up CTFE as 
well (having a clean and reusable IR -> JIT).

The current backend is fairly unwieldy, true, but it's also very 
old and could be a lot smaller now we have things like ranges (or 
even templates) - as with many things in the compiler it 
doesn't/can't use modern D for various reasons.

For an empirical guess of how big a backend would be - cranelift 
is a modern (not just SSA) backend aimed at build times rather 
than runtime efficiency, and it clocks in (cranelift/codegen) at 
roughly 90k lines (the whole project warts and all is 130k). The 
current dmd backend is 97k. We could be significantly more 
concise because we have better metaprogramming - i.e. LLVM has a 
huge amount of boilerplate and DSLs that could be done fairly 
easily either as metaprogamming or mixin DSLs.

Is it worth it? No idea, but it isn't a totally unrealistic 
proposition (More realistically would be a dub project being 
merged in, I have a few rubbish backend projects on various 
computers of mine but none are remotely worth publishing).
Dec 17 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/17/2020 8:02 AM, Guillaume Piolat wrote:

 (for info: the particular issue that irks me is 
 https://issues.dlang.org/show_bug.cgi?id=21474)
 
 I'd be really wary to release something built with DMD and optimizations on.
 This is not _only_ about speed imho.


That was reported 5 days ago, give me a chance!

There are hardly any outstanding optimization bugs in DMD.

That said, I'll take a look at this issue.

BTW, please tag code gen issues with the `backend` keyword, else I'm apt to
miss it.
Dec 17 2020
parent reply Guillaume Piolat <first.name guess.com> writes:
On Thursday, 17 December 2020 at 23:22:20 UTC, Walter Bright 
wrote:

 BTW, please tag code gen issues with the `backend` keyword, 
 else I'm apt to miss it.


Got 3 tagged, I expect a bit more issues when D_SIMD will be used 
:)
Dec 17 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/17/2020 3:35 PM, Guillaume Piolat wrote:

 On Thursday, 17 December 2020 at 23:22:20 UTC, Walter Bright wrote:

 BTW, please tag code gen issues with the `backend` keyword, else I'm apt to 
 miss it.


 
 Got 3 tagged, I expect a bit more issues when D_SIMD will be used :)


So I see!

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=backend%2C%20&keywords_type=allwords&list_id=234080&query_format=advanced
Dec 17 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/17/2020 2:02 AM, claptrap wrote:

 And lets be honest if LLVM doesnt support it, it's pretty small potatoes,
who's 
 going to go to that kind of effort to add some niche architecture to DMD?


Win64 was never small potatoes.

Besides, nothing is impairing using LDC.
Dec 17 2020
parent reply claptrap <clap trap.com> writes:
On Thursday, 17 December 2020 at 23:16:33 UTC, Walter Bright 
wrote:

 On 12/17/2020 2:02 AM, claptrap wrote:

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 Win64 was never small potatoes.


So some years ago DMD had a single target that LLVM did not, and 
how does it look today?
Dec 17 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 18 December 2020 at 00:13:41 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 23:16:33 UTC, Walter Bright 
 wrote:

 On 12/17/2020 2:02 AM, claptrap wrote:

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 Win64 was never small potatoes.


 So some years ago DMD had a single target that LLVM did not, 
 and how does it look today?


For an average D developer, DMD is just the way to go. And the 
development time is more iterative than release. So DMD speed is 
a must have for development.

Average Joe needs DMD.

Given enough time, DMD will get ARM support.
Dec 19 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 14:20:45 UTC, aberba wrote:

 Average Joe needs DMD.


Average Joes tend not to use smaller languages, they use the most 
used languages for which there are many online tutorials. D has 
to focus on those bases that are not covered by other languages.


 Given enough time, DMD will get ARM support.


I hope people don't waste resources on adding ARM support, a 
moving target that has to be maintained. That time would be 
better spent on writing a clean high level IR.
Dec 19 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Saturday, 19 December 2020 at 15:14:04 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 19 December 2020 at 14:20:45 UTC, aberba wrote:

 Average Joe needs DMD.


 Average Joes tend not to use smaller languages, they use the 
 most used languages for which there are many online tutorials. 
 D has to focus on those bases that are not covered by other 
 languages.


I'm an average Joe BTW. When was the last time you met an average 
Joe? 😀



 Given enough time, DMD will get ARM support.


 I hope people don't waste resources on adding ARM support, a 
 moving target that has to be maintained. That time would be 
 better spent on writing a clean high level IR.


Developing with LDC compile time is a huge pain and a big! time 
sink. So I rather have it be the default until I don't need it 
anymore. UX first.

There's nothing wrong with having three alternative compilers. 
Was that the whole point some time back. DMD for development 
(mostly), LDC/ GCC for release. Sounds perfect to me.
Dec 19 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 15:22:34 UTC, aberba wrote:

 I'm an average Joe BTW. When was the last time you met an 
 average Joe? 😀


Nah, you are too dedicated to be average ;-).


 There's nothing wrong with having three alternative compilers.


True, but sinking a lot of time into extending and maintaining an 
outdated backend does not make a lot of sense. It would make more 
sense to improve on the interface between frontend/backend. Other 
languages are moving forward, so this project should try to stay 
nimble...
Dec 19 2020
prev sibling parent reply claptrap <clap trap.com> writes:
On Saturday, 19 December 2020 at 14:20:45 UTC, aberba wrote:

 On Friday, 18 December 2020 at 00:13:41 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 23:16:33 UTC, Walter Bright 
 wrote:

 On 12/17/2020 2:02 AM, claptrap wrote:

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 Win64 was never small potatoes.


 So some years ago DMD had a single target that LLVM did not, 
 and how does it look today?


 For an average D developer, DMD is just the way to go. And the 
 development time is more iterative than release. So DMD speed 
 is a must have for development.

 Average Joe needs DMD.


Average Joe doesnt exist.

Dont get me wrong, I agree 100% that fast compile is a very 
desirable feature. What I disagree with is the idea that DMD 
gives people the freedom to add support for new architectures 
that they wouldn't otherwise have.

1. Arm support is probably the most desirable, and yet DMD doesnt 
have it, because it's a lot of work, and well I dont know 
personally but it sounds like doing anything with the DMD backend 
is a bit of a nightmare. IE. Freedom to do something is not the 
same as the thing actually being done.

2. People could just add it to LLVM if they want i think. Might 
even be easier to write a whole new backend from scratch, i dont 
know. IE. Not having DMD doesnt preclude the benefit that Walter 
claims DMD gives us.
Dec 19 2020
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Saturday, 19 December 2020 at 17:15:40 UTC, claptrap wrote:

 On Saturday, 19 December 2020 at 14:20:45 UTC, aberba wrote:

 On Friday, 18 December 2020 at 00:13:41 UTC, claptrap wrote:

 On Thursday, 17 December 2020 at 23:16:33 UTC, Walter Bright 
 wrote:

 On 12/17/2020 2:02 AM, claptrap wrote:

 And lets be honest if LLVM doesnt support it, it's pretty 
 small potatoes, who's going to go to that kind of effort to 
 add some niche architecture to DMD?


 Win64 was never small potatoes.


 So some years ago DMD had a single target that LLVM did not, 
 and how does it look today?


 For an average D developer, DMD is just the way to go. And the 
 development time is more iterative than release. So DMD speed 
 is a must have for development.

 Average Joe needs DMD.


 Average Joe doesnt exist.

 Dont get me wrong, I agree 100% that fast compile is a very 
 desirable feature. What I disagree with is the idea that DMD 
 gives people the freedom to add support for new architectures 
 that they wouldn't otherwise have.

 1. Arm support is probably the most desirable, and yet DMD 
 doesnt have it, because it's a lot of work, and well I dont 
 know personally but it sounds like doing anything with the DMD 
 backend is a bit of a nightmare. IE. Freedom to do something is 
 not the same as the thing actually being done.

 2. People could just add it to LLVM if they want i think. Might 
 even be easier to write a whole new backend from scratch, i 
 dont know. IE. Not having DMD doesnt preclude the benefit that 
 Walter claims DMD gives us.


Writing a new backend would probably be easier.

You definitely can add new architectures to DMD (they're not all 
that different these days), i.e. the instruction scheduler isn't 
particularly unreadable, but the dual benefit of having a generic 
code generator to use in D and a clean backend in DMD is pretty 
nice.

It's a huge job, though.
Dec 19 2020
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. Might even be 
 easier to write a whole new backend from scratch, i dont know. IE. Not 
 having DMD doesnt preclude the benefit that Walter claims DMD gives us.
 


Building LLVM from scratch takes multiple hours. Building DMD from 
scratch (including backend) takes _seconds_.

Why is it so hard to believe that this is a benefit that an actual 
compiler developer might care for? It's exactly the prevalence of this 
kind of common sense pragmatics that makes D so convenient to use 
despite all flaws. You lose that if you start adding dependencies on 
projects that lack it.

Anyway, I think the solution is not to change the default development 
compiler, it's to get rid of that concept by improving separation of 
frontend and backends in the frontend development workflow so that it 
becomes equally convenient to develop frontend patches against every 
backend. (Though it may be possible to make the case that this would 
happen more quickly if LLVM or GCC were made the default backend, as 
it's plausible that the developers of LDC and GDC are more aware of what 
needs to be done in that department.)
Dec 19 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. 
 Might even be easier to write a whole new backend from 
 scratch, i dont know. IE. Not having DMD doesnt preclude the 
 benefit that Walter claims DMD gives us.
 


 Building LLVM from scratch takes multiple hours. Building DMD 
 from scratch (including backend) takes _seconds_.


Why would you?

Wasting effort on ARM when Apple is doing a best of breed for 
free for LLVM is just silly. It is going to be a moving target, 
M1 is just the first iteration. Save the resources for something 
that matters...
Dec 19 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Saturday, 19 December 2020 at 18:23:19 UTC, Ola Fosheim 
Grostad wrote:

 On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. 
 Might even be easier to write a whole new backend from 
 scratch, i dont know. IE. Not having DMD doesnt preclude the 
 benefit that Walter claims DMD gives us.
 


 Building LLVM from scratch takes multiple hours. Building DMD 
 from scratch (including backend) takes _seconds_.


 Why would you?

 Wasting effort on ARM when Apple is doing a best of breed for 
 free for LLVM is just silly. It is going to be a moving target, 
 M1 is just the first iteration. Save the resources for 
 something that matters...


You realise that that 80% (450k overall, backend is 90k) of the 
code in has nothing to do with the code generation.

Apple are also pretty reticent to upstream stuff to LLVM but that 
doesn't really matter because the dmd backend isn't and shouldn't 
be complicated enough to need that information.
Dec 19 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 19:34:32 UTC, Max Haughton wrote:

 You realise that that 80% (450k overall, backend is 90k) of the 
 code in has nothing to do with the code generation.


You realise that creating a high quality backend that is 100% bug 
free takes a lot of effort and that you have to maintain it in 
perpetuity? It isn't sufficient that someone "just does it", it 
also has to be correct, efficient and updated.


 Apple are also pretty reticent to upstream stuff to LLVM but 
 that doesn't really matter because the dmd backend isn't and 
 shouldn't be complicated enough to need that information.


It isn't even obvious that Apple will release the full ISA for 
their future ARM CPUs.
Dec 19 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 19 December 2020 at 19:34:32 UTC, Max Haughton 
 wrote:

 You realise that that 80% (450k overall, backend is 90k) of 
 the code in has nothing to do with the code generation.


 You realise that creating a high quality backend that is 100% 
 bug free takes a lot of effort and that you have to maintain it 
 in perpetuity? It isn't sufficient that someone "just does it", 
 it also has to be correct, efficient and updated.


 Apple are also pretty reticent to upstream stuff to LLVM but 
 that doesn't really matter because the dmd backend isn't and 
 shouldn't be complicated enough to need that information.


 It isn't even obvious that Apple will release the full ISA for 
 their future ARM CPUs.


DMD is good enough, this discussion is pointless.

The ISA isn't the problem, Apple will probably stick with arm but 
knowing the parameters to tweak the instruction scheduling is the 
kind of thing they're being coy with that matter.
Dec 19 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 19:44:29 UTC, Max Haughton wrote:

 DMD is good enough, this discussion is pointless.


I think the point was lost, then. Implementing it is less than 
10% of the total work. You also need to write exhaustive tests, 
maintain it and update it. So whoever implements ARM support has 
to stick around. It is worse to add support for something that 
falls into decay than not having it in the first place.
Dec 19 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim 
Grøstad wrote:

 You realise that creating a high quality backend that is 100% 
 bug free takes a lot of effort and that you have to maintain it 
 in perpetuity? It isn't sufficient that someone "just does it", 
 it also has to be correct, efficient and updated.


This post made me think.

https://forum.dlang.org/post/umfqzznlrongfrvictus forum.dlang.org

Read point number 3.


Basically, there are problems with DMD, sometimes crashes and has 
codegen bugs. Codegen bugs is definitely not something you want 
in a big project because they are time consuming.

Thank you for posting real commercial experience with D. If I was 
a hard headed boss of the D project I would probably demand that 
the DMD backend would be scrapped and efforts should focus on 
stability with the support of GCC and LLVM backends.
Dec 19 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:

 Basically, there are problems with DMD, sometimes crashes and 
 has codegen bugs. Codegen bugs is definitely not something you 
 want in a big project because they are time consuming.


Yes, but it is ok for developing a reference compiler, but there 
is no need for ARM support to do that either. One can run x86 
code on ARM CPUs using an emulator for testing. It is a matter of 
setting up a more generic testing environment.

In fact, as was mentioned earlier one could do idealized code gen 
for a virtual machine if front end deveopment was the main issue. 
Might be a good idea actually, regarding CTFE.
Dec 19 2020
prev sibling next sibling parent Calvin P <cloudlessapp gmail.com> writes:
On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:

 Basically, there are problems with DMD, sometimes crashes and 
 has codegen bugs. Codegen bugs is definitely not something you 
 want in a big project because they are time consuming.

 Thank you for posting real commercial experience with D. If I 
 was a hard headed boss of the D project I would probably demand 
 that the DMD backend would be scrapped and efforts should focus 
 on stability with the support of GCC and LLVM backends.


+1

LDC build process is fast with LLVM installed, and you need LLVM 
or GCC anyway if you are work on non-toy projects.


I do my developer process with LDC -O0 -g -fsanitize=address 
-fsanitize=thread, use Makefile without DUB/druntime/phobos.  
LLVM sanitizer made my work down quick and solid, and have multi 
platform cross build is just awesome.

I use to like DMD fast build experience, the price is get some 
hard to resolve mysterious bugs.  Then I refactor my work without 
use DUB/druntime/Phobos, I still get keep the lightning build 
speed and have multi platform ability with great code generate 
quality.

In my opinion, Walter is artist and have power to performance the 
magic.  Average Joe play DMD just like boy play toys.   There is 
nothing wrong with that, just not suit for average Joe like me 
made living from the jungle.
Dec 19 2020
prev sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:

 On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim 
 Grøstad wrote:

 You realise that creating a high quality backend that is 100% 
 bug free takes a lot of effort and that you have to maintain 
 it in perpetuity? It isn't sufficient that someone "just does 
 it", it also has to be correct, efficient and updated.


 This post made me think.

 https://forum.dlang.org/post/umfqzznlrongfrvictus forum.dlang.org

 Read point number 3.


 Basically, there are problems with DMD, sometimes crashes and 
 has codegen bugs. Codegen bugs is definitely not something you 
 want in a big project because they are time consuming.

 Thank you for posting real commercial experience with D. If I 
 was a hard headed boss of the D project I would probably demand 
 that the DMD backend would be scrapped and efforts should focus 
 on stability with the support of GCC and LLVM backends.


Ilya has been working on a certain very important subset of work 
on behalf of Symmetry.  That mostly had to be  nogc because it 
needs to be usable as an Excel plugin as well as from our DSL.  
And we decided to do something that conventionally speaking you 
should never do - porting a critical library written in a hurry 
in C++ and still evolving to an emerging programming language 
(D).  C++ mangling and ABI interoperability isn't perfect now but 
is a lot better than the situation when we started. We did finish 
it, by the way, and achieved our technical and commercial goals.

I think we only build that codebase using LDC now but more 
generally we use LDC for release builds and dmd for development 
and it is not perfect, but it is overall fine. We build with dmd 
nightly as well to stay ahead of breakages coming down the line.

I love the existence of gdc and the incredible range of targets 
it supports.  I am also in awe at what Iain has been able to 
accomplish.  We don't use gdc currently only because for 
pragmatic reasons we need to have a more current front end - 
although gdc is much more up to date these days.

I wonder what amount of funding would be needed for a first 
version of an ARM back end for DMD.

More generally I don't think D is growing too slowly.  If 
anything if you zoom out the time horizon, I think many of the 
causes of frustration amongst some users in fact reflects the 
fact that it can take time for organisation to catch up with 
growth. It takes time, energy and committed and talented people 
to build organisation and these things take the time they take, 
particularly with an open source endeavour.
Dec 29 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:

 I wonder what amount of funding would be needed for a first 
 version of an ARM back end for DMD.


I don't know, but my main worry is that it would be end up 80% 
dependent on Walter and delay more important stuff. Which is a 
cost that cannot be measured in terms of payment.

It really depends on 1. experience/knowledge/skills 2. backend 
familiarity 3. confidence level (release quality or test build 
quality?).

Rough guesstimate 1-2 months for something useable (for adapting 
an existing well designed backend), but that is like < 10% of the 
total work. Clearly not competitive quality, but enough to 
develop the compiler?

Maybe if someone funded an advisor so that it could be turned 
into a MSc master project to build a new non-optimizing backend 
from scratch? Sounds like a fun project and could bring new 
talent into the pool.



 More generally I don't think D is growing too slowly.


Yes, it is more difficult to manage if it grows fast (more 
demands, more fires to extinguish). The challenge is really to 
diversify the load and make sure that new features aren't started 
on before the existing feature set is solidified. If 1-2 key 
developers are overloaded (even if it is just mentoring) then 
that would be bad.

Cheers! ;-)
Dec 29 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Some of the criticisms of DMD were fair, and I've been doing some work on them. 
The buglist for problems with SIMD is now down to 3 items:

https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=dmd&keywords=simd&keywords_type=allwords&list_id=234194&query_format=advanced
Dec 29 2020
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:

 On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:

 [...]


 Ilya has been working on a certain very important subset of 
 work on behalf of Symmetry.  That mostly had to be  nogc 
 because it needs to be usable as an Excel plugin as well as 
 from our DSL.  And we decided to do something that 
 conventionally speaking you should never do - porting a 
 critical library written in a hurry in C++ and still evolving 
 to an emerging programming language (D).  C++ mangling and ABI 
 interoperability isn't perfect now but is a lot better than the 
 situation when we started. We did finish it, by the way, and 
 achieved our technical and commercial goals.

 [...]


Excel plugins don't have any issues with GC, as per my experience 
writing them via the .NET and COM APIs.

Why was this a must have, if you can share?
Dec 29 2020
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:

 I wonder what amount of funding would be needed for a first 
 version of an ARM back end for DMD.


I guess you'd first need to define what is ARM for DMD?  Is it 
ARM or Apple?  Treating both as a distinction would be really 
important, as the former has more multilib and ABI combinations 
than there are moons in the solar system.


 More generally I don't think D is growing too slowly.  If 
 anything if you zoom out the time horizon, I think many of the 
 causes of frustration amongst some users in fact reflects the 
 fact that it can take time for organisation to catch up with 
 growth. It takes time, energy and committed and talented people 
 to build organisation and these things take the time they take, 
 particularly with an open source endeavour.


I think it would be a fair observation to say that as of recent D 
has probably been both at the same time - moving fast at a 
glacial pace.  There are some big things on the horizon for sure 
that have been brewing for some time now, though not necessarily 
have been at the fore on people's radar.
Dec 30 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 13:30:58 UTC, Iain Buclaw wrote:

 On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc 
 wrote:

 I wonder what amount of funding would be needed for a first 
 version of an ARM back end for DMD.


 I guess you'd first need to define what is ARM for DMD?  Is it 
 ARM or Apple?  Treating both as a distinction would be really 
 important, as the former has more multilib and ABI combinations 
 than there are moons in the solar system.


The thread is focusing on Apple ARM though.
Dec 30 2020
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Wednesday, 30 December 2020 at 13:30:58 UTC, Iain Buclaw wrote:

 I guess you'd first need to define what is ARM for DMD?  Is it 
 ARM or Apple?  Treating both as a distinction would be really 
 important, as the former has more multilib and ABI combinations 
 than there are moons in the solar system.


The key thing is surely to be able to build and run code with DMD 
on the major types of machine that developers are likely to be 
using.  So while broader ARM support is nice, it's support for 
the Apple M1 that should be the priority.  More specialized needs 
are already supplied by GDC and LDC.
Jan 01 2021
prev sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:

 On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:

 On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim 
 Grøstad wrote:

 You realise that creating a high quality backend that is 100% 
 bug free takes a lot of effort and that you have to maintain 
 it in perpetuity? It isn't sufficient that someone "just does 
 it", it also has to be correct, efficient and updated.


 This post made me think.

 https://forum.dlang.org/post/umfqzznlrongfrvictus forum.dlang.org

 Read point number 3.


 Basically, there are problems with DMD, sometimes crashes and 
 has codegen bugs. Codegen bugs is definitely not something you 
 want in a big project because they are time consuming.

 Thank you for posting real commercial experience with D. If I 
 was a hard headed boss of the D project I would probably 
 demand that the DMD backend would be scrapped and efforts 
 should focus on stability with the support of GCC and LLVM 
 backends.


 Ilya has been working on a certain very important subset of 
 work on behalf of Symmetry.  That mostly had to be  nogc 
 because it needs to be usable as an Excel plugin as well as 
 from our DSL.  And we decided to do something that 
 conventionally speaking you should never do - porting a 
 critical library written in a hurry in C++ and still evolving 
 to an emerging programming language (D).  C++ mangling and ABI 
 interoperability isn't perfect now but is a lot better than the 
 situation when we started. We did finish it, by the way, and 
 achieved our technical and commercial goals.

 I think we only build that codebase using LDC now but more 
 generally we use LDC for release builds and dmd for development 
 and it is not perfect, but it is overall fine. We build with 
 dmd nightly as well to stay ahead of breakages coming down the 
 line.

 I love the existence of gdc and the incredible range of targets 
 it supports.  I am also in awe at what Iain has been able to 
 accomplish.  We don't use gdc currently only because for 
 pragmatic reasons we need to have a more current front end - 
 although gdc is much more up to date these days.

 I wonder what amount of funding would be needed for a first 
 version of an ARM back end for DMD.

 More generally I don't think D is growing too slowly.  If 
 anything if you zoom out the time horizon, I think many of the 
 causes of frustration amongst some users in fact reflects the 
 fact that it can take time for organisation to catch up with 
 growth. It takes time, energy and committed and talented people 
 to build organisation and these things take the time they take, 
 particularly with an open source endeavour.


Re: cost of DMD backend for ARM, the existing backend is loaded 
with implementation details from the pentium 5 and 6 (pro), and 
is generally not very nice to read or write - it would probably 
be easier to do a basic retargetable code generator from scratch 
but keep the existing backend for x86 in the meantime.

For a material estimate of size, the cranelift backend rust has 
is about 87k lines (inc. tests IIRC) so somewhere on that order 
(and we can generate huge amounts of code for free because D) - I 
think the our backend is a bit bigger than that.

Cranelift already has basic ARM support too; I can't comment on 
the quality of code generated.

This could also kill a few birds with one stone as it's an 
effective route to a modern JIT which hypothetically (I believe 
Stefan's work showed it's not as simple as that, but still) could 
help with CTFE.
Dec 30 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 15:00:15 UTC, Max Haughton 
wrote:

 Cranelift already has basic ARM support too; I can't comment on 
 the quality of code generated.


Are you thinking porting?
Dec 30 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 30 December 2020 at 15:56:49 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 15:00:15 UTC, Max Haughton 
 wrote:

 Cranelift already has basic ARM support too; I can't comment 
 on the quality of code generated.


 Are you thinking porting?


No, just guessing how much work it would be. I would quite like 
to get a basic backend going but it's much easier said than done 
(i.e. most optimisations are fairly simple but generating proper 
code and debug info at the end takes ages to test let alone write)
Dec 30 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 16:03:56 UTC, Max Haughton 
wrote:

 No, just guessing how much work it would be. I would quite like 
 to get a basic backend going but it's much easier said than 
 done (i.e. most optimisations are fairly simple but generating 
 proper code and debug info at the end takes ages to test let 
 alone write)


*nods*

I actually like the idea of a fast non-optimizing backend.

What could be fun is a space-optimizing compiler for WASM and 
embedded: save as much space as possible.
Dec 30 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 30 December 2020 at 16:13:14 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 16:03:56 UTC, Max Haughton 
 wrote:

 No, just guessing how much work it would be. I would quite 
 like to get a basic backend going but it's much easier said 
 than done (i.e. most optimisations are fairly simple but 
 generating proper code and debug info at the end takes ages to 
 test let alone write)


 *nods*

 I actually like the idea of a fast non-optimizing backend.

 What could be fun is a space-optimizing compiler for WASM and 
 embedded: save as much space as possible.


Space optimizing still requires quite a lot of time eliminating 
work, although LLVM is still pretty bad at it specifically - if 
you give a recursive factorial implementation to LLVM, it can't 
see the overflow's going to happen to so  it will (at O3) give 
you about 100 SIMD instructions rather than a simple loop.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 16:18:34 UTC, Max Haughton 
wrote:

 Space optimizing still requires quite a lot of time eliminating 
 work, although LLVM is still pretty bad at it specifically - if 
 you give a recursive factorial implementation to LLVM, it can't 
 see the overflow's going to happen to so  it will (at O3) give 
 you about 100 SIMD instructions rather than a simple loop.


:-D I wasn't aware of that.

Yes, but I guess one could start with a non-optimizing SSA based 
backend with the intent of improving it later, but a focus on 
space optimization. At least it could be competitive in a niche 
rather than a lesser version of llvm...
Dec 30 2020
next sibling parent reply claptrap <clap trap.com> writes:
On Wednesday, 30 December 2020 at 16:22:27 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 16:18:34 UTC, Max Haughton 
 wrote:

 Space optimizing still requires quite a lot of time 
 eliminating work, although LLVM is still pretty bad at it 
 specifically - if you give a recursive factorial 
 implementation to LLVM, it can't see the overflow's going to 
 happen to so  it will (at O3) give you about 100 SIMD 
 instructions rather than a simple loop.


 :-D I wasn't aware of that.

 Yes, but I guess one could start with a non-optimizing SSA 
 based backend with the intent of improving it later, but a 
 focus on space optimization. At least it could be competitive 
 in a niche rather than a lesser version of llvm...


Is it plausible to make a new backend that takes LLVM IR, so it 
uses the same glue layer as LDC? Or would that inhibit fast 
compilation?
Dec 30 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 16:25:08 UTC, claptrap wrote:

 Is it plausible to make a new backend that takes LLVM IR, so it 
 uses the same glue layer as LDC? Or would that inhibit fast 
 compilation?


I think LDC uses some LLVM provided utility code for building the 
initial SSA, but you probably could do that.

I don't think the glue layer is the most work though, so you 
would probably be better off creating a simpler SSA than LLVM?

I haven't given this much thought, though.
Dec 30 2020
prev sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 30 December 2020 at 16:22:27 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 16:18:34 UTC, Max Haughton 
 wrote:

 Space optimizing still requires quite a lot of time 
 eliminating work, although LLVM is still pretty bad at it 
 specifically - if you give a recursive factorial 
 implementation to LLVM, it can't see the overflow's going to 
 happen to so  it will (at O3) give you about 100 SIMD 
 instructions rather than a simple loop.


 :-D I wasn't aware of that.

 Yes, but I guess one could start with a non-optimizing SSA 
 based backend with the intent of improving it later, but a 
 focus on space optimization. At least it could be competitive 
 in a niche rather than a lesser version of llvm...


SSA basically gets you a lot of optimisations for "free" 
(amortized) if you maintain the property but other than that a 
simple backend is hugely faster than LLVM as evidenced by 
languages moving away from LLVM for debug builds.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 17:49:43 UTC, Max Haughton 
wrote:

 SSA basically gets you a lot of optimisations for "free" 
 (amortized) if you maintain the property but other than that a 
 simple backend is hugely faster than LLVM as evidenced by 
 languages moving away from LLVM for debug builds.


Maybe it is possible to design a SSA that is very close to WASM? 
I think that tight code gen for WASM can be competitive as there 
is a desire to keep downloads small on the web.
Dec 30 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 30 December 2020 at 18:04:25 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 17:49:43 UTC, Max Haughton 
 wrote:

 SSA basically gets you a lot of optimisations for "free" 
 (amortized) if you maintain the property but other than that a 
 simple backend is hugely faster than LLVM as evidenced by 
 languages moving away from LLVM for debug builds.


 Maybe it is possible to design a SSA that is very close to 
 WASM? I think that tight code gen for WASM can be competitive 
 as there is a desire to keep downloads small on the web.


WASM is a stack machine IIRC whereas most compiler optimisations 
are traditionally stated as register machines so it would be more 
productive to have WASM as a traditional backend.

I think any algorithms that rely on DAGs are also more efficient 
with register IRs, so again it would be easy to have a 
traditional SSA IR (probably with Block arguments instead of phi 
because it's 2020) and convert to a stack machine afterwards.
Dec 30 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 18:25:41 UTC, Max Haughton 
wrote:

 WASM is a stack machine IIRC whereas most compiler 
 optimisations are traditionally stated as register machines so 
 it would be more productive to have WASM as a traditional 
 backend.


I was more thinking having the same SSA instructions/limitations. 
If one can do fast SSA->WASM then one might be able to use 
whatever WASM execution engine Chrome uses for JIT? Just a 
thought...


 I think any algorithms that rely on DAGs are also more 
 efficient with register IRs, so again it would be easy to have 
 a traditional SSA IR (probably with Block arguments instead of 
 phi because it's 2020) and convert to a stack machine 
 afterwards.


Oh, yes, for sure use a simple register IR.
Dec 30 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 30 December 2020 at 18:35:03 UTC, Ola Fosheim 
Grøstad wrote:

 On Wednesday, 30 December 2020 at 18:25:41 UTC, Max Haughton 
 wrote:

 WASM is a stack machine IIRC whereas most compiler 
 optimisations are traditionally stated as register machines so 
 it would be more productive to have WASM as a traditional 
 backend.


 I was more thinking having the same SSA 
 instructions/limitations. If one can do fast SSA->WASM then one 
 might be able to use whatever WASM execution engine Chrome uses 
 for JIT? Just a thought...


https://v8.dev/blog/liftoff

Seems to ignore code quality for fast code-gen. Maybe some ideas 
in there.
Dec 30 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 30 December 2020 at 16:03:56 UTC, Max Haughton 
wrote:

 On Wednesday, 30 December 2020 at 15:56:49 UTC, Ola Fosheim 
 Grøstad wrote:

 On Wednesday, 30 December 2020 at 15:00:15 UTC, Max Haughton 
 wrote:

 Cranelift already has basic ARM support too; I can't comment 
 on the quality of code generated.


 Are you thinking porting?


 No, just guessing how much work it would be. I would quite like 
 to get a basic backend going but it's much easier said than 
 done (i.e. most optimisations are fairly simple but generating 
 proper code and debug info at the end takes ages to test let 
 alone write)


The dmd back-end is surprisingly more segregated than you think, 
there are a bunch of entrypoint methods you can override (class 
Obj if I remember correctly), and from there, modules can act as 
their own encapsulation for emitting code for different CPUs - 
just swap the x87 modules for ARM modules in a hypothetical build.

Someone already did 70% of the work in untangling the back-end 
and made a toy ARMv4 backend several years ago.  Though it may 
not be in a salvageable state now, especially if the ultimate aim 
is to generate code for the Apple M1.
Dec 30 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 30 December 2020 at 16:53:41 UTC, Iain Buclaw wrote:

 On Wednesday, 30 December 2020 at 16:03:56 UTC, Max Haughton 
 wrote:

 On Wednesday, 30 December 2020 at 15:56:49 UTC, Ola Fosheim 
 Grøstad wrote:

 On Wednesday, 30 December 2020 at 15:00:15 UTC, Max Haughton 
 wrote:

 Cranelift already has basic ARM support too; I can't comment 
 on the quality of code generated.


 Are you thinking porting?


 No, just guessing how much work it would be. I would quite 
 like to get a basic backend going but it's much easier said 
 than done (i.e. most optimisations are fairly simple but 
 generating proper code and debug info at the end takes ages to 
 test let alone write)


 The dmd back-end is surprisingly more segregated than you 
 think, there are a bunch of entrypoint methods you can override 
 (class Obj if I remember correctly), and from there, modules 
 can act as their own encapsulation for emitting code for 
 different CPUs - just swap the x87 modules for ARM modules in a 
 hypothetical build.

 Someone already did 70% of the work in untangling the back-end 
 and made a toy ARMv4 backend several years ago.  Though it may 
 not be in a salvageable state now, especially if the ultimate 
 aim is to generate code for the Apple M1.


I was more thinking of how (say) cgsched.d seems to basically 
assume either a basic OoO or a pentium 5 UV pipeline. I don't 
know empirically how sensitive a modern core is to instruction 
scheduling given that a full Tomasulo-core actually makes it 
relatively hard to force some kind of data hazards - as opposed 
to an in-order pipeline.

Making that work with a generic machine is probably harder than 
making a simple one from scratch (I'm not sure if cranelift 
actually has a proper instruction scheduler)

If the actual object code and debug output could be reused reused 
it would save a huge amount of work.

It would also be interesting to try and have a hard 
cpu-instructions per IR-insn upper bound for debug builds.
Dec 30 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2020 9:47 AM, Max Haughton wrote:

 I was more thinking of how (say) cgsched.d seems to basically assume either a 
 basic OoO or a pentium 5 UV pipeline.


Not only does it seem to, it specifically was designed for the Pentium and
later 
the P6 architectures. However, scheduling is not so important for modern CPUs. 
The scheduler can also be simply turned off, it is totally optional.
Dec 30 2020
parent Max Haughton <maxhaton gmail.com> writes:
On Thursday, 31 December 2020 at 01:14:51 UTC, Walter Bright 
wrote:

 On 12/30/2020 9:47 AM, Max Haughton wrote:

 I was more thinking of how (say) cgsched.d seems to basically 
 assume either a basic OoO or a pentium 5 UV pipeline.


 Not only does it seem to, it specifically was designed for the 
 Pentium and later the P6 architectures. However, scheduling is 
 not so important for modern CPUs. The scheduler can also be 
 simply turned off, it is totally optional.


Question answered then - it came it to mind because I was having 
a read while having a reading a microarchitecture textbook. 
(Apologies in advanced if it makes anyone feel old) I was curious 
as to what the industry (vs. textbook) approach was like at the 
time (I guess I would've been -5 years old when P6 hit the 
shelves).
Dec 30 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2020 7:00 AM, Max Haughton wrote:

 Re: cost of DMD backend for ARM, the existing backend is loaded with 
 implementation details from the pentium 5 and 6 (pro), and is generally not
very 
 nice to read or write


The overall design of it is pretty simple. The complexity comes from the 
complexity of the instruction set. There's no way to wish that complexity away. 
You'll even see it in the inline assembler. I'm actually rather surprised that 
the initial design of it has proven effective for nearly 40 years despite vast 
changes in the Intel architecture.

The CPU architecture that didn't fit in too well with the code generator design 
was the wacky x87 FPU, which used a primitive stack architecture. I never did a 
good job with that, but the point is moot these days as the x87 is effectively
dead.



 - it would probably be easier to do a basic retargetable 
 code generator from scratch


Everyone thinks that. But not a chance. The last 1% will take 500% of the time, 
and you'll be chasing bugs for years that the old one already solved.



 but keep the existing backend for x86 in the meantime.
 
 For a material estimate of size, the cranelift backend rust has is about 87k 
 lines (inc. tests IIRC) so somewhere on that order (and we can generate huge 
 amounts of code for free because D) - I think the our backend is a bit bigger 
 than that.


The backend of DMD is 121,000 lines, but that includes the optimizer, symbolic 
debug info, exception handling table generation, a lot for various object file 
formats, etc., all of which is pretty generically written. The actual code gen 
is around 39,000 lines.
Dec 30 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Thursday, 31 December 2020 at 01:11:10 UTC, Walter Bright 
wrote:

 - it would probably be easier to do a basic retargetable code 
 generator from scratch


 Everyone thinks that. But not a chance. The last 1% will take 
 500% of the time, and you'll be chasing bugs for years that the 
 old one already solved.



That was specifically referring to properly adding ARM support 
rather than replacing the backend for the sake of it. I'm not in 
any way under the impression that either would be easy.
Dec 30 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/30/2020 6:20 PM, Max Haughton wrote:

 On Thursday, 31 December 2020 at 01:11:10 UTC, Walter Bright wrote:

 - it would probably be easier to do a basic retargetable code generator from 
 scratch


 Everyone thinks that. But not a chance. The last 1% will take 500% of the 
 time, and you'll be chasing bugs for years that the old one already solved.


 
 
 That was specifically referring to properly adding ARM support rather than 
 replacing the backend for the sake of it. I'm not in any way under the 
 impression that either would be easy.


Sorry I misunderstood you.

The difficulty is apparent in that most compiler writers write a front end and 
use someone else's back end, write a simple interpreter, or generate C code.

Me, I've always enjoyed the challenge of a back end.
Dec 30 2020
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 Why is it so hard to believe that this is a benefit that an 
 actual compiler developer might care for?


Yes, this is important.

I have done patches to dmd myself. It is very quick and 
accessible.

I've never even tried to compile the others myself before, it is 
just intimidating. But out of curiosity, I tried to compile ldc 
just now.

git clone
git submodule init
cmake

OK, it took a full minute to get to this point, but that's OK, it 
is just setup.

make

... over a minute later:

/home/me/d/dev/ldc/gen/passes/GarbageCollect2Stack.cpp: In 
function ‘void RemoveCall(LLCallBasePtr, const 
{anonymous}::Analysis&)’:
/home/me/d/dev/ldc/gen/passes/GarbageCollect2Stack.cpp:446:35: 
error: conversion from ‘LLCallBasePtr’ {aka ‘llvm::CallBase*’} to 
‘llvm::CallSite’ is ambiguous
   446 |     A.CGNode->removeCallEdgeFor(CB);


yada yada yada.


I have no idea what any of this means, maybe the llvm version on 
my box (8.0.1) is too old, but with dmd, it USED to be that 
things would just work. It isn't *that* nice anymore, but it 
still isn't too hard. Way faster and much less scary = more 
likely to get new dev work done.
Dec 19 2020
parent 0xEAB <desisma heidel.beer> writes:
On Saturday, 19 December 2020 at 19:24:34 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 Why is it so hard to believe that this is a benefit that an 
 actual compiler developer might care for?


 Yes, this is important.

 I have done patches to dmd myself. It is very quick and 
 accessible.

 [...]

 still isn't too hard. Way faster and much less scary = more 
 likely to get new dev work done.


+1

Wouldn't (couldn't) have contributed to DMD if it wasn't as 
simple as it is.
It's super cool when your modified compiler is just a few seconds 
of compilation way.


In comparison to that, testing some changes to the DUB registry 
requires me to setup some MongoDB server in advance. And 
configure it accordingly. And maybe patch some code to not bug me 
with it's auth process or whatsoever…
Without some (time consuming) help by WebFreak dub-registry PR 


For DMD you just run the build script. No need to prepare some 
LLVM or whatever dependency (maybe even in some specific expected 
versions) in advance.

- Elias
Dec 19 2020
prev sibling next sibling parent reply Jeeferson <jeeferson.johnson gmail.com> writes:
On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. 
 Might even be easier to write a whole new backend from 
 scratch, i dont know. IE. Not having DMD doesnt preclude the 
 benefit that Walter claims DMD gives us.
 


 Building LLVM from scratch takes multiple hours. Building DMD 
 from scratch (including backend) takes _seconds_.


Anyone that says LLVM takes multiple hours obviously hasn't built 
it, or are using a 20 year old computer to build it.

Once you build LLVM you don't build it again. Unless you are 
modifying LLVM itself, which LDC only has one or two commits that 
make changes, for Android for local thread storage. So if you are 
developing a compiler it would still only take seconds.


 Why is it so hard to believe that this is a benefit that an 
 actual compiler developer might care for? It's exactly the 
 prevalence of this kind of common sense pragmatics that makes D 
 so convenient to use despite all flaws. You lose that if you 
 start adding dependencies on projects that lack it.


The user base that compiles DMD is infinitely smaller than the 
amount that use it. The only opinion I've heard from the D dev 
team is that they hate the backend and see the DMD backend as 
obsolete. So not sure who you are really referring to here, in 
reality.


 Anyway, I think the solution is not to change the default 
 development compiler, it's to get rid of that concept by 
 improving separation of frontend and backends in the frontend 
 development workflow so that it becomes equally convenient to 
 develop frontend patches against every backend. (Though it may 
 be possible to make the case that this would happen more 
 quickly if LLVM or GCC were made the default backend, as it's 
 plausible that the developers of LDC and GDC are more aware of 
 what needs to be done in that department.)


One of the benefits of having your own backend is that you have 
control over it right? I don't think anyone here would disagree 
the current backend is garbage. It is legacy C, it is difficult 
to read and write and is full of bugs. All the while only one 
person is really working on it.

Since we have full control why isn't a better backend created? 
This is indicative of the real problems that are being faced. 
Lack of manpower.
Dec 19 2020
next sibling parent reply Jeeferson <jeeferson.johnson gmail.com> writes:
On Saturday, 19 December 2020 at 20:36:07 UTC, Jeeferson wrote:

 On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. 
 Might even be easier to write a whole new backend from 
 scratch, i dont know. IE. Not having DMD doesnt preclude the 
 benefit that Walter claims DMD gives us.
 


 Building LLVM from scratch takes multiple hours. Building DMD 
 from scratch (including backend) takes _seconds_.


 Anyone that says LLVM takes multiple hours obviously hasn't 
 built it, or are using a 20 year old computer to build it.

 Once you build LLVM you don't build it again. Unless you are 
 modifying LLVM itself, which LDC only has one or two commits 
 that make changes, for Android for local thread storage. So if 
 you are developing a compiler it would still only take seconds.


To add onto that, you can also down it prebuilt, it also 
available on most Linux distros because it is so widely used and 
adopted. So you won't be building it yourself most of the time 
anyways.
Dec 19 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 19.12.20 22:04, Jeeferson wrote:

 On Saturday, 19 December 2020 at 20:36:07 UTC, Jeeferson wrote:

 On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 2. People could just add it to LLVM if they want i think. Might even 
 be easier to write a whole new backend from scratch, i dont know. 
 IE. Not having DMD doesnt preclude the benefit that Walter claims 
 DMD gives us.


 Building LLVM from scratch takes multiple hours. Building DMD from 
 scratch (including backend) takes _seconds_.


 Anyone that says LLVM takes multiple hours obviously hasn't built it, 
 or are using a 20 year old computer to build it.

 Once you build LLVM you don't build it again. Unless you are modifying 
 LLVM itself, which LDC only has one or two commits that make changes, 
 for Android for local thread storage. So if you are developing a 
 compiler it would still only take seconds.


 
 To add onto that, you can also down it prebuilt, it also available on 
 most Linux distros because it is so widely used and adopted. So you 
 won't be building it yourself most of the time anyways.
 


Dependencies are simple in theory. In practice things sometimes go 
wrong. Then you have to figure out why instead of just doing what you 
wanted to be doing. The worst case is when a dependency is causing build 
trouble in some component you don't need but the build is tangled up in 
a way that does not easily allow you to get only the component that you 
actually need. E.g., I once had to build a specific commit of llvm to 
compile a latex file. Of course that commit did not actually compile 
with the latest g++, etc. I don't really see why anyone should have to 
touch anything related to llvm to add some new feature to the parser.
Dec 19 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 20 December 2020 at 04:22:29 UTC, Timon Gehr wrote:

 On 19.12.20 22:04, Jeeferson wrote:

 [...]


 Dependencies are simple in theory. In practice things sometimes 
 go wrong. Then you have to figure out why instead of just doing 
 what you wanted to be doing. The worst case is when a 
 dependency is causing build trouble in some component you don't 
 need but the build is tangled up in a way that does not easily 
 allow you to get only the component that you actually need. 
 E.g., I once had to build a specific commit of llvm to compile 
 a latex file. Of course that commit did not actually compile 
 with the latest g++, etc. I don't really see why anyone should 
 have to touch anything related to llvm to add some new feature 
 to the parser.


DMD rocks. Stop complaining and make PRs if you want to change 
something.
Dec 30 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 30 December 2020 at 12:14:28 UTC, Imperatorn wrote:

 DMD rocks. Stop complaining and make PRs if you want to change 
 something.


Note to everyone ^, didn't mean to reply like that 😒
Dec 30 2020
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.12.20 21:36, Jeeferson wrote:

 On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 2. People could just add it to LLVM if they want i think. Might even 
 be easier to write a whole new backend from scratch, i dont know. IE. 
 Not having DMD doesnt preclude the benefit that Walter claims DMD 
 gives us.


 Building LLVM from scratch takes multiple hours. Building DMD from 
 scratch (including backend) takes _seconds_.


 
 Anyone that says LLVM takes multiple hours obviously hasn't built it, or 
 are using a 20 year old computer to build it.
 ...


False. Maybe it improved in the meantime, maybe there were some missing 
flags to the cmake invocation. (Also, you are assuming the build just 
works if you follow the instructions.)


 Once you build LLVM you don't build it again.


My point was there's some value in simplifying initial setup. Git clone 
and get started. Dependencies on a huge C++ project can be more painful 
than not having those dependencies.


 ...
 
 The user base that compiles DMD is infinitely smaller than the amount 
 that use it.


False, there's a positive number of people working on DMD (and they are 
the ones who actually decide what happens to the backend).


 The only opinion I've heard from the D dev team is that 
 they hate the backend and see the DMD backend as obsolete.


So either you don't read or Walter is not on the dev team. Got it.


 So not sure who you are really referring to here, in reality.
 


I have contributed language features to the frontend and not having to 
deal with getting LLVM setup right was a plus. (I never said I couldn't 
be bothered to do it.)


 Anyway, I think the solution is not to change the default development 
 compiler, it's to get rid of that concept by improving separation of 
 frontend and backends in the frontend development workflow so that it 
 becomes equally convenient to develop frontend patches against every 
 backend. (Though it may be possible to make the case that this would 
 happen more quickly if LLVM or GCC were made the default backend, as 
 it's plausible that the developers of LDC and GDC are more aware of 
 what needs to be done in that department.)


 
 One of the benefits of having your own backend is that you have control 
 over it right? I don't think anyone here would disagree the current 
 backend is garbage. It is legacy C, it is difficult to read and write 
 and is full of bugs. All the while only one person is really working on it.
 
 Since we have full control why isn't a better backend created? This is 
 indicative of the real problems that are being faced. Lack of manpower.
 


I really hate the way some people just assume there are two positions on 
any given matter and start superficially classifying people into one of 
two stances. My point was that it's stupid to claim the DMD backend does 
not have _any_ benefits over LLVM. Anyone should be able to agree with 
that, it's completely obvious no matter how you stand on whether or not 
work on the DMD backend should continue or not.
Dec 19 2020
prev sibling parent reply claptrap <clap trap.com> writes:
On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:

 On 19.12.20 18:15, claptrap wrote:

 
 2. People could just add it to LLVM if they want i think. 
 Might even be easier to write a whole new backend from 
 scratch, i dont know. IE. Not having DMD doesnt preclude the 
 benefit that Walter claims DMD gives us.
 


 Building LLVM from scratch takes multiple hours. Building DMD 
 from scratch (including backend) takes _seconds_.

 Why is it so hard to believe that this is a benefit that an 
 actual compiler developer might care for? It's exactly the 
 prevalence of this kind of common sense pragmatics that makes D 
 so convenient to use despite all flaws. You lose that if you 
 start adding dependencies on projects that lack it.


Tbh i never even thought about how long it takes to actually 
build the compilers. When people talked about compile speed, i 
thought they just meant how long DMD takes to compile something, 
not how long it takes to compile DMD. I can agree 100% that would 
be a hugely important issue, actually if something took 2 hours 
to build i wouldn't even bother.
Dec 20 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 20 December 2020 at 10:19:22 UTC, claptrap wrote:

 something, not how long it takes to compile DMD. I can agree 
 100% that would be a hugely important issue, actually if 
 something took 2 hours to build i wouldn't even bother.


It doesn't…
Dec 20 2020
prev sibling next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
wrote:


 I don't see how LDC and GDC are impaired in any way by DMD.


I feel having a compiler like dmd that takes seconds to build is 
great.

However there is a huge price ... your time !
Dec 17 2020
prev sibling parent reply Kali <kalissey gmail.com> writes:
On Thursday, 17 December 2020 at 06:52:08 UTC, Walter Bright 
wrote:

 On 12/14/2020 1:57 AM, Abdulhaq wrote:

 DMD is Walter's baby and he's going to continue with that, 
 having power over it is secondary to that.
 
 D Foundation of course want to retain control over what they 
 have built, it's years and years of their hard work, decades 
 even. Why should they give control to someone else and why 
 think that that other group would do any better? Arguably it 
 would be irresponsible to do that.



 Having DMD means we can support whatever target we want to, we 
 are not constrained by a community we don't really have a voice 
 in.


Not really... You can add custom targets to LLVM. You have the 
whole framework to back you up so you aren't reimplementing it.


 For example, DMD moved to support Win64 years before LLVM 
 supported it.


So you only added 1 target? When is ARM64 going to be added? LLVM 
has had it for years (along with many other architectures).

You are also comparing apples to oranges. What LLVM achieves is 
implementing *everything* for windows. You can literally replace 
MSVC with LLVM CLang. DMD implements a very small subset of that. 
LLVM supporting Win64 is much much more impressive than DMD 
supporting it.

When you use LLVM it's not "theirs". That's the whole point of 
the community being open source. It is "ours". I feel that's part 
of what is wrong with this community.


 I don't see how LDC and GDC are impaired in any way by DMD.


Maybe you should look into the development of LDC and GDC and 
you'll see the cracks.
Dec 18 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/18/2020 8:10 PM, Kali wrote:

 So you only added 1 target?


The backend targets:

* 16 bit DOS
* 16 bit Windows (yes, it's different)
* 286 protected mode
* 386 DOS extenders
* OS/2

Yes, the above are obsolete. But it shows the adaptability of the backend
design.

* 32 bit Windows
* 64 bit Windows
* OSX 32/64, FreeBSD 32/64, Linux 32/64

There are obsolete 68000 and PowerPC targets written by others.

There's a partial 32 bit ARM target written by another.

Win64 is only one target, sure, but it was a crucial one for D.
Dec 19 2020
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution.


Why does there have to be a default compiler?
Dec 14 2020
parent reply 9il <ilyayaroshenko gmail.com> writes:
On Monday, 14 December 2020 at 11:53:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution.


 Why does there have to be a default compiler?


The meaning of `default` has been described in the following 
sentences of the original post, maybe in a bit strange form 
because of my English level. We would always have a default 
compiler or say `master` compiler. Changes go to DMD first and 
then to other compilers. A one with an ARM notebook can compile, 
run, test, and patch LDC, but actually, she/he would need to 
patch DMD, which can't be compiled for ARM.

Ilya
Dec 14 2020
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 14 December 2020 at 13:36:45 UTC, 9il wrote:

 On Monday, 14 December 2020 at 11:53:26 UTC, Ola Fosheim 
 Grøstad wrote:

 On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution.


 Why does there have to be a default compiler?


 The meaning of `default` has been described in the following 
 sentences of the original post, maybe in a bit strange form 
 because of my English level. We would always have a default 
 compiler or say `master` compiler. Changes go to DMD first and 
 then to other compilers. A one with an ARM notebook can 
 compile, run, test, and patch LDC, but actually, she/he would 
 need to patch DMD, which can't be compiled for ARM.


This would happen anyway regardless of the compiler used for 
testing.

Genuine example: I am (with an intermediate) running the 
testsuite and fixing compiler and library bugs on all macOS 
platforms from darwin8 to darwin20 on i386, x86_64, PPC, and 
PPC64 hardware.  I would *still* actually need to send a patch to 
LDC which can't be compiled for that entire compilation matrix.

IMO, there is something wrong with the language being used to 
compartmentalize the various D language compilers.  Also it is 
pointless changing the status-quo, and frankly it doesn't matter 
what the back-end is.

The way I see things, there is a common base upstream 
implementation, central for all parties involved.  Moving it to 
LDC would be the opposite of centralizing the front-end 
implementation.
Dec 14 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 14 December 2020 at 13:36:45 UTC, 9il wrote:

 The meaning of `default` has been described in the following 
 sentences of the original post, maybe in a bit strange form 
 because of my English level. We would always have a default 
 compiler or say `master` compiler. Changes go to DMD first and 
 then to other compilers. A one with an ARM notebook can 
 compile, run, test, and patch LDC, but actually, she/he would 
 need to patch DMD, which can't be compiled for ARM.


I don't think the development of the front end should depend on 
any particular backend, there should be a proper abstraction 
layer.

The proper fix is to decouple dmd from the dmd backend through a 
high level IR that can support borrowing and ARC.
Dec 15 2020
prev sibling next sibling parent reply Calvin P <cloudlessapp gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.

 Making LDC a default compiler looks like a more rational 
 solution. By default, I mean a branch where we do the main work 
 on the compiler and DRuntime and what is used to make the first 
 release of the new version of the compiler.

 I just realized why we still have DMD as the default compiler 
 and why probably we would have it in the near future.

 D Foundation wants to have full power to make all key 
 decisions. Making LDC a default compiler would also mean they 
 would need to share their authority with others. That is only 
 my opinion, I don't pretend it is right.

 Kind regards,
 Ilya


I support made LDC default compiler. DMD is a dead end.

With LDC we can move fast, and easy add the C++ 20 
co_await/co_async function with LLVM coroutine.

check out this:

https://github.com/trending?l=rust&since=monthly
https://github.com/trending?l=go&since=monthly
https://github.com/trending?l=swift&since=monthly
https://github.com/trending?l=js&since=monthly
https://github.com/trending?l=d&since=monthly
Dec 14 2020
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 14 December 2020 at 14:45:58 UTC, Calvin P wrote:

 I support made LDC default compiler. DMD is a dead end.

 With LDC we can move fast, and easy add the C++ 20 
 co_await/co_async function with LLVM coroutine.


I speak regularly with the person who's implementing 
-fcoroutines, and no, you wouldn't be able to just add co_await 
and co_async. ;-)
Dec 14 2020
prev sibling next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.


[Citation needed]

I agree that ARM is an important architecture, and will probably 
become even moreso in the next few years. But AMD, at least, is 
not standing still and Intel's microarchitectures are still 
excellent; they just need to manufacture them on a better process 
to become highly competitive again.
Dec 14 2020
parent reply RSY <rsy_881 gmail.com> writes:
I agree with ARM, it should be something everyone could target 
(crosstarget) easily

As for LDC as default, i disagree, compilation time with LDC is 
very slow, even in debug mode, so DMD should stay default for the 
sake of quick iteration during development
Dec 14 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 15 December 2020 at 02:10:26 UTC, RSY wrote:

 I agree with ARM, it should be something everyone could target 
 (crosstarget) easily

 As for LDC as default, i disagree, compilation time with LDC is 
 very slow, even in debug mode, so DMD should stay default for 
 the sake of quick iteration during development


Yeah, I think that if you have a workflow where compilation times 
don't matter much, moving away from DMD makes a lot of sense. If 
you have a workflow that involves lots of compilation, D with LDC 
is unimpressive. A fruitful initiative would be improving DMD's 
compilation speeds at the expense of optimizations. Even better 
would be a REPL. Everyone needing blazing speed already uses LDC 
or GDC for those builds.
Dec 15 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 15, 2020 at 04:47:46PM +0000, bachmeier via Digitalmars-d wrote:
[...]

 A fruitful initiative would be improving DMD's compilation speeds at
 the expense of optimizations.


[...]

I honestly doubt we'd gain any significant compilation speed by
pessimizing optimizations any more than they already are in DMD. In
fact, I don't even bother with -O when I'm using DMD, due to codegen
bugs that often get triggered by -O.  Whenever I bother to use DMD, it's
because I want fast compile times, I don't care for optimizations. (If I
wanted optimizations I'd use LDC instead, any day.)  So we're not going
to gain anything by making DMD optimizations even worse.

Instead, what would actually benefit everyone is to make the front-end
faster, because the front-end is shared by all 3 compilers. As Andrei
and Stefan has posted in the past, the bottlenecks are mainly in CTFE
and recursive template expansions.  If the front-end improves in this
area, it helps *all* 3 compilers, not just DMD.  So forget about
DMD-specific (i.e., backend) improvements; instead, improve the
front-end, and everybody wins.  The DMD backend is already sufficiently
fast for what it does anyway; it's not even the bottleneck in the first
place.  It's the recursive template instantations in the front-end that
are the bottleneck. And CTFE, to a lesser extent.


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. --
Benjamin Franklin
Dec 15 2020
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 15 December 2020 at 02:10:26 UTC, RSY wrote:

 As for LDC as default, i disagree, compilation time with LDC is 
 very slow, even in debug mode, so DMD should stay default for 
 the sake of quick iteration during development


At least until LLVM has as fast code generation as DMD.
Dec 30 2020
prev sibling next sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.


I work with ARM daily (automotive) and I'm skeptical of that 
assumption. Sure Apple is moving over, but that's a more 
centralised and controlled ecosystem. It won't be as easy with 
Windows or GNU+Linux.

Why would the developers put in all that effort if it turns out 
to be another "Year of the Linux desktop" or "Rust is superior 
and everyone will be using it"?It would be safer and less of a 
hassle to react to market conditions than to predict and preempt 
them.

Let the chips fall where they may, and work based on that. It's 
too early yet.
Dec 15 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham wrote:

 I work with ARM daily (automotive) and I'm skeptical of that 
 assumption. Sure Apple is moving over, but that's a more 
 centralised and controlled ecosystem. It won't be as easy with 
 Windows or GNU+Linux.

 Why would the developers put in all that effort if it turns out 
 to be another "Year of the Linux desktop" or "Rust is superior 
 and everyone will be using it"?It would be safer and less of a 
 hassle to react to market conditions than to predict and 
 preempt them.

 Let the chips fall where they may, and work based on that. It's 
 too early yet.


Apple might have gone over to ARM but in the Windows world x86 
isn't going away anytime soon. There is simply too much SW for 
x86 for people making the switch. There are x86 emulators but the 
performance is probably not satisfactory right now.

I would rather say that ARM is getting more competition in 
embedded. Because of the recent sales of ARM, this is enough to 
get some people scared. They believe that the business model of 
ARM is going away or they will refocus. Regardless if this is 
true or not some are looking at alternatives and that might be 
RISC V. Also where cost is important RISC V will have an 
advantage. The rising star in my opinion is RISC V.
Dec 15 2020
next sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham 
 wrote:

 [...]


 Apple might have gone over to ARM but in the Windows world x86 
 isn't going away anytime soon. There is simply too much SW for 
 x86 for people making the switch. There are x86 emulators but 
 the performance is probably not satisfactory right now.


Apple can emulate x86 quite fast, we can expect MS can do the 
same.


 I would rather say that ARM is getting more competition in 
 embedded. Because of the recent sales of ARM, this is enough to 
 get some people scared. They believe that the business model of 
 ARM is going away or they will refocus. Regardless if this is 
 true or not some are looking at alternatives and that might be 
 RISC V. Also where cost is important RISC V will have an 
 advantage. The rising star in my opinion is RISC V.


Agreed. And this looks like another one reason to make the LLVM 
backend default.
Dec 15 2020
next sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham 
 wrote:

 [...]




 Agreed. And this looks like another one reason to make the LLVM 
 backend default.


Not really. All those targets will need runtime support from the 
foundation. As is, runtime support aside from X86, AMD64 is 
somewhat lacklustre even on GDC and LDC, and it's not easy to 
produce runtimes.

In my opinion it's best to have a bleeding-edge implementation 
that the foundation can work out language issues and experiment 
on and then other compilers that can focus on multi-targeting and 
LLVM/GCC interfacing.
Dec 15 2020
prev sibling next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham 
 wrote:

 [...]


 Apple might have gone over to ARM but in the Windows world x86 
 isn't going away anytime soon. There is simply too much SW for 
 x86 for people making the switch. There are x86 emulators but 
 the performance is probably not satisfactory right now.


 Apple can emulate x86 quite fast, we can expect MS can do the 
 same.


 I would rather say that ARM is getting more competition in 
 embedded. Because of the recent sales of ARM, this is enough 
 to get some people scared. They believe that the business 
 model of ARM is going away or they will refocus. Regardless if 
 this is true or not some are looking at alternatives and that 
 might be RISC V. Also where cost is important RISC V will have 
 an advantage. The rising star in my opinion is RISC V.


 Agreed. And this looks like another one reason to make the LLVM 
 backend default.


So we fragment the ecosystem just to make it easier to use a 
compiler that anyone bothering to use D in the first place will 
see either on the website or by googling "dlang arm"? Previous 
fragmentations (i.e. Tango from 10 years ago) *still* come up in 
discussions of D - even on hackernews where people have actually 
heard of us.

This is just bikeshedding. If people want to run D on their 
RISC-V cores they'll have ldc and gcc to choose from, anyone 
actually using a non-x86 ISA wont have any problem with that.
Dec 15 2020
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 I would rather say that ARM is getting more competition in 
 embedded. Because of the recent sales of ARM, this is enough 
 to get some people scared. They believe that the business 
 model of ARM is going away or they will refocus. Regardless if 
 this is true or not some are looking at alternatives and that 
 might be RISC V. Also where cost is important RISC V will have 
 an advantage. The rising star in my opinion is RISC V.


 Agreed. And this looks like another one reason to make the LLVM 
 backend default.


As far as I know, only GDC supports RISC-V as a first class 
citizen.  So another reason *not* to make LLVM backend the 
default, actually. ;-)
Dec 15 2020
next sibling parent reply Calvin P <cloudlessapp gmail.com> writes:
On Tuesday, 15 December 2020 at 15:40:20 UTC, Iain Buclaw wrote:

 As far as I know, only GDC supports RISC-V as a first class 
 citizen.  So another reason *not* to make LLVM backend the 
 default, actually. ;-)


Maybe. But compare GDC with LDC, LDC is the winner for me.

I use it to build linux/osx/mingw/andoird/ios product(X86 & ARM 
on all list OS), It do a great job almost all the time.
Dec 15 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 15 December 2020 at 15:53:47 UTC, Calvin P wrote:

 Maybe. But compare GDC with LDC, LDC is the winner for me.


I find both are pretty good for a lot of things. I use gdc on my 
raspberry pi for example because it is included in the os and 
just works. I use ldc for its webassembly output because it just 
works.

But I use dmd for most things because it rox too. Any dev work I 
do on D-the-language is always done on dmd's source too since it 
is by far the easiest to hack on.

There's no downside to having the three compilers.
Dec 15 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 15 December 2020 at 16:05:40 UTC, Adam D. Ruppe wrote:

 There's no downside to having the three compilers.


The downside is that dmd will most likely prevent new language 
features like stackless coroutines.
Dec 15 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Tuesday, 15 December 2020 at 20:08:52 UTC, Ola Fosheim Grostad 
wrote:

 On Tuesday, 15 December 2020 at 16:05:40 UTC, Adam D. Ruppe 
 wrote:

 There's no downside to having the three compilers.


 The downside is that dmd will most likely prevent new language 
 features like stackless coroutines.


I wouldn't have thought so, as language features squarely land in 
the common D front-end, rather than needing any special support 
in each respective compiler.  From what I've seen of -fcoroutines 
in gcc, there is very little being handed over for the middle-end 
to manage, and zilch in the back-end.
Dec 15 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 16 December 2020 at 00:34:12 UTC, Iain Buclaw wrote:

 On Tuesday, 15 December 2020 at 20:08:52 UTC, Ola Fosheim 
 Grostad wrote:

 On Tuesday, 15 December 2020 at 16:05:40 UTC, Adam D. Ruppe 
 wrote:

 There's no downside to having the three compilers.


 The downside is that dmd will most likely prevent new language 
 features like stackless coroutines.


 I wouldn't have thought so, as language features squarely land 
 in the common D front-end, rather than needing any special 
 support in each respective compiler.  From what I've seen of 
 -fcoroutines in gcc, there is very little being handed over for 
 the middle-end to manage, and zilch in the back-end.


How efficient is it then? Compared to non coroutine execution?
Dec 16 2020
prev sibling parent reply 9il <ilyayaroshenko gmail.com> writes:
On Tuesday, 15 December 2020 at 15:40:20 UTC, Iain Buclaw wrote:

 On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 [...]


 Agreed. And this looks like another one reason to make the 
 LLVM backend default.


 As far as I know, only GDC supports RISC-V as a first class 
 citizen.  So another reason *not* to make LLVM backend the 
 default, actually. ;-)


Let's go with GDC :)
Dec 15 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 15, 2020 at 04:36:25PM +0000, 9il via Digitalmars-d wrote:

 On Tuesday, 15 December 2020 at 15:40:20 UTC, Iain Buclaw wrote:

 On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 [...]


 
 Agreed. And this looks like another one reason to make the LLVM
 backend default.


 
 As far as I know, only GDC supports RISC-V as a first class citizen.
 So another reason *not* to make LLVM backend the default, actually.
 ;-)


 
 Let's go with GDC :)


The point is there's a choice of different compilers for different
needs.  No need to promote one to the exclusion of others. ;-)


T

-- 
Life is complex. It consists of real and imaginary parts. -- YHL
Dec 15 2020
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 15 December 2020 at 16:36:25 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 15:40:20 UTC, Iain Buclaw wrote:

 On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 [...]


 Agreed. And this looks like another one reason to make the 
 LLVM backend default.


 As far as I know, only GDC supports RISC-V as a first class 
 citizen.  So another reason *not* to make LLVM backend the 
 default, actually. ;-)


 Let's go with GDC :)


Let's write a new backend from scratch in D that targets only 
WebAssembly and make that the "default" "master" D compiler :P
Dec 15 2020
parent reply twk <abc xyz.com> writes:
I would like to point out that ARM also has other competition:

https://riscv.org/

So we do not want to base all of our decisions on ARM.
Dec 15 2020
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 15 December 2020 at 23:11:32 UTC, twk wrote:

 I would like to point out that ARM also has other competition:

 https://riscv.org/

 So we do not want to base all of our decisions on ARM.


My point was to sidestep the whole argument about what 
ISA/platform is going to be the most popular one and also which 
backend should be the default among dmc/gcc/llvm by choosing 
neither and building a new one from scratch.
Perhaps it wasn't apparent from my post, but I was joking :)

Okay, perhaps only half joking, as choosing a virtual ISA that is 
already this widespread, stable enough, with adoption rapidly 
growing (just look at all the excitement arond WASI, wasm for 
blockchain, the bytcode alliance, wasm for backend apps (even as 
a sandbox, instead of containers) (see also the precursor to that 
- CloudABI) etc.), cross-platform (supported on way more 
platforms than what dmd can target) and with more backends than 
D's big 3, actually has some nice befits, like making it easier 
to build a REPL, safer dynamic code generation, faster edit-debug 
cycle, etc. Ability to build and run D on any platform for which 
the there is a wasm AoT compiler, JIT or at least an interpreter. 
Also a good opportunity to retractor druntime and phobos to be 
less libc, or even Posix dependent, less GC-reliant and generally 
more modular and pay-as-you go.

P.S. I know about RISC-V as I'm waiting SiFive to release their 
16GB RAM boards as I don't like being forced to use separate 
compilation to build D code especially when playing with CTFE and 
TMP monsters :P

P.S.S. Perhaps the future neither x86_64, nor IBM POWER, nor 
MIPS, nor ARM, etc., but FPGAs :P
Dec 15 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 16 December 2020 at 01:37:50 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Tuesday, 15 December 2020 at 23:11:32 UTC, twk wrote:

 I would like to point out that ARM also has other competition:

 https://riscv.org/

 So we do not want to base all of our decisions on ARM.


 My point was to sidestep the whole argument about what 
 ISA/platform is going to be the most popular one and also which 
 backend should be the default among dmc/gcc/llvm by choosing 
 neither and building a new one from scratch.
 Perhaps it wasn't apparent from my post, but I was joking :)

 Okay, perhaps only half joking, as choosing a virtual ISA that 
 is already this widespread, stable enough, with adoption 
 rapidly growing (just look at all the excitement arond WASI, 
 wasm for blockchain, the bytcode alliance, wasm for backend 
 apps (even as a sandbox, instead of containers) (see also the 
 precursor to that - CloudABI) etc.), cross-platform (supported 
 on way more platforms than what dmd can target) and with more 
 backends than D's big 3, actually has some nice befits, like 
 making it easier to build a REPL, safer dynamic code 
 generation, faster edit-debug cycle, etc. Ability to build and 
 run D on any platform for which the there is a wasm AoT 
 compiler, JIT or at least an interpreter. Also a good 
 opportunity to retractor druntime and phobos to be less libc, 
 or even Posix dependent, less GC-reliant and generally more 
 modular and pay-as-you go.

 P.S. I know about RISC-V as I'm waiting SiFive to release their 
 16GB RAM boards as I don't like being forced to use separate 
 compilation to build D code especially when playing with CTFE 
 and TMP monsters :P

 P.S.S. Perhaps the future neither x86_64, nor IBM POWER, nor 
 MIPS, nor ARM, etc., but FPGAs :P


I assume compiling dmd on an FPGA would take a mere day or two to 
actually finish. FPGA's are not good at general purpose 
computing, although I believe dcompute can use them.

Ultimately in this discussion of arm and RISC-V making the 
frontend asm {} blocks understand them would probably do more 
than changing compilers. It's a relatively simple thing to have 
but I don't think any other language can do it.
Dec 15 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 16 December 2020 at 05:20:21 UTC, Max Haughton 
wrote:

 Ultimately in this discussion of arm and RISC-V making the 
 frontend asm {} blocks understand them would probably do more 
 than changing compilers. It's a relatively simple thing to have 
 but I don't think any other language can do it.


asm {} blocks are cross platform without needing special support.


uint result = void;
version (ARM)
{
     asm nothrow  nogc
     {
         "vmrs %0, FPSCR;

     }
}
else version (RISCV32)
{
     asm nothrow  nogc
     {
         "frflags %0" : "=r" (result);
     }
}
return result;
Dec 16 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 16 December 2020 at 10:26:46 UTC, Iain Buclaw wrote:

 On Wednesday, 16 December 2020 at 05:20:21 UTC, Max Haughton 
 wrote:

 Ultimately in this discussion of arm and RISC-V making the 
 frontend asm {} blocks understand them would probably do more 
 than changing compilers. It's a relatively simple thing to 
 have but I don't think any other language can do it.


 asm {} blocks are cross platform without needing special 
 support.


 uint result = void;
 version (ARM)
 {
     asm nothrow  nogc
     {
         "vmrs %0, FPSCR;

     }
 }
 else version (RISCV32)
 {
     asm nothrow  nogc
     {
         "frflags %0" : "=r" (result);
     }
 }
 return result;


I know I just like the dmd-style ones, it feels much more 
ergonomic than the equivalent in C++. I'm not a huge fan of GCC 
style asm, but ultimately I guess I'm bikeshedding.
Dec 16 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/16/2020 2:33 AM, Max Haughton wrote:

 I know I just like the dmd-style ones, it feels much more ergonomic than the 
 equivalent in C++. I'm not a huge fan of GCC style asm, but ultimately I guess 
 I'm bikeshedding.


The dmd-style ones hearken back to the good ole DOS days, where MASM matched
the 
Intel documentation. It's an evolved version of the inline assembler used by 
Digital Mars C, which matches MASM and Intel.

Intel has kept the same syntax ever since, and DMD's inline asm has kept on 
matching it.

The same syntax is generated by obj2asm.

If DMD ever did an ARM back end, the syntax would match the official ARM 
vendor's CPU documentation.
Dec 17 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 17 December 2020 at 08:52:40 UTC, Walter Bright 
wrote:

 On 12/16/2020 2:33 AM, Max Haughton wrote:

 I know I just like the dmd-style ones, it feels much more 
 ergonomic than the equivalent in C++. I'm not a huge fan of 
 GCC style asm, but ultimately I guess I'm bikeshedding.


 The dmd-style ones hearken back to the good ole DOS days, where 
 MASM matched the Intel documentation. It's an evolved version 
 of the inline assembler used by Digital Mars C, which matches 
 MASM and Intel.

 Intel has kept the same syntax ever since, and DMD's inline asm 
 has kept on matching it.


Though one critique would be that DMD is always behind on 
instruction set support, as of writing I don't think even 
AVX-512F can be used yet.
Dec 17 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/17/2020 2:41 PM, Iain Buclaw wrote:

 Though one critique would be that DMD is always behind on instruction set 
 support, as of writing I don't think even AVX-512F can be used yet.


Intel keeps moving the goal posts :-)

Sometimes others have added such support, so it's not impossible.
Dec 17 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 16 December 2020 at 01:37:50 UTC, Petar Kirov 
[ZombineDev] wrote:

 On Tuesday, 15 December 2020 at 23:11:32 UTC, twk wrote:

 I would like to point out that ARM also has other competition:

 https://riscv.org/

 So we do not want to base all of our decisions on ARM.


 My point was to sidestep the whole argument about what 
 ISA/platform is going to be the most popular one and also which 
 backend should be the default among dmc/gcc/llvm by choosing 
 neither and building a new one from scratch.
 Perhaps it wasn't apparent from my post, but I was joking :)


Actually, it was a pretty good idea, but I dont think Walter 
would accept that dmd is turned into a pure reference 
implementation.  It would have made it easier to improve the 
language IMO.  Making experimental changes to dmd has an 
unfortunately high implementation cost. A simpler reference 
implementation would surely open up for a serious code base 
cleanup and encourage more experimental language additions.
Dec 16 2020
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 15 December 2020 at 12:04:38 UTC, 9il wrote:

 On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 [...]


 Apple can emulate x86 quite fast, we can expect MS can do the 
 same.


Because they control the whole stack. They are also limited to 
pure 64 bit code. Windows would have to support at least 32 bit 
x86 and in that case it gets hairy.
Dec 16 2020
prev sibling parent Dylan Graham <dylan.graham2000 gmail.com> writes:
On Tuesday, 15 December 2020 at 10:13:41 UTC, IGotD- wrote:

 On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham 
 wrote:

 I work with ARM daily (automotive) and I'm skeptical of that 
 assumption. Sure Apple is moving over, but that's a more 
 centralised and controlled ecosystem. It won't be as easy with 
 Windows or GNU+Linux.

 Why would the developers put in all that effort if it turns 
 out to be another "Year of the Linux desktop" or "Rust is 
 superior and everyone will be using it"?It would be safer and 
 less of a hassle to react to market conditions than to predict 
 and preempt them.

 Let the chips fall where they may, and work based on that. 
 It's too early yet.


 Apple might have gone over to ARM but in the Windows world x86 
 isn't going away anytime soon. There is simply too much SW for 
 x86 for people making the switch. There are x86 emulators but 
 the performance is probably not satisfactory right now.

 I would rather say that ARM is getting more competition in 
 embedded. Because of the recent sales of ARM, this is enough to 
 get some people scared. They believe that the business model of 
 ARM is going away or they will refocus. Regardless if this is 
 true or not some are looking at alternatives and that might be 
 RISC V. Also where cost is important RISC V will have an 
 advantage. The rising star in my opinion is RISC V.


32 bit ARM chips are $5.32 AUD for a single unit. If the RISC-V 
can come out much cheaper then mass produced items will be 
probably be the first to mass-migrate. A dollar or two difference 
might not mean much to a hobbyist but in a production line that 
scales up to thousands -> tens or hundreds of thousands of 
dollars. From there it'd probably snow ball into other fields. 
Electronics / embedded production (and its firmware) is ever 
changing and would make the most sense to gnaw at that market 
before attempting to conquer PC.
Dec 15 2020
prev sibling parent Guillaume Piolat <first.name guess.com> writes:
On Tuesday, 15 December 2020 at 08:06:34 UTC, Dylan Graham wrote:

 On Monday, 14 December 2020 at 04:35:31 UTC, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few 
 years.


 I work with ARM daily (automotive) and I'm skeptical of that 
 assumption. Sure Apple is moving over, but that's a more 
 centralised and controlled ecosystem. It won't be as easy with 
 Windows or GNU+Linux.


I would say Apple is more interested in being able to deprecate 
stuff than in the architecture itseful.

For example in that macOS arm64, Universal Binary 2 (arm64 + 
x86_64) built in macOS 11.0 won't work anymore in macOS 10.11 so 
it will make the users stuck on this macOS version to eventually 
**buy another Mac**, which is the entire point of it all. Each 
year, as a software dev they make you drop one or two versions 
quite efficiently.
Dec 15 2020
prev sibling parent reply James Blachly <james.blachly gmail.com> writes:
On 12/13/20 11:35 PM, 9il wrote:

 ARM is going to conquer laptop and PC markets in the next few years.
 


...

AWS Graviton [0] is also ARM-based, and I didn't see any other mention 
in this thread. As these cloud instances are significantly cheaper than 
Intel based EC2 instances, it will be important for those of us writing 
enterprise software to have first class ARM support.

[0] https://aws.amazon.com/ec2/graviton/
Dec 30 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 02:30:57 UTC, James Blachly 
wrote:

 AWS Graviton [0] is also ARM-based, and I didn't see any other 
 mention in this thread. As these cloud instances are 
 significantly cheaper than Intel based EC2 instances, it will 
 be important for those of us writing enterprise software to 
 have first class ARM support.


But why deploy dmd compiled code when you can use ldc?
Dec 31 2020
prev sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 31 December 2020 at 02:30:57 UTC, James Blachly 
wrote:

 On 12/13/20 11:35 PM, 9il wrote:
 AWS Graviton [0] is also ARM-based, and I didn't see any other 
 mention in this thread. As these cloud instances are 
 significantly cheaper than Intel based EC2 instances, it will 
 be important for those of us writing enterprise software to 
 have first class ARM support.


You have LDC for that?
Dec 31 2020
parent reply James Blachly <james.blachly gmail.com> writes:
On 12/31/20 3:17 AM, Ola Fosheim Grostad wrote:

 On Thursday, 31 December 2020 at 02:30:57 UTC, James Blachly wrote:

 On 12/13/20 11:35 PM, 9il wrote:
 AWS Graviton [0] is also ARM-based, and I didn't see any other mention 
 in this thread. As these cloud instances are significantly cheaper 
 than Intel based EC2 instances, it will be important for those of us 
 writing enterprise software to have first class ARM support.


 
 You have LDC for that?
 


You responded twice so not sure which to respond to. In any case, I am 
aware LDC via LLVM has support for ARM; I was really just trying to 
provide support to Ilya's argument about the coming importance of ARM 
overall (not Apple M1 specific)

Kind regards
Jan 02 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 3 January 2021 at 02:48:32 UTC, James Blachly wrote:

 On 12/31/20 3:17 AM, Ola Fosheim Grostad wrote:

 You have LDC for that?
 


 You responded twice so not sure which to respond to.


A bug in the d forum software? The web interface was hangingand 
it didnt show up in the web interface,, so I tried again... :-/
Jan 03 2021