[CW7.0 for coldfire] weird behavior

[Nouchi]

Hi,

Someone can explained this behavior?

Code:

 MCF_GPIO_SETAN = MCF_GPIO_SETAN_SETAN5; MCF_GPIO_DDRDD = 0x00;   
0001342E: 42394010002C    clr.b    0x4010002C (0x4010002c)      // MCF_GPIO_DDRDD = 0x0000013434: 7020            moveq    #32,d0               00013436: 13C04010003A    move.b   d0,0x4010003A (0x4010003a)   // MCF_GPIO_SETAN = MCF_GPIO_SETAN_SETAN5

 Why codewarrior invert execution order of two volatile variable (vuint8), when I use optimization level 4 (smaller code size)?


Emmanuel.

Message Edited by BugMan on 2008-05-19 11:16 AM

[Nouchi]

Hi,

I would like to know, if volatile modifier is used, what the compiler have to do?
Optimizing or not optimizing?

Code:

typedef volatile uint8   vuint8
#define MCF_GPIO_SETAN   (*(vuint8 *)(&__IPSBAR[0x10003A]))


 MCF_GPIO_SETAN = MCF_GPIO_SETAN_SETAN5; MCF_GPIO_DDRDD = 0x00;

produce:
0001342E: 42394010002C    clr.b    0x4010002C (0x4010002c)      // MCF_GPIO_DDRDD = 0x00
00013434: 7020            moveq    #32,d0              
00013436: 13C04010003A    move.b   d0,0x4010003A (0x4010003a)   // MCF_GPIO_SETAN = MCF_GPIO_SETAN_SETAN5

The peephole optimizer has effect in this case is it normal?
I need some explanation......

Emmanuel
 

[CrasyCat]

 Hello

According to Wikipedia:

"a variable or object declared with the volatile keyword may be modified externally from the declaring object. For example, a variable that might be concurrently modified by multiple threads may be declared volatile. Variables declared to be volatile will not be optimized by the compiler because the compiler must assume that their values can change at any time"

That means if you have code as follows:

Code:

Code:typedef volatile uint8   vuint8#define MCF_GPIO_SETAN   (*(vuint8 *)(&__IPSBAR[0x10003A])) MCF_GPIO_SETAN = 5; MCF_GPIO_DDRDD = 0x00;  MCF_GPIO_SETAN = 4;

 

The compiler will generate code for both instructions MCF_GPIO_SETAN = 5; and MCF_GPIO_SETAN = 4;.

This does nor mean that the compiler must keep the sequence of the instructions in the code.

An optimizing compiler might modify the code above as follows:

 

Code:

Code:Code:typedef volatile uint8   vuint8#define MCF_GPIO_SETAN   (*(vuint8 *)(&__IPSBAR[0x10003A])) MCF_GPIO_DDRDD = 0x00;  MCF_GPIO_SETAN = 5; MCF_GPIO_SETAN = 4;

 
This is perfectly legal.

CrasyCat

[CompilerGuru]

I would actually like to defend the CF compiler, but I don't think this reordering of volatile accesses (here volatile writes) is reasonable (or are legal according to C99/C++98). I think here the compiler should be changed.

For the standard volatile definitions, as far as I remember (did not look it up now), C89 is not so precise in this topic, so could be that the compiler does not violate this standard, but that does not make the behavior better tough.

But actually the C++ and the more recent C99 standard are both more specific about volatile.
The wikipedia article is nice, but not really normative. Maybe it could be a bit extended :smileyhappy:.
Hmm. With wikipedia references it works pretty much the other way round than with standard references.
If a compiler does not match the standard, we should change the compiler.
If a compiler not match wikipedia (but follows the standards), we should change wikipedia :smileyhappy:.

Did you submit a service request for this issue?

Daniel

[Nouchi]

Hello Daniel,

I already submit a service request, and Freescale support answered:
"This is not a bug, you are using the peephole optimization For fix it, In your target settings -> Code generation -> Coldfire Processor. Uncheck the PeepHole optimization
The peephole optimization applies the local optimization routines to small sections of code in this case for the MCF_GPIO_DDRDD = 0x00;    that is just 8 bytes. "

I don't like this reply so much, so I decided to open a discussion about this topic.
I think it would it would be great to have solutions which override all optimizations when you want to keep order statement.


Regards,
Emmanuel