Re: GNU C keyword volatile, GNU compiler/optimizer and instruction re-ordering

Arun <Arun@Winphoria.Com> wrote:
...
>
> some_function() {
> volatile int *ptr1 = 0x60000000;
> volatile int *ptr2 = 0x60000004;
> int val;
> ... ... ...
> *ptr1 = 0x1212abab;
> ... ... ...
> *ptr1 = 0xabcd1234;
> ... ... ...
> val = *ptr2; /* We expect to have 0xabcd1234
> assigned to val */
> }
...
>In the same context, can processor pipelines in general re-order the
>instructions? Interesting cases may be the Intel's Pentium series and
>Motorola PowerPC. What if possible/any, are the hints by the
>compiler/optimizer to the processor?


Yes, hardware can re-order memory accesses. Systems that do this may
have a 'memory barrier' instruction which enforces ordering. In the
example above, you would put a store/load barrier between the last
write to *ptr1 and the read from *ptr2. This would instruct the CPU to
guarantee that the read was not performed before the write. Similarly
you may have store/store barriers (for when you need to perform writes
in a specific order), and load/store and load/load ones with the
obvious meaning.


An alternative to memory barriers is for the memory region to be
marked in some way to indicate that it is not plain memory so accesses
cannot be re-ordered or cached.


I would not expect a compiler to guarantee that volatile accesses
cannot be re-ordered by hardware - merely that it does not re-order
the accesses.
--
Eppur si muove

Return to the comp.compilers page.
Search the comp.compilers archives again.