Greetings,
I am trying to use the standard
#define compiler_barrier() asm volatile("":::"memory")
approach to controlling the optimizer in an embedded system. The target
is a Parallax Propeller. The application is typical; I am trying to
time some code and the optimizer is moving statements outside the timed
area:
unsigned ct;
unsigned time;
ct=CNT; // read current count
// do some stuff
time=CNT-ct; // calculate time to do some stuff
Of course, some of the code in "do some stuff" is migrating after the
time= statement.
I thought that this would sort it:
ct=CNT; // read current count
// do some stuff
compiler_barrier();
time=CNT-ct;
I thought this would prevent any instructions associated with any code
that is listed before compiler_barrier() from appearing afterward and
vice-versa.
But it does not appear to work this way. I see significant numbers of
instructions after the second read of CNT. Indeed it looks as if gcc
has moved several _entire C statements_ after time=CNT-ct;
My confusion is whether or not the memory cobberer prevents movement of
statements in addition to flushing any values that may be in registers
before the compiler_barrier() line. i.e. it is unclear if there is any
control over what statements the memory being flushed is attached to (if
this makes any sense).
I am further confused as to whether this is an error in my understanding
(likely) or possibly an error in the particular gcc propeller
implementation.
I can provide more detailed code if it would be helpful (or if you are
adventurous, there is a related thread on the propeller forum:
http://forums.parallax.com/discussion/164186/memory-barrier)
Any help would be most appreciated.
All the best,
Tom Udale
