The LLVM+SDCC toolchain | Hacker News Reader

The LLVM+SDCC toolchain

colecovision.eu

75 pointsingve22 comments

> Currently only stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 SDCC backends supported

this is pretty cool... the gameboy (gbz80) processor is supported. now we can make late 80s gameboy roms on any 2016 llvm supported language

I'd love to see support for the 65c816/5A22, to allow targeting the SNES. Anyone know of Open Source compilers targeting that family of processors?

cc65 does support the NES: https://github.com/cc65/cc65

It might have an SNES mode too. Note that even the 65c816 isn't good enough to run most C and your "portable" C code probably isn't portable if int isn't 32 bits anymore!

Doesn't look like it covers the SNES, unfortunately, but NES support helps.

Rust recently gained support for systems with 16-bit integers and pointers, in order to support AVR. It'd be challenging, and some of the libraries might not work out of the box, but it's worth a shot.

The much harder part would be supporting various memory windowing techniques.

> Note that even the 65c816 isn't good enough to run most C

At least they added stack-relative addressing, which is a huge improvement over the 6502.

I wrote a gameboy game using the (old) SDCC that ships with the (old) GBDK, and ran into countless issues with what i assume was the C frontend.

Rearrange functions in source file? ICE!

Reorder variable definitions? ICE!

It was very cool to end up with a working .gb rom but the process was not a great experience. Hopefully this addresses some of the compiler reliability.

EDIT: play my crappy game https://code.ivysaur.me/shmup/

Well, this is one way of going about it.

I have been mulling over the idea of adding backends for the various 8bit and 16bit microprocessors directly to llvm.

I was thinking the same, but seeing some semi-abandoned projects, plus some comments saying llvm is not very suited for those kind of processors, never gave me the incentive to try and go trough with it...

"adding a Z80 backend to LLVM" just came up on the mailing list and someone responded with a link to LLVM+SDCC and someone else chimed in on the list with this page about using the LLVM C backend.

I know that an AVR backend end has been in the works for quite a while but I haven't checked the status lately.

AVR is a little unusual amongst 8-bit architectures in that it was designed from the ground up to support C cleanly - it's possibly the world's only 8-bit RISC CPU. As far as I know it's also the only 8-bit architecture officially supported by gcc for the same reason.

Work is still ongoing. I think it's in the process of being upstreamed.

> Well, this is one way of going about it.

It's honestly probably the best way of going about it. The target-independent backend in LLVM really isn't designed for these kinds of architectures. When you have pointers that don't fit in registers, an extremely register-starved architecture (6502), crippled "index registers", no stack-relative addressing, a tiny stack, odd concepts like zero-page, etc. then most of LLVM's codegen infrastructure isn't applicable.

I'm sure it's technically possible to slot some kind of 8-bit codegen into the framework, but the fact that it's been tried many times and hasn't succeeded indicates to me that it's just not worth it. It seems a lot easier to just write a custom code generator that lowers LLVM IR to the target with its own mechanisms, and using the SDCC backend is likely as reasonable a choice as any other.

It's a bit of a problem - some of these architectures (8051 I'm looking at you) have multiple address spaces, some with 16-bit pointers, some with 8-bit ones - 8051 SDCC supports 24-bit generic pointers with embedded tags saying which address space is being pointed at, you can also mark variables with explicit address space tags:

    packet __xdata  * __data rx_packet;

a pointer to (16-bit addresses) external data space stored in (8-bit addressed) local data space. Any useful compiler for an 8051 is going to need these SDCC extensions

I'm having hard time deciding if this is a cleaner approach than converting subset of x86 asm to 6502 asm[0]. The reassembler seems like it has smaller surface area to worry, more rigid semantics, but then again it is very platform specific..

[0] https://www.youtube.com/watch?v=zBkNBP00wJE

for non compiler experts, how does llvm decouple a language from a target machine?

LLVM specifies another "language", the LLVM intermediate representation (IR) which is easy to generate by a compiler frontend and suitable for running optimizations in, and then compile on to the target architecture. It's a bit like an assembly language with infinite registers and explicit control flow.

E.g. Clang front end reads C code and emits LLVM IR. The LLVM backend (llvm-as) then reads the IR and generates target machine code.

It's important to note, however, that while LLVM IR is language and target independent, a lot of languages themselves are not target independent.

IE LLVM does not make C magically portable, because C requires and creates target-specific information (for example sizeof).

To give a simple example, you can't take:

  int *foo;
  printf("%d\n", sizeof(foo))

Compile it on a 16 bit platform to llvm bitcode and then run compile/run the llvm bitcode on a 64 bit platform, and get the right answer for that platform, and llvm can't solve this.

The long story on this one is that it's basically not possible to even just move this stuff to dynamic evaluation in a frontend because you can depend on target specific things in the preprocessor, IIRC. Otherwise, you could, but it'd generate super-slow code unless you built llvm intrinsics for all these things, and then lowered them once you had target specific info.

I believe TeNDRA and friends could do this at one point, but i might be misremembering (i've deliberately blocked most of my knowledge of ANDF)

> The long story on this one is that it's basically not possible to even just move this stuff to dynamic evaluation in a frontend because you can depend on target specific things in the preprocessor, IIRC.

Well, unless you go the whole way and interpret the language itself like CINT :)

Just so I understand, the problem is that compiling this code on a 16 bit vs 64 bit platform will produce different IR code?

The IR code itself is "portable", but the C to IR compiler is using target specific information?

(I've just been learning about assemblers and compilers, still trying to wrap my mind around this stuff. Would there be much educational value in writing IR code by hand?)

> The IR code itself is "portable", but the C to IR compiler is using target specific information?

Right. Consider how you'd compile something as simple as printf("%d", (int)sizeof(int));

The point still stands, but I think sizeof(int*) or sizeof(int) is a poor example, because it could be compiled to a portable "getelementptr" LLVM instruction.

However, Clang does not do this and emits a constant integer for sizeof() operations (according to my quick and dirty test).

Reply on news.ycombinator.com