On 6/2/2024 9:15 AM, Guillaume Piolat wrote:
> 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)

I didn't know this. The D Arm floating point is going to do what the native hardware does.

On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
> it has become abundantly clear that the x86 architecture appears to be headed for obsolescence. The Arm processor is taking over.

Is this clear? 95% market share in a slow moving space; id bet 40 years

Once I was looking into getting it done, but every time I had to realize it was way out of scope of my capabilities.

Once it's feasible enough, I'll be testing my libraries with DMD too on my Raspberry Pi, even though there's only a minimal difference between ARM and x86-64 once properly compiled. Biggest one boils down to vector optimizations, which is likely a quirk of LDC2.

On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
>

What stuff can other contributors be helping with on this?

On 6/3/2024 9:41 AM, Ben Jones wrote:
> On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
>>
> 
> What stuff can other contributors be helping with on this?
> 

1. add floating point instructions, SIMD, SVE and SME instructions to the disasmarm.d. It only currently does the Base Instructions.

http://www.scs.stanford.edu/~zyedidia/arm64/index.html


2. using the Gnu assembler, `as`, write an example of every instruction. Collect the binary hex emitted, and add them as unit tests to the disassembler.


3. write an inline assembler. Much like the arm disassembler, this will be totally different from the way the x86 assembler works. I suggest making it work analogously to the way disasmarm.d works. The list of instructions written for (2) can be reused as the test suite for it.


With the disassembler verified against `as`, and the inline assembler verified against the disassembler, then the instructions generated by the compiler can be much more easily verified.

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

Adding new features is always exciting, but it is crucial to ensure that these features are fully developed and bring real value to the users. Incomplete features can lead to confusion and frustration, ultimately hindering productivity rather than enhancing it.

I would like to urge the development team to reconsider the current strategy and prioritize the completion and perfection of existing features before introducing new ones. By doing so, we can ensure a more robust, reliable, and user-friendly programming language.

GDC and LDC already support arm and optimize the code perfectly.
Instead of introducing yet another redundant feature, I believe our focus should be on refining and optimizing the existing ones. This approach would not only enhance the stability of our language but also improve the overall user experience.

On 6/3/2024 11:38 AM, Walter Bright via Digitalmars-d wrote:
> On 6/3/2024 9:41 AM, Ben Jones wrote:
>> On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:
>>>
>>
>> What stuff can other contributors be helping with on this?
>>
> 
> 1. add floating point instructions, SIMD, SVE and SME instructions to the disasmarm.d. It only currently does the Base Instructions.
> 
> http://www.scs.stanford.edu/~zyedidia/arm64/index.html
> 
> 
> 2. using the Gnu assembler, `as`, write an example of every instruction. Collect the binary hex emitted, and add them as unit tests to the disassembler.
> 
> 
> 3. write an inline assembler. Much like the arm disassembler, this will be totally different from the way the x86 assembler works. I suggest making it work analogously to the way disasmarm.d works. The list of instructions written for (2) can be reused as the test suite for it.
> 
> 
> With the disassembler verified against `as`, and the inline assembler verified against the disassembler, then the instructions generated by the compiler can be much more easily verified.

You mean something like:

https://github.com/braddr/dmd/blob/arm/test/compilable/arm_iasm.d
https://github.com/braddr/dmd/blob/arm/src/iasm_arm.c

They only cover a subset of the instructions based on an older version of the instruction set, but that still covers probably 90% of both assembly and tests.  It doesn't cover disassembly, as I just used objdump from the standard gnu dev tool set.

On Monday, 3 June 2024 at 18:58:48 UTC, Temtaime wrote:
> 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
>
> Adding new features is always exciting, but it is crucial to ensure that these features are fully developed and bring real value to the users. Incomplete features can lead to confusion and frustration, ultimately hindering productivity rather than enhancing it.
>
> I would like to urge the development team to reconsider the current strategy and prioritize the completion and perfection of existing features before introducing new ones. By doing so, we can ensure a more robust, reliable, and user-friendly programming language.

This is getting tiring, you are getting tiring

If you don't understand the value, refrain from posting negativity

If you have an issue from the tracker that requires more attention, create a separate thread and discuss there instead of spamming here

People are free to explore new things, programming should not be a monotonous task that only slaves do

Having ARM support means one can keep working on the language in a world that is transitioning to ARM, perhaps not for everyone, but totally for consumer PCs

It is also an opportunity to look at old code and perhaps reorganize things and perhaps solve long standing issues along the way, it can only be useful


DMD is a strength many languages doesn't have

- VERY fast

- good enough performance

- free from LLVM

Having ARM means staying relevant, attracts people interested in ARM and more importantly promotes the language, no language is bug free, but that shouldn't detract us from moving forward instead of decaying and dying

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

Thanks for caring about ARM, DMD is what got me hooked with D, knowing it'll remain future proof is super important to me

On 6/3/2024 1:40 PM, Brad Roberts wrote:
> You mean something like:
> 
> https://github.com/braddr/dmd/blob/arm/test/compilable/arm_iasm.d
> https://github.com/braddr/dmd/blob/arm/src/iasm_arm.c
> 
> They only cover a subset of the instructions based on an older version of the instruction set, but that still covers probably 90% of both assembly and tests.  It doesn't cover disassembly, as I just used objdump from the standard gnu dev tool set.

Yes, please!