Compiler Comparison
RTOS Availability



LED Timer


LED Timer


STM8AF Serial
STM8AF Dhry. Whet.
STM8AL Serial


LED Timer
Dhrystone Whetstone


LED Timer
Dhrystone Whetstone


LED Timer


LED Timer
Dhrystone Whetstone








A comparison of C compilers targeting the STM8

This is a comparison of currently (mid-2016) available C implementations targeting the STM8. The author is a SDCC user and developer, but tried to do an objective comparison here.

The Compilers

There are currently multiple C implementations targeting the STM8:

There are two more: "ST8CC" and "SDCC for ST7, STM8". Neither has been included in the comparison. "ST8CC" seems rather incomplete and does not run under current operating systems. "SDCC for ST7, STM8" is an umaintained fork of an old SDCC version.

Standard Compliance

The input language to be accepted by C compilers is defined by international standards, with the ANSI C89/ISO C90, ISO C99 and ISO C11 being the most important.

No current compiler targeting the STM8 fully supports any of the standards. However all of the compilers at least support large subsets of some standards. They also offer some extensions to the standard, e.g. for I/O. SDCC and IAR implement these extensions in a standard-conforming way (using identifiers prefixed by two underscores).

In general, SDCC and IAR are ahead of the competition in standard-compliance. Raisonance don't make much effort to support standards beyond C90. Cosmic has a somewhat incomplete C99 mode (compiler option -pc99, not directly exposed in the IDE). All compilers offer a decent C90 mode. While the C99 mode of IAR is more complete than the SDCC and Cosmic ones, SDCC is the only compiler with a C11 mode.


This is also reflected in the data types supported by the compilers. Even though all the standards require the data types double and long double, none of the compilers support it. Some compilers instead offer non-standard versions of these types with reduced precision (essentially using float in place of double and long double). Cosmic and Raisonance both offer a non-standard boolean data type, where pointers and arrays are not allowed. For Raisonance, boolean variables have to be global. In Raisonance, the size of bitfields is limited to 8 bits (the lowest limit allowed by the standards is 16 bits).

boolcharshortintlonglong longfloatdoublelong double

Code Quality

Three important aspects of code quality are correctness, size and performance. The latter two can be assessed using benchmarks. Three classic benchmarks suitable for small devices were used:

The benchmarks were build with the different optimizing compilers with various optimization settings, and executed on an STM8AF5288 on the STM8A-DISCOVERY evaluation board. For the Cosmic compiler, +modsl0 was used to specify ≤64K code size, with corresponds to the default settings of the other compilers. The benchmark results were output via the printf from the implementation and a custom putchar() onto an UART. For SDCC, Dhrystone and Whetstone sources from the tutorial were used directly, for the others, they were modified as necessary to make them compile (the modifications did not affect correctness or score; for most compilers they were limited to adding typedefs and making putchar work with the implementation; for Raisonance it was also necessary to rename variables as data is a keyword there, and make Coremark use global instead of local storage, since Raisonance does not support more than 256 bytes of local variables per function). The compilers were run on Debian GNU/Linux (for SDCC) or Windows 7 (others). The resulting executable was transferred onto the board via the tools that came with the compiler on Windows 7 (IAR) or via stm8flash on Debian GNU/Linux (others).

For correctness, SDCC is build each night on different OSes, and then the regression test suite is compiled and executed on simulators. Besides SDCC-specific tests, the regression test suite also contains most of the tests from GCC. This testing process gives some confidence in the correctness of the code generated by SDCC. Dhrystone and Coremark have an internal mechanism for verifying correct operation; the verification passed for all except Dhrystone with Cosmic. The C standard requires that variable arguments smaller than int are converted to int on function calls. Cosmic omits those casts to int, which results in the Dhrystone self-test failing.

Scores for benchmarks

Whetstone scores vary widely between the compilers, with SDCC performing worst. Whetstone scores mostly depend on the quality of the floating-point implementation and the floating-point library functions. Most software for embedded systems does not use floating-point arithmetic. The scores reported here are not comparable to Whetstone scores for other architectures / compilers, since the compilers targeting the STM8 currently do not support double and thus use reduced precision.

With Dhrystone we see a bit less of variation. Cosmic and Raisonance deliver the 0.29 DMIPS / MHz mentioned in STM8 marketing material. SDCC only achieves 0.17 DMIPS / MHz. On the other hand, IAR even achieves 0.35 DMIPS / MHz when optimizing for speed. Dhrystone mostly depend on the quality of string library functions, and code generation for 16-bit integer operations. Both are frequently found in software for embedded systems.

Coremark scores are quite similar among the compilers, however IAR with optimization for speed outperforms all others, while Raisonance and IAR generate rather slow code when optimizing for code size. Coremark scores mostly depend on the code generation for 16-bit and 32-bit integers and are not affected much by library functions.

The results indicate that all compilers generate code of reasonable quality. Most differences in the scores can be explained by how much effort went into optimizing the library functions that come with the compilers for the STM8. In general, code generated by IAR optimizing for code speed is the fastest.

Code sizes for benchmarks

The results for code size do not vary as much as the benchmark scores. In general, we see Raisonance doing best, with Cosmic second, then SDCC and IAR last. Apparently the great code speed that IAR can achieve comes at a substantial price in code size.

OS support

SDCC is available for a wide range of operating systems, and for some of them is even part of standard distributions. Cosmic is available for Windows, Linux, Solaris, HP-UX. The other compilers are Windows only.

LinuxWindowsMac OS XNetBSDSolarisFreeBSDOpenBSDHurdHP-UX


SDCC is free software under the GPL., ensuring continued availability. For the other compilers, available licenses can change. For Cosmic, 1-year licenses for Windows became available at no cost this year (a version limited to a code size of 32KB was available before). For Raisonance and IAR, there currently are 30 days evaluation licenses available at no cost. Alternatively, IAR also offers a time-unlimited evaluation version limited to a code size of 8 KB. Raisonance used to offer time-unlimited evaluation versions limited to a code size of 16KB. There is a time-unlimited evaluation version of Raisonance limited to a code size of 2KB included when buying RLink hardware.

CosmicFreeware (Windows only)
Raisonance30 days evaluation
IAR30 days evaluation


Summarizing the results from the sections above, we see that all compilers have their strengths and weaknesses. Cosmic gives a good balance of code speed and size. SDCC has great standard compliance, and wins on the OS support and license. Raisonance is best on code size. IAR delivers good standard compliance and the best code speed.

Standard ComplianceCode SpeedCode SizeOS SupportLicense