7 ms·

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.

by phire 10y ago

Sephiroth87 10y ago
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...
- wyldfire 10y ago
  "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.
dbcurtis 10y ago
I know that an AVR backend end has been in the works for quite a while but I haven't checked the status lately.
- makomk 10y ago
  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.
- mastax 10y ago
  Work is still ongoing. I think it's in the process of being upstreamed.
pcwalton 10y ago
> 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.
Taniwha 10y ago
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

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.

by phire 10y ago

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.

Sephiroth87 10y ago

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

wyldfire 10y ago
"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.

dbcurtis 10y ago

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

makomk 10y ago
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.
mastax 10y ago
Work is still ongoing. I think it's in the process of being upstreamed.

pcwalton 10y ago

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

Taniwha 10y ago

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