www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd Arm64 - first function compile!

reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jun 01
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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!
Jun 01
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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?
Jun 02
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 02
parent Elias (0xEAB) <desisma heidel.beer> writes:
On Sunday, 2 June 2024 at 16:39:53 UTC, Walter Bright wrote:

 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.


DMD as a cross-compiler? Sounds great!
Jun 14
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Jun 02
next sibling parent Mike Shah <mshah.475 gmail.com> writes:
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!
Jun 02
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 02
prev sibling next sibling parent reply max haughton <maxhaton gmail.com> writes:
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)
Jun 02
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 02
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
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)
Jun 02
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jun 02
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
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
Jun 02
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
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.
Jun 02
prev sibling next sibling parent reply Ben Jones <fake fake.fake> writes:
On Sunday, 2 June 2024 at 06:30:18 UTC, Walter Bright wrote:


What stuff can other contributors be helping with on this?



 Jun 03



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Jun 03



  parent reply Brad Roberts <braddr puremagic.com>  writes:


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.



 Jun 03



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


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!



 Jun 03



prev sibling next sibling parent reply Temtaime <temtaime gmail.com>  writes:


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.



 Jun 03



  parent reply ryuukk_ <ryuukk.dev gmail.com>  writes:


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



 Jun 03



 next sibling parent  Mike Parker <aldacron gmail.com>  writes:


On Monday, 3 June 2024 at 20:59:56 UTC, ryuukk_ wrote:


 This is getting tiring, you are getting tiring


Let's refrain from personal insults, please.



 Jun 03



prev sibling  parent reply Temtaime <temtaime gmail.com>  writes:


On Monday, 3 June 2024 at 20:59:56 UTC, ryuukk_ wrote:

 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


Disagreements are a natural part of any discussion, but it's 
essential to remain respectful. Resorting to insults doesn't 
contribute to a productive dialogue. I’m here to engage in a 
constructive conversation, not to spread negativity.

Regarding the core of the discussion, it's crucial to recognize 
that ARM is not poised to replace x86 entirely. The x86 
architecture remains deeply entrenched in many sectors, including 
enterprise, gaming, and high-performance computing, where its 
performance and compatibility advantages are significant. While 
ARM support is beneficial, it complements rather than replaces 
x86.

Moreover, there is a plethora of new x86 products being released 
for servers, desktops, and IoT devices, indicating that the world 
is not transitioning to ARM exclusively. Both architectures have 
their place and will continue to coexist, serving different needs 
and markets.



 Jun 04



 next sibling parent  ryuukk_ <ryuukk.dev gmail.com>  writes:


On Tuesday, 4 June 2024 at 17:44:41 UTC, Temtaime wrote:

 On Monday, 3 June 2024 at 20:59:56 UTC, ryuukk_ wrote:

 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


 Disagreements are a natural part of any discussion, but it's 
 essential to remain respectful. Resorting to insults doesn't 
 contribute to a productive dialogue. I’m here to engage in a 
 constructive conversation, not to spread negativity.


I didn't mean to sound insulting, i apologize



 Jun 04



prev sibling  parent reply max haughton <maxhaton gmail.com>  writes:


On Tuesday, 4 June 2024 at 17:44:41 UTC, Temtaime wrote:


 Regarding the core of the discussion, it's crucial to recognize 
 that ARM is not poised to replace x86 entirely. The x86 
 architecture remains deeply entrenched in many sectors, 
 including enterprise, gaming, and high-performance computing, 
 where its performance and compatibility advantages are 
 significant. While ARM support is beneficial, it complements 
 rather than replaces x86.


The only real (technical) moat that x86 has is backwards 
compatibility (and windows).

For raw performance the instruction doesn't make much difference 
(if any) other than in microbenchmarks here and there. I think 
Arm has some advantages in terms of perf/watt but I don't know 
any exact figures (e.g. the things I'm thinking of might not 
actually matter)

The best laptop processors at the moment are Apple's Arm chips, 
for example. Microsoft similarly are making another big push for 
Arm hardware at the moment.

As for HPC: Quite a few Arm supercomputers in the TOP500 these 
days (e.g. fugaku)



 Jun 04



  parent  Don Allen <donaldcallen gmail.com>  writes:


On Wednesday, 5 June 2024 at 01:41:36 UTC, max haughton wrote:

 The best laptop processors at the moment are Apple's Arm chips, 
 for example. Microsoft similarly are making another big push 
 for Arm hardware at the moment.


One small qualitative data point: I have a couple of Mac Minis, 
one with an M2 processor and the other with a 3.6 Ghz Intel I3 
processor. Same config otherwise (8MB, 256MB NVME SDD, both 
running latest MacOS version). The M2 machine is noticeably 
faster. I was surprised by how great the difference was when I 
first got it.



 Jun 05



prev sibling next sibling parent  ryuukk_ <ryuukk.dev gmail.com>  writes:


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



 Jun 03



prev sibling next sibling parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 6/2/24 08:30, Walter Bright wrote:

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


Nice!



 Jun 05



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


I've been tweeting progress reports with #AArch64 on

https://twitter.com/WalterBright



 Jun 12



  parent reply Brian Callahan <bcallah openbsd.org>  writes:


On Wednesday, 12 June 2024 at 23:07:59 UTC, Walter Bright wrote:

 I've been tweeting progress reports with #AArch64 on

 https://twitter.com/WalterBright


I'm not on Twitter so I can't see your tweets, but I can say that 
we in OpenBSD land are looking forward to aarch64 support in DMD.

~Brian



 Jun 12



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 6/12/2024 5:52 PM, Brian Callahan wrote:

 On Wednesday, 12 June 2024 at 23:07:59 UTC, Walter Bright wrote:

 I've been tweeting progress reports with #AArch64 on

 https://twitter.com/WalterBright


 
 I'm not on Twitter so I can't see your tweets,


You don't need to be on Twitter to see the tweets, just browse to that page.


 but I can say that we in OpenBSD 
 land are looking forward to aarch64 support in DMD.


And I'm looking forward to getting it done!



 Jun 12



 next sibling parent  monkyyy <crazymonkyyy gmail.com>  writes:


On Thursday, 13 June 2024 at 06:35:54 UTC, Walter Bright wrote:

 You don't need to be on Twitter to see the tweets, just browse 
 to that page.


depends on the day of the week and phase of the moon

the heavens have spoken and said "no" today



 Jun 12



prev sibling  parent reply Lance Bachmeier <no spam.net>  writes:


On Thursday, 13 June 2024 at 06:35:54 UTC, Walter Bright wrote:

 On 6/12/2024 5:52 PM, Brian Callahan wrote:

 On Wednesday, 12 June 2024 at 23:07:59 UTC, Walter Bright 
 wrote:

 I've been tweeting progress reports with #AArch64 on

 https://twitter.com/WalterBright


 
 I'm not on Twitter so I can't see your tweets,


 You don't need to be on Twitter to see the tweets, just browse 
 to that page.


That hasn't been the case for a while. If you're not logged into 
an account, all you'll see is a black page with the X logo in the 
center. You'll need to use Mastodon if you want to post things on 
social media that are accessible to everyone.



 Jun 13



  parent reply monkyyy <crazymonkyyy gmail.com>  writes:


On Friday, 14 June 2024 at 01:39:09 UTC, Lance Bachmeier wrote:

 On Thursday, 13 June 2024 at 06:35:54 UTC, Walter Bright wrote:

 On 6/12/2024 5:52 PM, Brian Callahan wrote:

 On Wednesday, 12 June 2024 at 23:07:59 UTC, Walter Bright 
 wrote:

 I've been tweeting progress reports with #AArch64 on

 https://twitter.com/WalterBright


 
 I'm not on Twitter so I can't see your tweets,


 You don't need to be on Twitter to see the tweets, just browse 
 to that page.


 That hasn't been the case for a while. If you're not logged 
 into an account, all you'll see is a black page with the X logo 
 in the center. You'll need to use Mastodon if you want to post 
 things on social media that are accessible to everyone.


Im all for mastodon, but im pretty sure its all fairly siloed



 Jun 14



  parent reply Lance Bachmeier <no spam.net>  writes:


On Saturday, 15 June 2024 at 02:20:29 UTC, monkyyy wrote:

 On Friday, 14 June 2024 at 01:39:09 UTC, Lance Bachmeier wrote:



 That hasn't been the case for a while. If you're not logged 
 into an account, all you'll see is a black page with the X 
 logo in the center. You'll need to use Mastodon if you want to 
 post things on social media that are accessible to everyone.


 Im all for mastodon, but im pretty sure its all fairly siloed


Well, one of the principles is to give users control over 
interactions, so instances can block other instances and users 
can even block entire instances as they wish.

However, anyone can read what you post if it's a publicly 
available server. Just click the link. You can even add someone's 
account to your RSS reader without having a Mastodon account.

Other social media services don't allow that AFAIK.



 Jun 14



  parent  monkyyy <crazymonkyyy gmail.com>  writes:


On Saturday, 15 June 2024 at 02:35:14 UTC, Lance Bachmeier wrote:

 On Saturday, 15 June 2024 at 02:20:29 UTC, monkyyy wrote:

 On Friday, 14 June 2024 at 01:39:09 UTC, Lance Bachmeier wrote:



 That hasn't been the case for a while. If you're not logged 
 into an account, all you'll see is a black page with the X 
 logo in the center. You'll need to use Mastodon if you want 
 to post things on social media that are accessible to 
 everyone.


 Im all for mastodon, but im pretty sure its all fairly siloed


 Well, one of the principles is to give users control over 
 interactions, so instances can block other instances and users 
 can even block entire instances as they wish.

 However, anyone can read what you post if it's a publicly 
 available server. Just click the link. You can even add 
 someone's account to your RSS reader without having a Mastodon 
 account.

 Other social media services don't allow that AFAIK.


I know nothin about protocol stuff, but my experience is that I 
once tried a generic server found it to be a political bubble and 
left; and a few years later had the thought to find a block list 
and start shopping, found mine current one and interacting with 
outside the bubble seems buggy with gaps saying "this message is 
not available", videos that dont play, images that dont load; etc.

I don't think the whole network lives up to a high "the internet 
routes around censorship" ideal the software was trying for, you 
mostly need to pick your pocket



 Jun 14



prev sibling next sibling parent  jmh530 <john.michael.hall gmail.com>  writes:


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.

 [snip]


Tweeting your regular progress on this is a good approach I 
think, even when I don't understand the significance of what 
you're saying.



 Jun 13



prev sibling  parent  Imperatorn <johan_forsberg_86 hotmail.com>  writes:


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.

 [...]


Well done 👏



 Jun 14