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 (early 2018) available C implementations targeting the STM8. The author is a SDCC user and developer, but tried to do an objective comparison here. This page might get updated as new information becomes available (i.e. in case there are changes between SDCC 3.7.0 RC1 and the final 3.7.0 release or when obtaining a current Raisonance evaluation license). There is also a similar comparison from 2016, and a summary of the changes from mid-2016 to early 2018.

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 unmaintained 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 only supports a few select keywords 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 bit-fields 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, which corresponds to the default settings of the other compilers. For IAR, which has an inlining heuristic, inlining was disabled for Dhrystone regardless of optimization goal (as required by the official rules for the Dhrystone benchmark). The benchmark results were output via the printf from the implementation and a custom putchar() onto an UART. For all compiler except Raisonance, Dhrystone and Whetstone sources from the tutorial were used directly. Raisonance required various modifications (the modifications did not affect correctness or score; they consisted of adding typedefs, renaming variables as data is a keyword for Raisonance, 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 stm8flash on Debian GNU/Linux.

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. IAR only achieves 0.25 DMIPS / MHz (a regression, older versions achieved 0.35 DMIPS / Mhz). On the other hand, SDCC even achieves 0.37 DMIPS / MHz when optimizing for speed. Dhrystone mostly depends 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 vary substantially among the compilers; IAR with optimization for speed performs quite well, while Raisonance and IAR generate rather slow code when optimizing for code size. SDCC outperforms all other compilers. 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 quite good, but with the exception of floating-point SDCC generates the fastest code.

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 and SDCC second, then 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, GNU/Linux, Solaris, HP-UX. The other compilers are Windows only.



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 are available at not cost (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 code speed, OS support and the license. Raisonance is best on code size. IAR delivers good standard compliance and good code speed. However, since SDCC improved substantially since 2016, the situation is now less balanced than it was then. While Raisonance still generates the smallest code, and SDCC generates the slowest floating-point code, SDCC is now on-par or ahead of the other compilers in nearly all aspects.

Standard ComplianceCode SpeedCode SizeOS SupportLicense