Hi folks,
I'm one of the authors of the paper in question.
I teach two embedded systems courses that use CodeWarrior, one based on HCS12 and one based on ColdFire. Overall I'm happy with both chips and with both versions of CodeWarrior!
But yes, the ColdFire C compiler has serious issues with volatiles. I'd be happy to post examples if people are interested. We haven't studied the HCS12 port in detail but it seems better-- a bit of spot checking that I've done has turned up no problems.
Anecdote: I got started with this whole volatile project due to my standard lecture on proper use of volatile variables. A couple years ago I was giving this lecture, which included some C code fragments and their translation into ColdFire asm. One of the students raised his hand and asked why a particular translation didn't look right-- I answered that I must have cut and pasted wrong. But later I looked into this and it was the compiler that was wrong. This eventually snowballed into a long-term testing project. So far we've reported 129 bugs to various compiler developers.
John Regehr
Looks like I don't have CW for CF installed right now. But I remember that for example this code is totally optimized away:
volatile int x;
x |= 0;
Here the "or" does not need to be performed, but there has to be a load from and store to x.
Please keep in mind that I'm not picking on CW here: no compiler that we have tested so far has been free of volatile bugs.
My hand-written test suite is here:
http://www.cs.utah.edu/~regehr/volatile_stress.c
To test your compiler of choice, just compile this code with your favorite optimization options and see if you believe its results. I just did this using CW 4.7 for HCS12 and found very little, if anything, that looked suspicious.
John Regehr
Below are a couple of (I claim) mistranslations performed by CW for CF 7.1 when optimizing maximally for speed.
Here g_1 is loaded but the compiler forgets to store it:
; 142: void or_1 (void);
; 143: void or_1 (void)
; 144: {
;
0x00000000 _or_1:
; or_1:
0x00000000 0x4E560000 link a6,#0
;
; 145: g_1 |= 0;
;
0x00000004 0x203900000000 move.l _g_1,d0
;
; 146: }
;
0x0000000A 0x4E5E unlk a6
0x0000000C 0x4E75 rts
0x0000000E 0x51FC trapf
Here the loop optimizer improperly collapses five stores into one (LOOP_BOUND is 5):
; 262: void loop_3 (void);
; 263: void loop_3 (void)
; 264: {
; 265: TYP i;
;
0x00000000 _loop_3:
; loop_3:
0x00000000 0x4E560000 link a6,#0
0x00000004 0x598F subq.l #4,a7
;
; 266: volatile TYP z = 0;
; 267: for (i=0; i<LOOP_BOUND; i++) {
;
0x00000006 0x42AEFFFC clr.l -4(a6)
;
; 268: z += 3;
; 269: }
;
0x0000000A 0x700F moveq #15,d0
0x0000000C 0x2D40FFFC move.l d0,-4(a6)
;
; 270: }
;
0x00000010 0x4E5E unlk a6
0x00000012 0x4E75 rts
Hello
The appropriate process to request an improvement in the generated code is to submit a service request.
Click here to submit a service request.
Make sure to attach a code snippet showing the code you want o get optimized.
CrasyCat
SR has been submitted. Thanks,
John Regehr