ARM first & default LDC

[Max Haughton]

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.