Re: [Mspgcc-users] Instruction reordering

[David B. <da...@we...>]

On 27/11/15 12:32, Wayne Uroda wrote:
> Hello,
> 
> I have a question about instruction reordering in the compiler.
> 
> In this blog 
> http://preshing.com/20120625/memory-ordering-at-compile-time/ It says
> that a compiler barrier should be used where writes to memory must
> not be reordered.

Looks like good information.

> 
> My MSP430 code is all bare metal, foreground-background code and I am
> not using any type of RTOS, so it could be considered lock-free.
> 
> Anyway, a new employee at my work pointed out that the compiler is
> free to reorder my memory writes, even those marked volatile. I said
> that I had never actually seen mspgcc do this, but now I am curious:
> will mspgcc reorder memory writes, eg to global variables? Is this
> dependent on the msp430 side of gcc (the backend), or more on the
> AST/RTL side?

The compiler can re-order any reads or writes it likes, except volatile
accesses.  The order of volatile accesses will always match the source
code.  But the compiler can move non-volatile reads and writes back and
forth between volatile accesses.

So if you have non-volatile variables a, b, c, and volatile variables u,
v, and source code like this:

a = 1;
u = 100;
b = 2;
v = 200;
c = 3;

Then the compiler can generate code like this:

a = 1;
c = 3;
u = 100;
v = 200;
b = 2;

But it may not generate code like this:

a = 1;
v = 200;
b = 2;
u = 100;
c = 3;

(The same applies to reads.)

The volatile accesses must be exact, in the same number and the same
order with respect to other volatile accesses.  But the non-volatile
accesses can be moved around as much as the compiler wants.

Note that variable accesses can also be moved around with respect to
function calls, /if/ the compiler knows the function does not make
volatile accesses.

The compiler can also eliminate "dead" stores, or unused reads.  Given:

a = 1;
u = 100;
a = 2;
v = 200;
a = 3;

The compiler can generate:

u = 100;
v = 200;
a = 3;

or

a = 3;
u = 100;
v = 100;


> 
> Or to put it another way, should I be reviewing my shared (between
> background and ISR) variables and placing compiler barriers where
> variables must be stored in an exact order?

Yes, these must be handled carefully.  In particular, volatile accesses
give no indication about how non-volatile accesses are handled.
Sometimes people write code like this:

int data[4];
volatile bool newData;

void update(int x) {
	data[0] = data[1];
	data[1] = data[2];
	data[2] = data[3];
	data[3] = x;
	newData = true;
}

And they think that making the newData flag a volatile is sufficient.
It is /not/ sufficient - the compiler can set newData before doing
anything with the data[] array.  And then your interrupt code will work
fine in all your testing, and hit a race condition when the customer is
watching.

You have to make each access to "data" here volatile, or you need a
memory barrier between "data[3] = x;" and "newData = true;".  A memory
barrier tells the compiler that all memory writes before the barrier
need to be completed, no writes after the barrier may be started, and
any data read before the barrier is now invalid.

And note that even then, nothing in memory barriers or volatile access
will ensure that the reads or writes are atomic.

Some useful macros/functions:

#define volatileAccess(v) *((volatile typeof((v)) *) &(v))

static inline void compilerBarrier(void) {
	asm volatile("" ::: "memory");
}


> 
> I am using a very old version of mspgcc, 3.2.3, I think it was the
> last stable Windows binary release before the CPUX instructions
> started making their way in, sorry I don't know the version, from
> 2008/2009 maybe?
> 

That was probably the final release before the mspgcc 4 project was
started.  And now there is a new port msp430-elf from Red Hat and TI,
which is where you should go for moving on for the future.

gcc 3.2.3 did not optimise as aggressively as newer gcc, so it will do a
lot less re-arrangement of code.  In general, the compiler will
re-arrange the order of writes if it has good reason to do so - if the
result is smaller and/or faster.  If it makes no difference, then it
will not re-order the writes.