asm volatile("":::"memory) uncertainty.

[Tom Udale <tom at ionoptix dot com>]

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