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