DMD backend generation future with the new AI race processor

[Brad Roberts]

The issues I had with doing the arm DMD backend were primarily the 
difficulty of deciphering and penetrating the dmd backend, not the arm 
parts.  The other big issue I had was me and my work patterns.  I got 
enough done that I knew it could be done.  That's an inflection point 
for me where it's likely I'll drop many projects, particularly the 
exploratory ones.  I was also busy with a more than full time job and 
had to prioritize it over massive side projects.

Combine that with the timing, and it just didn't make sense to continue 
the work.  This was about 10 years ago and LDC and GDC were becoming 
very usable, which brought along arm backends that were far more mature 
and already very usable.

If anyone wants to pick up the work, it's in the arm branch of my dmd 
fork.  Chances are it'd take a week or three to bring it back up to 
where I left it, meaning the barely capable of doing any code gen.  A 
LOT has changed over the years, but the touch points with the backend 
code haven't evolved all that much compared to the front end).  This 
would have been before the code base was all D and before switching to 
build.d -- neither of which are actually a big problem, just gives a bit 
of what era we're talking about.

As to being competitive, that's unrealistic for the same reason that 
dmd's backend isn't competitive with ldc and gdc.  It can reach the 
level of competent and usable (which _is_ a useful level of 
functionality), but there's just no way to complete with the legions of 
engineers that work on those optimizers and backend code generators.

My 2 cents,
Brad

On 3/10/2024 12:42 PM, Walter Bright via Digitalmars-d wrote:
> Brad looked into doing an ARM backend for DMD many years ago, but gave 
> it up as too much work.
> 
> I'd love to do a competitive one, but it would take a while.