Hacker News Reader

Comment by hacker_homie | Hacker News Reader

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.

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.

> 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).

Might be. There certainly were bugs in my understanding of micro-controllers and compilers at the time...

EDIT: but SDCC indeed ignored 'volatile': https://sourceforge.net/p/sdcc/bugs/436/

Reply on news.ycombinator.com