The article available here:
http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder/optimization_1optim_code_reorder.html
contains an essential mistake and is misleading for avr-gcc users.
In short: the author of the article in online documentation makes some analysis of a tricky case of using memory barrier in gcc and makes false conclusions. Quote:
"To sum it up:
memory barriers ensure proper ordering of volatile accesses
memory barriers don't ensure statements with no volatile accesses to be reordered across the barrier"
Point 1 makes no sense - volatile accesses are ensured to be properly ordered without any barriers - this is guaranteed by C standard.
Point 2 is false - a memory barrier ensures proper ordering of all, including non-volatile, memory accesses. This covers all global data, but not necesserily local data which can be placed in registers. In the analyzed case, variable val is a local variable. This is the real reason why memory barrier does not ensure strict ordering of operations on val. Memory barriers won't influence management of local variables stored in registers And this is perfectly fine, as only variables stored in memory can be accessed from various CPU contexts.
So the sentence "Unfortunately, at the moment, in avr-gcc (nor in the C standard), there is no mechanism to enforce complete match of written and executed code ordering" is correct. But the further conclusions (the two points quoted earlier) are incorrect and strongly misleading.
|