I used sdcc for an 8051 based commercial project a while back. I seem to remember spending more time reading the assembly to figure out workarounds for the compiler than actually writing C code!
Whereas sdcc works brilliantly for z80 lineage processors. I wrote quite a lot of C for Gameboy recently and didn't find a single compiler bug in sdcc which revised my opinion of it upwards greatly.
Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)
But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)
when you have large code, bugs will find you. for example two uint16 vars globally declared one after another. adding them together to each other will produce an access to garbage memory after 5-6 additions. dumb code but a simple repro. i ran into its bug when working on eInk price tags a while back.
As a student, 20 years ago, I felt like I was going crazy when using SDCC for pic16. Being new to microcontrollers and C, SDCC seemed cursed - even simple 'blink LED' test cases pseudo-randomly worked or didn't. It turned out that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins. These bugs have long been fixed but still live on in my long-term memory.
I still run across this to this day with GCC and Cortex-M code. The optimizer will occasionally decide to blow away loops that are clearly doing something.
What a coincidence, just yesterday I asked an LLM to generate a C compiler for the 8051 because SDCC's output was not optimized.
Within an 1.5 hour it was correctly compiling my project at 60% of the size of what SDCC generates.
One or 2 quota refreshes later it passed the SDCC test suite and optimized soft floats.
I assume you're running that test suite using a 3rd party 8051 emulator to avoid the potential for common-mode errors in both your compiler and emulator resulting in false confidence the compiler's correctness?
> two simulators used for testing, sim51 (a plain 8051) and minitel_sim
I used sdcc for an 8051 based commercial project a while back. I seem to remember spending more time reading the assembly to figure out workarounds for the compiler than actually writing C code!
Whereas sdcc works brilliantly for z80 lineage processors. I wrote quite a lot of C for Gameboy recently and didn't find a single compiler bug in sdcc which revised my opinion of it upwards greatly.
I used it for some toy projects never ran into "bugs" as in this is just broken, but it's quirky for sure.
Slightly larger switch() statement and you'll run into peephole optimizer just eating away at jump target instructions without telling the jumper to adapt the destination address for the case. Of course the result is completely random code execution. Things like that. :)
But I wrote non-trivial code with sdcc regardless. My favorite 8051 targets are FX2LP USB boards from aliexpress. :)
when you have large code, bugs will find you. for example two uint16 vars globally declared one after another. adding them together to each other will produce an access to garbage memory after 5-6 additions. dumb code but a simple repro. i ran into its bug when working on eInk price tags a while back.
As a student, 20 years ago, I felt like I was going crazy when using SDCC for pic16. Being new to microcontrollers and C, SDCC seemed cursed - even simple 'blink LED' test cases pseudo-randomly worked or didn't. It turned out that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins. These bugs have long been fixed but still live on in my long-term memory.
> that the compiler optimized away some 'empty' loops a little bit too aggressively without realizing that these loops were setting output pins.
Doesn't sounds like a bug in the compiler, sounds more like `volatile` was not used (unless, of course, `volatile` was not being honoured).
I still run across this to this day with GCC and Cortex-M code. The optimizer will occasionally decide to blow away loops that are clearly doing something.
Please file a bug report, if you haven't done so.
What a coincidence, just yesterday I asked an LLM to generate a C compiler for the 8051 because SDCC's output was not optimized. Within an 1.5 hour it was correctly compiling my project at 60% of the size of what SDCC generates. One or 2 quota refreshes later it passed the SDCC test suite and optimized soft floats.
https://github.com/jyaif/cc51
I assume you're running that test suite using a 3rd party 8051 emulator to avoid the potential for common-mode errors in both your compiler and emulator resulting in false confidence the compiler's correctness?
> two simulators used for testing, sim51 (a plain 8051) and minitel_sim
Narrator: No, he was not.
"it runs on my device" is my criteria of success here