In recent days, it has become abundantly clear that the x86 architecture appears to be headed for obsolescence. The Arm processor is taking over. The Mac is dropping the x86 in favor of Arm. Microsoft has announced Arm laptops.

Even my Raspberry Pi is an Arm64.

What to do about dmd? Many people in the D community have expressed interest in creating an Arm backend for D. Since implementing a 64 bit code generator is trivial, I thought I'd look into it.

I bought a couple books on the Arm, and have been studying the datasheet for it. Most of the backend can be repurposed to Arm. The structure of it can remain the same.

The goal is Arm64, not Arm32. Since even the Pi is Arm64, there is no purpose in supporting the Arm32.

Hacking away listening to Brain Pain metal, the first function compiles:

```
void foo() { }
```

dmd -c test.d -vasm

producing:

```
_D4test3fooFZv:
0000:   D6 5F 03 C0  ret
```

And there it is! Nothing else works, but what the heck.

https://github.com/WalterBright/dmd/commit/04546a8f72c10a09764f23675c67c5fbdf29628c

Awesome work!

You are inspiring me to consider doing a bit of work on the backend.

I've already checked, first possible thing to consider is to move all the object format stuff from frontend into backend to make it more self contained.

Who knows, maybe that backend could be attractive in the hobbyist compiler community yet!

Walter Bright kirjoitti 2.6.2024 klo 9.30:
> Hacking away listening to Brain Pain metal, the first function compiles:
> 
> ```
> void foo() { }
> ```
> 
> dmd -c test.d -vasm
> 
> producing:
> 
> ```
> _D4test3fooFZv:
> 0000:   D6 5F 03 C0  ret
> ```
> 
> And there it is! Nothing else works, but what the heck.

Nice. A long way to go but you have to start somewhere!

Question, what's the host architecture? Does this ARM-targeting dmd run on ARM, or on x64 cross-compiling to ARM?

On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
>
> And there it is! Nothing else works, but what the heck.
>
> https://github.com/WalterBright/dmd/commit/04546a8f72c10a09764f23675c67c5fbdf29628c

No need to go into the woods alone.

Original work on ARM32:
https://github.com/braddr/dmd/tree/arm

Rebased against 2.076 (the C++ port):
https://github.com/ibuclaw/dmd/tree/dmd-cxx-arm

There ought to be something in there that's salvageable.

On Sunday, 2 June 2024 at 12:38:18 UTC, Iain Buclaw wrote:
> On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
>>
>> And there it is! Nothing else works, but what the heck.
>>
>> https://github.com/WalterBright/dmd/commit/04546a8f72c10a09764f23675c67c5fbdf29628c
>
> No need to go into the woods alone.
>
> Original work on ARM32:
> https://github.com/braddr/dmd/tree/arm
>
> Rebased against 2.076 (the C++ port):
> https://github.com/ibuclaw/dmd/tree/dmd-cxx-arm
>
> There ought to be something in there that's salvageable.

Amazing! Seeing dmd ARM support on Mac would be a big win!

On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
> In recent days, it has become abundantly clear that the x86 architecture appears to be headed for obsolescence. The Arm processor is taking over. The Mac is dropping the x86 in favor of Arm. Microsoft has announced Arm laptops.
>
> Even my Raspberry Pi is an Arm64.
>
> What to do about dmd? Many people in the D community have expressed interest in creating an Arm backend for D. Since implementing a 64 bit code generator is trivial, I thought I'd look into it.
>
> I bought a couple books on the Arm, and have been studying the datasheet for it. Most of the backend can be repurposed to Arm. The structure of it can remain the same.
>
> The goal is Arm64, not Arm32. Since even the Pi is Arm64, there is no purpose in supporting the Arm32.
>
> Hacking away listening to Brain Pain metal, the first function compiles:
>
> ```
> void foo() { }
> ```
>
> dmd -c test.d -vasm
>
> producing:
>
> ```
> _D4test3fooFZv:
> 0000:   D6 5F 03 C0  ret
> ```
>
> And there it is! Nothing else works, but what the heck.
>
> https://github.com/WalterBright/dmd/commit/04546a8f72c10a09764f23675c67c5fbdf29628c

https://developer.arm.com/Architectures/A64%20Instruction%20Set%20Architecture

Warning: Arm64 doesn't really exist other than as an informal name / thing apple use sometimes, aarch64 is the name you'll find in the manual, with A64 being the name of the instruction in particular (apparently, not really sure how the versioning works there)

On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
> And there it is! Nothing else works, but what the heck.
>
> https://github.com/WalterBright/dmd/commit/04546a8f72c10a09764f23675c67c5fbdf29628c

A few oddities in "arm64":

- Some arm64 archs can't represent a NaN with a negative sign. But Apple version of arm64 can.

- Floating-point to integer casting tend to clamp to min/max representable integers, when the float value exceed the integer representation. IIRC D doesn't define the maximum values for which this is a well defined operation.

- Likewise, shifting by more bits then the integer has is well defined, and doesn't work the same as in x86. So I'd say this is generally UB in D.

- Rounding a float that is exactly in the middle (such as 3.5) is a bit different than x86 IIRC, the rules are slightly different but I think this was only arm32.

- the denormal flags are one flag (instead of two in x86)

On 6/2/2024 2:56 AM, Dukc wrote:
> Question, what's the host architecture? Does this ARM-targeting dmd run on ARM, or on x64 cross-compiling to ARM?

A while back I enhanced dmd so any of its executables could generate code for any of its targets. That turned out to be very useful, so I'll continue that with Arm code generation.

On 6/2/2024 5:38 AM, Iain Buclaw wrote:
> There ought to be something in there that's salvageable.

I talked with Brad briefly about his Arm32 work before embarking on Arm64. I appreciate the efforts he put into it, and I hope I can make use of it.

On 6/2/2024 8:34 AM, max haughton wrote:
> Warning: Arm64 doesn't really exist other than as an informal name / thing apple use sometimes, aarch64 is the name you'll find in the manual, with A64 being the name of the instruction in particular (apparently, not really sure how the versioning works there)

Yeah, I did notice that there were several different monikers for the Arm64, and no clear explanation of which is preferred for what.

It continues the tradition of the equally confusing nomenclature of the the x86.