Z80Babel: C++, D, Rust, Zig and Fortran

Página 2/4
1 | | 3 | 4

Por salutte

Master (162)

Imagen del salutte

11-02-2022, 13:49

Compiling it will takes a while. Check the pre-packaged dev environments that include the binary already compiled with the right patches applied:

https://github.com/CE-Programming/toolchain/releases

Por salutte

Master (162)

Imagen del salutte

11-02-2022, 13:53

There is some discussion about the rtlib and the builtin calls in:

https://github.com/jacobly0/llvm-project/pull/10

Por geijoenr

Champion (352)

Imagen del geijoenr

11-02-2022, 13:55

ohh, this is actually the CE Toolchain! I didn't know! Then it is definitely stable.

Por Grauw

Ascended (10633)

Imagen del Grauw

11-02-2022, 15:21

I see jacobly0’s project uses the new GlobalISel framework, that’s nice, it makes it future-proof and is something I was missing from older LLVM Z80 backend attempts.

Por salutte

Master (162)

Imagen del salutte

11-02-2022, 15:47

Could you find documentation about the calling convention?

Por Grauw

Ascended (10633)

Imagen del Grauw

11-02-2022, 16:07

Should be completely described by the TableGen definition in Z80CallingConv.td (see also here).

Por salutte

Master (162)

Imagen del salutte

12-02-2022, 16:23

Thanks! Checking this files I confirmed that it uses the stack to pass arguments, expanding 8 bit parameters to 16 bit.

I used this knowledge to manually convert the assembler generated for the Sieve benchmark by the llvm-z80 to the sdcc calling convention, add the required extra libraries, and benchmark it.

When using the __smulu call:
CLANG frontend + LLVM-Z80 backend:
Delay: 367 ms
Size: 260 bytes ( not including the size of the __smulu function)

When inlining the "n*3" manually:
CLANG frontend + LLVM-Z80 backend:
Delay: 320 ms
Size: 261 bytes

As a reference, for the same function:
SDCC:
Delay: 324 ms
Size: 210 bytes

CLANG as front end + SDCC as back end:
Delay: 287 ms
Size: 196 bytes

I don't really see a lot of potential to improve the code generation performance of the llvm-z80 backend without a significant overhaul of the current code, and given the current issues, I don't find it worth the effort to migrate from the sdcc backend for the moment.

But it sucks missing the ability to pass structs by value, and the super long compilation times of SDCC are also a pity.

Por geijoenr

Champion (352)

Imagen del geijoenr

14-02-2022, 14:23

I also looked a bit into this. The changes from Jacob cover only llvm and clang, but neither the assembler nor the linker. Even though is quite an achievement to generate z80 code, without assembler or linker the outcome is a bit limited. There is not relocatable binary output, no elf files, and no linking as part of llvm for (e)z80.

To solve this he put together an assembler and linker using fasmg, in just 3k lines of configuration code. I haven't gone through it in detail yet, the assembler can be switched to z80 easily by swapping the configuration, but the linker is more difficult and is probably targeted at eZ80 and TI devices.

Very interesting stuff anyways.

Por Grauw

Ascended (10633)

Imagen del Grauw

14-02-2022, 14:33

Interesting, I did have the assembler and linker working iirc (ended in the middle of code generation), though only for Z80 of course and I’m not very familiar with eZ80 (probably it makes things more complicated). Maybe I can find some time to dig up the code and see if our approach was similar and whether I’m able to merge it.

Por Giangiacomo Zaffini 2

Champion (274)

Imagen del Giangiacomo Zaffini 2

14-02-2022, 20:19

Since this thread has broaden its discussion already, I would like to reference COCOACRUMBS's Clang/LLVM + Gnu binutils targetting (e)Z80.

Página 2/4
1 | | 3 | 4