The LLVM+SDCC toolchain and its potential uses
The LLVM+SDCC toolchain is meant to allow the use of languages other than C and to evaluate the effect of LLVM optimizations for 8-bit targets. Currently, it consists of a fork of the LLVM C frontend (cfe) clang, the LLVM optimizer (optional), the LLVM C backend (cbe; no longer part of LLVM, now maintained independently from LLVM). and the Small Device C Compiler (SDCC). he toolchain is still in a very early stage and likely has many issues, especially around corner cases.
Installing the LLVM+SDCC toolchain
Using the LLVM+SDCC toolchain
To compile a test.c C file with it for STM8:
- Compile C source to LLVM IR:
clang/build/bin/clang -fno-signed-char -target sdcc-stm8 -S -emit-llvm -isystem /usr/local/share/sdcc/include test.c(you might want to change the include path depending on where your SDCC header files are installed). This should give you atest.llfile - Compile LLVM IR to C:
llvm-cbe/bin/llvm-cbe test.ll. This should give you atest.cbe.cfile. - Compile to binary:
sdcc -msmt8 test.cbe.c.
The above process should result in a working binary file just as if the original C file had been compiled with SDCC directly. However the binary will probably be less optimized as SDCC is not yet able to optimize out all the overhead generated in the translations. But if you optimize the LLVM IR before converting it to C, you might well get a more optimized result than with plain SDCC. To optimize, use e.g. opt-3.8 -O2 -disable-simplify-libcalls -S (we need -disable-simplify-libcalls since for opt-3.8, sdcc-stm8 is an unknown target triple, so it assumes the host architecture; this breaks the simplification of libcalls, since e.g. some printf() calls get converted to putchar(), but we get a putchar() that takes a 32-bit int; this would result in stack corruption later).
The files compiled using the above process can be freely linked with files compiled using SDCC directly.
Known issues
- No support for SDCC extensions in the cfe
- Probably different compiler-defined behaviour in some corner cases
- No support for some features that are not supported by SDCC (most prominently variable-length arrays and
alloca()) - Currently only stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 SDCC backends supported
- Support for languages other than C is untested
- Floating-point support is untested
- SDCC emits function definitions for
static inlinefunctions even when all uses are inlines, resulting in larger-than-necessary code size - There is a bug in the handling of
volatilein the cbe