Thanks very much David.

I already disable interrupts when I need an atomic operation, such as a write 
to 32 bit variable or a read-modify-write on a 16bit variable.

Am I right to assume that simple writes to 16 bit variables are always atomic 
on MSP430? Eg done = 0xabcd, the CPU doesn't do two byte writes or anything 
dumb like that, the memory will be X (don't care) before the write and will be 
0xabcd after, or should I disable interrupts for all writes to shared memory 
(shared with an ISR)?


My colleague asserts that the compiler is even free to reorder volatile 
accesses, like

volatile int a;
volatile int b;
int c;

int main()
{
    a = 5;
    b = 0;
    c = 1;
    return 0;
}

You are saying that the compiler will always write a before b, even without a 
memory barrier. Is that right?

But in the above, the write to c can happen anywhere, as far as I understand.

Lastly, this compiler (3.2.3) is only used on our legacy projects. More 
recently we are using the last LTS of mspgcc before Ti/RH started their port.
I've not seriously tried to use the new RH compiler, and my company is largely 
moving away from MSP430 towards ARM Cortex now.

Thanks
- Wayne



> On 27 Nov 2015, at 23:19, David Brown <da...@westcontrol.com> wrote:
> 
>> 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.
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to