uc80 - New Z80 super optimizing C compiler

[aaron wohl]

The Fujitsu test suite produces code on average 46% smaller than z88dk.
Implements C99/C11/C24 (no VLA, _Complex, threads)
Targets CP/M
Global optimization across multiple .c files
https://github.com/avwohl/uc80

[Aleksandr Sharikhin (Nihirash)]

Did you tried it with some real-world apps?

Can it build Petit FatFS, UZIX core(for example) or some not only hello-world apps?

Is it usable outside CP/M target? 

пятница, 13 марта 2026 г. в 03:40:32 UTC+1, aaron wohl:

[7alken]

hi, umm, I tried it with my tiny incomplete vmex here ... https://github.com/apws/230326-VMEX
(source may be intentionally nonconventional probably, single vmex.c and more included .h files, but it was already tested on many compilers) ...having this result:

v:\~prj\230326-VMEX\build\stdio-desktop\retro\cpm\z80-uc80-test>uc80 ..\..\..\..\..\src\vmex.c -o vmex.mac
uc80: ..\..\..\..\..\src\vmex.c:678:5: Expected SEMICOLON

... so it fails even at parsing? ... and I know that my simple source  (still manually composed with very early parts drafted) CAN have some weirdos inside ... but elsewhere it is okay :)
(more focus for many months on hw, expecting inevitable tectonic shifts in sw, so ... observing also codex now, last week and month was quite drastic)

using this:
set SRC=..\..\..\..\..\src

uc80 %SRC%\vmex.c -o vmex.mac
um80 vmex.mac -o vmex.rel
ul80 vmex.rel lib/libc.lib lib/runtime.lib -o vmex.com

(... z88dk - size of cpm com is 20kB)

btw, hope some recent enhancements related to LLM aren't causes of retrobrewcomputing and tindie issues, even many bad guys probably use locals with qwen or so ... grrr 

Petr

[Phillip Stevens]

Good to see a new optimising C compiler. The results look truely impressive.

The Fujitsu test suite produces code on average 46% smaller than z88dk.

Looking at your benchmarking, I would say there’s a few things to consider.

1. You’ve restricted sdcc to use a minimum number of allocation nodes. Using only 10,000 is equivalent to racing against a  Lamborghini stuck in 1st Gear. Yes, that’s sufficient to allow completion of many complex functions, but it is far from optimal. For z88dk benchmarking we usually use 300,000, where compilation starts to approach the best available outcome.

2. The standard startup crt0, library, and command line handling provided with z88dk require attaching file support library code and stdio library code into a hello world program. Some of this can be removed by specifying ndos and no stdio.

3. If the compiler testing is using print functions, I’d note that the z88dk standard library includes many printf format converters by default, which leads to larger than necessary binaries. Usually, the programmer will issue a #pragma to tune the format converters to only those actually needed (or to add those omitted by default). 

Implements C99/C11/C24 (no VLA, _Complex, threads)
Targets CP/M
Global optimization across multiple .c files
https://github.com/avwohl/uc80

I note there is extensive use of static variables in the compiler libraries, even for simple things like 32-bit arithmetic. That is very problematic in C, because it breaks the implied reentrancy of functions. It will be impossible to run a simple recursive fibonacci function, for example, as the addition function is non-reentrant. Most compilers and libraries use stack variables (unless explicitly declared static) with C, because of exactly this issue. That is an architecture decision you could reconsider.

Cheers, Phillip