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.

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.

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

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.

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.

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

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

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.

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

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.