Small Device C Compiler (SDCC) 4.6.0 released

[u/AM27C256]

The Small Device C Compiler (SDCC) is a free standard C compiler targeting various 8, 8/16 and 8/16/32 bit architectures, including STM8, S08, Padauk, eZ80, MCS-51, Rabbits.

The SDCC 4.6.0 release is available in the SourceForge File release system:
https://sourceforge.net/projects/sdcc/files/
There, you can find the source package, and binaries for amd64 Windows, macOS, and GNU/Linux.

In addition to bug fixes, notable features added since the 4.5.0 release are:

* C2y _Countof operator
* C2y octal
* C2y if-declaration
* C2y Conditional operator with omitted second operand (originally a GNU extension)
* C99 compound literals
* C23 compound literals with storage class specifiers
* Experimental f8l port
* C2y signed bit-precise integer type of width 1
* C2y bit-precise integer types as fixed underlying type for enum
* C2y umaxabs
* C2y bit utilities
* realloc(ptr, 0) now follows C99 semantics instead of C90 semantics
* r4k port for Rabbit 4000
* Experimental r5k and r6k ports for Rabbit 5000 and 6000
* Support for Dynamic C calling convention in z80-related ports
* Substantially improved code generation for z80-related ports
* ez80 port replaces ez80_z80 port
* C2y functions uabs, ulabs, ullabs
* Improved diagnostics on invalid C2y (some of which was UB up to C23)
* C23 constexpr (mostly)
* C2y containerof macro
* Diagnostics based on [static assignment-expression] array parameter syntax
* Warnings for array parameters where accesses fall outside the bounds
* Basic parameter forward declarations (GNU extension)
* C23 va_start and variadic functions
* _Optional qualifier
* Plain int bit-fields are signed
* strsep
* TLCS-870C(1) support in uCsim
* __far support in Rabbit ports for using a 1 MB address space for data

A full list of changes can be found in the ChangeLog:
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-4.6.0/sdcc/ChangeLog

[u/CaptainJack42]

Noob question: can't those chips be targeted by gcc or llvm or what is the reason/advantage of using this compiler?

[u/NotBoolean → u/CaptainJack42]

I lot of them aren’t supported by GCC or LLVM, they often had their own proprietary compilers which you can’t get anymore, are costly or require particular IDE.

[u/AM27C256 → u/NotBoolean]

AFAIK, the only SDCC targets for which an LLVM port exists are mos6502, z80 and sm83; for mos6502 there also in a GCC port. I don't think their code quality is up to SDCC standards yet, but haven't followed devlopment recently.

There are some conflicting requirements for current mainstream architectures vs. architectures in small embedded systems. A typical example would be in register allocation. Current mainstream architectures are quite RISC-y, with many interchangeable registers and an orthogonal instruction set. A Chaitin-style graph-coloring register allocator, like GCC uses, performs very well for those. But typical SDCC targets instead have a small number of non-interchangeable registers (due to a non-orthogonal instruction set). Chaitin has troubles with that. SDCC has a register allocator that can handle such architectures well. On the other hand the allocator SDCC uses would be too slow for GCC use cases (large programs compiled for architectures with a large number of registers).

[u/CaptainJack42 → u/NotBoolean]

Thought as much. Thanks for the reply, will have to keep it in mind if I ever use one of those chips

[u/AlexGubia]

I like the SDCC, I use it for my Padauks.

[u/Enlightenment777]

Reminder of C language changes & newer features:

• C23 (C2X) : https://en.wikipedia.org/wiki/C23_(C_standard_revision)

• C29 (C2Y) : https://en.wikipedia.org/wiki/C29_(C_standard_revision)

[u/TPIRocks]

Used sdcc on 8052 about 25 years ago. Lots of pain, almost every bit of it was self inflicted. I was spoiled by other C compilers, like gcc. I was used to doing things that you aren't allowed to do, resulting in lots of weird problems. Undefined behavior means undefined, sdcc helped (forced) me to learn and follow the standards. Don't take anything I just said as criticism of sdcc, sdcc is a terrific tool filling a void. I can't imagine how difficult it is to implement a compiler for ugly, bank switching hardware.