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

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.

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

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.

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. ;-)

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.

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.

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.

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

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