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.

On 11/03/2024 8:42 AM, Walter Bright 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.

For reference here is an old C++ version that was modified for ARM by Iain/Brad.

https://github.com/ibuclaw/dmd/tree/dmd-cxx-arm

This would be an ideal project to throw a student at long term (PhD maybe?).

If we don't, OSX support for dmd is dead, and we might as well kill it off now.

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.

On 11/03/2024 11:55 AM, Brad Roberts wrote:
> 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.

I can't even find leafs or entry points to begin an understanding.

So +1 on the indecipherable aspect to it.

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

Walter has recently been arguing against @restrict, and previously argued against atomics being intrinsics with me.

Even with Walter working full time on it for a few years, that backend will never match what LLVM 19 can do without things like that.

It is unfortunate.

On Sunday, 10 March 2024 at 22:55:32 UTC, Brad Roberts wrote:
> 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.

I'm happy to help with this project.  I also don't think we'll hit LDC performance, but there's benefits to being self hosting on ARM platforms without LDC/GDC.

On Monday, 11 March 2024 at 20:32:44 UTC, Ben Jones wrote:
> On Sunday, 10 March 2024 at 22:55:32 UTC, Brad Roberts wrote:
>> 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.
>
> I'm happy to help with this project.  I also don't think we'll hit LDC performance, but there's benefits to being self hosting on ARM platforms without LDC/GDC.

Maybe we could consider adding a backend for the Go language toolchain. I think there are many similarities between the D and Go languages, such as simplicity, readability, and speed.

On 3/10/2024 3:55 PM, Brad Roberts wrote:
> 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.

I meant competitive in terms of being equivalent to the x86 code generator.

On 3/10/2024 5:40 PM, Richard (Rikki) Andrew Cattermole wrote:
> Even with Walter working full time on it for a few years, that backend will never match what LLVM 19 can do without things like that.

I regularly have people telling me what I can't do :-)

For example, people in this forum used to tell me that DMD didn't do Data Flow Analysis and DFA had been invented in the 2000s.

Never mind that Datalight C circa 1985 was the very first DOS compiler to do DFA.

I was told the backend couldn't do loop unrolling which was a special magical thing that only super advanced engineers could write, which it now does.

Then I was told the backend couldn't do SROA, which it does now.

Then I was told the backend couldn't do SIMD, which it does now.

And so on.

It just takes time to do these things, and I'm pretty booked. The DMD backend is doing remarkably well considering how little time I spend on it.

Just recently the imminent demise of it was predicted because it wasn't generating IBT (Indirect Branch Tracking) code. It generates IBT now.

Nice to see you here, Brad!