www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD AArch64 progress

reply Walter Bright <newshound2 digitalmars.com> writes:
I've reached the point with the AArch64 code generation that DMD should be able 
to generate working programs with it.

Since everything has to work in order to compile druntime, I am working first
on 
ImportC, which only requires the C standard library to function. I had it 
working with "hello world", a trivial program, but am now ready for more 
substantial testing.

It turns out that the D test suite doesn't have much C code in it, and does not 
have specific tests for arithmetic and other low level operations. (A lot of 
this is tested incidentally by everything else in the libraries and test
suite.) 
These tests do exist for the Digital Mars C/C++ compiler, and I relied on 
testing that compiler for that testing.

But, I am no longer building DMC++ and am not running that test suite anymore.

So I have started adding parts of the DMC test suite to the D test suite. Those 
tests date back to the 1980s, and are targeted at the 16 bit memory model, 
Windows, and obsolete C practices. The first step was to update this and get it 
to work with gcc.

Next, I needed to get it running with ImportC for x86. That blew up. It seems 
that old test suite is doing its job and detecting faults in ImportC! But my 
focus is on compiling the code with AArch64, so I'm just filing bug reports on 
ImportC to fix later.

Aaaand, I'm making progress getting the AArch64 code generator to work with the 
C test suite. A long ways to go yet.

The near term plan:

1. file ImportC bug reports on things in test/runnable/exe1.c that don't work 
for x86_64

2. get dmd to compile exe1.c for AArch64 without crashing in the code generator

3. get exe1.c to run on my Raspberry Pi

An awful lot of the code generator has to work in order for (3) to work.
Mar 07
next sibling parent reply Ben Jones <fake fake.fake> writes:
On Friday, 7 March 2025 at 17:41:13 UTC, Walter Bright wrote:

 I've reached the point with the AArch64 code generation that 
 DMD should be able to generate working programs with it.

 Since everything has to work in order to compile druntime, I am 
 working first on ImportC, which only requires the C standard 
 library to function. I had it working with "hello world", a 
 trivial program, but am now ready for more substantial testing.


Glad the work is progressing!

Why not test with D code using -betterC ?
Mar 07
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/7/2025 10:59 AM, Ben Jones wrote:

 Why not test with D code using -betterC ?


Good question!

1. I don't have to translate the code to D

2. There isn't a D compiler on my Raspberry Pi, but there is gcc, so gcc is 
useful as reference compiler

3. It exposes issues with ImportC
Mar 07
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 7 March 2025 at 20:57:19 UTC, Walter Bright wrote:

 On 3/7/2025 10:59 AM, Ben Jones wrote:

 Why not test with D code using -betterC ?


 Good question!

 1. I don't have to translate the code to D

 2. There isn't a D compiler on my Raspberry Pi, but there is 
 gcc, so gcc is useful as reference compiler


you should be able to get a GCC that includes GDC. Also LDC works 
on RasPi.
Mar 07
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/7/2025 3:00 PM, Nicholas Wilson wrote:

 you should be able to get a GCC that includes GDC. Also LDC works on RasPi.


I know. But I'm a ways from needing it.
Mar 07
prev sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Friday, 7 March 2025 at 17:41:13 UTC, Walter Bright wrote:

 
 Next, I needed to get it running with ImportC for x86. That 
 blew up. It seems that old test suite is doing its job and 
 detecting faults in ImportC! But my focus is on compiling the 
 code with AArch64, so I'm just filing bug reports on ImportC to 
 fix later.


That's impressive!

Why prioritize adapting legacy C tests over using D's `-betterC` 
mode to validate the AArch64 backend and low-level codegen?

Because risks masking AArch64-specific codegen flaws (e.g., 
register pressure, non-uniform integer widths, or C→AArch64 ABI 
mismatches) that only raw, unaltered C exercises.

Thanks...

SDB 79
Mar 07