Forums

Powerpc optimization change the order of operation

Started by dreamerg April 17, 2008
Hi 
Does sombody know a way to disable optimization for part of a code?
I have a code that writes data to some HW machine. It has to do it in
acertain order. Although I use volatile to write to those adresses the
order in which the writes and read are done changes when I enable
optimization in the compiler. Is there a way to solve this without the need
to disable the optimization? I don't want to put this code in seperate
function in another file and disable the optimization only for this file. 

Thanks


dreamerg wrote:
> Hi > Does sombody know a way to disable optimization for part of a code? > I have a code that writes data to some HW machine. It has to do it in > acertain order. Although I use volatile to write to those adresses the > order in which the writes and read are done changes when I enable > optimization in the compiler. Is there a way to solve this without the need > to disable the optimization? I don't want to put this code in seperate > function in another file and disable the optimization only for this file.
Do you also use volatile variables to read ? The compiler is not allowed to change the order of volatile accesses, even with optimizations enabled. If it does, it's a bug in the compiler. Did you talk to your compiler vendor ? It is, of course, possible that the variables aren't declared properly, or that there's another error in the code. Perhaps you could post a small example of what you're trying to do ?
Arlet Ottens wrote:
> dreamerg wrote: >> Hi Does sombody know a way to disable optimization for part of a code? >> I have a code that writes data to some HW machine. It has to do it in >> acertain order. Although I use volatile to write to those adresses the >> order in which the writes and read are done changes when I enable >> optimization in the compiler. Is there a way to solve this without the >> need >> to disable the optimization? I don't want to put this code in seperate >> function in another file and disable the optimization only for this file. > > Do you also use volatile variables to read ? > > The compiler is not allowed to change the order of volatile accesses, > even with optimizations enabled. If it does, it's a bug in the compiler. > Did you talk to your compiler vendor ? > > It is, of course, possible that the variables aren't declared properly, > or that there's another error in the code. Perhaps you could post a > small example of what you're trying to do ? >
As well as all the above good advice, it's important to remember that "volatile" is an instruction to the compiler, not the processor. In particular, it won't affect things like caches, write buffers, and instruction re-ordering. Depending on the powerpc in question, you can get all sorts of re-ordering in the processor. You have to make sure that your accesses are not cached, and that you use an "eieio" instruction (or equivalent, depending on the exact ppc model) to ensure that write buffers are flushed and any speculative loads are dropped between accesses.
David Brown wrote:
> ... > You have to make sure that your accesses are not cached, and that you > use an "eieio" instruction (or equivalent, depending on the exact ppc > model) to ensure that write buffers are flushed and any speculative > loads are dropped between accesses.
eieio does not flush the cache or any buffers, it only enforces "in order". Typically, he will have the peripherals in a non-cacheable block or page (which is *not* how they come out of reset). If for some reason they are in cacheable memory, things get messier, for read he will have to do dcbi prior to reading, for write dcbf after reading, all these interspersed with eieio or sync... but this is not a normal thing to do. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/7e449468a68d81f9?dmode=source
On Apr 17, 8:42=A0am, "dreamerg" <levitas...@gmail.com> wrote:
> Hi > Does sombody know a way to disable optimization for part of a code? > I have a code that writes data to some HW machine. It has to do it in > acertain order. Although I use volatile to write to those adresses the > order in which the writes and read are done changes when I enable > optimization in the compiler. Is there a way to solve this without the nee=
d
> to disable the optimization? I don't want to put this code in seperate > function in another file and disable the optimization only for this file.
While volatile requires that all accesses to the variables in question occur (more or less), and it requires that the access happen as bounded by the sequence points in the program (again, more or less), it says nothing about what order things happen in between sequence points. So assuming va and vb are declared volatile: c =3D va + vb; There is no guarantee regarding the order in which va and vb are accessed (but they will be accessed). So if the order matters, you need to insert sequence points between those two reads, something like: t1 =3D va; t2 =3D vb; c =3D t1 + t2; But you should still review your compiler=92s documentation for what exactly volatile guarantees.
dreamerg wrote:
> Hi > Does sombody know a way to disable optimization for part of a code? > I have a code that writes data to some HW machine. It has to do it in > acertain order. Although I use volatile to write to those adresses the > order in which the writes and read are done changes when I enable > optimization in the compiler. Is there a way to solve this without the need > to disable the optimization? I don't want to put this code in seperate > function in another file and disable the optimization only for this file.
If your compiler is GCC, there's a simpler solution. Pity that you didn't mention which compiler you use.
> Thanks
You're welcome. Also, don't forget to use "eieio" instructions, as another message in this thread suggests. It is important to prevent reordering by both the compiler and the CPU itself.