This is something that has bugged me ever since I first had the misfortune of using a 'C' compiler for a PIC micro many years ago. Basically, they're all crap.
I tried many different makes of 'C' compiler and I could make them generate broken code rather two easily, it didn't seem to make a difference if the compiler vendor was an independent company or the chip manufacturer, I found myself having to hand hold the compiler to make sure it generated working code. I spent a lot of time double checking the resulting assembler to make sure that it was doing what it should be.
Fast forward to this week, we've replaced an off the shelf IC with an MSP running code to do the same job, in fact it's better because it can do a couple of other things and doesn't need extra transistors to handle some inversions. Great.
So I had code up and running on it, but then when I switched to release code it stopped working, so off I went into the assembler to find out why it was hanging....and there it was:
volatile int *a;
void f()
{
int *b;
....
while(a!=b)
while(a==b)
....
}
This might look odd, but it's some code to make sure that a timer isn't operating on a value so that code outside can change it. (it's not my code and at first glance it doesn't seem very elegant, but it's a solution to a slightly tricky problem).
Basically, b is a pointer to a linked list entry and a is pointer to the current entry being used by the timer. Function f changes the linked list, so you have to be careful you don't change it while in use by the timer.
Now, because a is declared as volatile the compiler should not optimise those statements, but it does, so the assembler becomes:
ne_test:
cmp &a,&b
jne ne_test
eq_test:
jmp eq_test
wtf? It's assumed because the first loop is true (i.e a does not equal b), that the second loop must be false (a equals b), but a is declared volatile, so it really shouldn't do that.
So, my question is this, how on earth do people write stuff for 8/16 bit micros with any amount of confidence that what they've written is actually what they'll get. I've not seen this on any ARM compiler that I've used (but I'm sure odd cases do pop up).
It's been at least 5 years since I first pulled my hair out trying to use one of these compilers and it seems that not a lot has changed since then.
Adrian
Previous Topic
Index