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.

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

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.

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;
         and %0, %0, #0x1F;" : "=r" (result);
    }
}
else version (RISCV32)
{
    asm nothrow @nogc
    {
        "frflags %0" : "=r" (result);
    }
}
return result;

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;
>          and %0, %0, #0x1F;" : "=r" (result);
>     }
> }
> 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.

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.

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?

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.

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.

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.