
The LLVM+SDCC toolchain - ingve
http://www.colecovision.eu/llvm+sdcc/
======
rkachowski
> 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

~~~
JoshTriplett
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?

~~~
astrange
cc65 does support the NES:
[https://github.com/cc65/cc65](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!

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

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

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

------
scoopr
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](https://www.youtube.com/watch?v=zBkNBP00wJE)

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

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

~~~
DannyBee
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)

~~~
greenshackle2
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?)

~~~
pcwalton
> 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));

~~~
exDM69
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).

