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.
The PIC compiler options were never standards compliant up until around when Microchip purchased AVR. There are great chips now that have free gcc support, reasonable power draw, and 32bit float support (ATSAM3X8E current prices are not worth it in many cases.)
PIC does still have a few key use-cases, but most people will hit the stack depth limits pretty quickly in C. A pic12 Assembly project is fun, but the limitations cut deep these days.
STM32/ESP32/RP2350 or nRF for low power stuff are far less effort these days, and give much better value. =3
TIL about Dallas Semiconductor from this page.
Love Silicon Prairie lore.
SDCC has the best OSS 8051 compiler. It is buggy as hell, but it is free. Sometimes that is good enough.
I used it for some toy projects never ran into "bugs" as in this is just broken, but it's quirky for sure.
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.
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
Has worked well enough for me on 8051 and stm8
SDCC has been a nice resource for a variety of MCUs. I wish it had support for some of the 8-bit PIC chips like the PIC10 and PIC12... maybe one day!
If it has not to be SDCC, Mikroe compilers have support for them across C, BASIC and Pascal compilers, if I am not mistaken.
The PIC compiler options were never standards compliant up until around when Microchip purchased AVR. There are great chips now that have free gcc support, reasonable power draw, and 32bit float support (ATSAM3X8E current prices are not worth it in many cases.)
PIC does still have a few key use-cases, but most people will hit the stack depth limits pretty quickly in C. A pic12 Assembly project is fun, but the limitations cut deep these days.
STM32/ESP32/RP2350 or nRF for low power stuff are far less effort these days, and give much better value. =3