out of order execution / reoredering of instructions

[Samuel Stearley]

Declare the variables to be volatile and the compiler won't be allowed
to play games with the ordering.

I wouldn't rely on that. I might be wrong but I think the only
consequence of volatile is to keep the compiler from optimizing away
reads


For the powerPC here's what we do at work to make sure memory mapped
IO registers are accessed in proper order.

1) proper setup of dbat registers. The dbats define attributes for
very larger areas of physical address space. We make sure that they
define it as cache inhibited and as guarded.

2) we don't use expressions like *ptr =value. we call functions like
DWordWrite(UINT32 * ptr, value). The ptr is cast as pointing to a
volatile UINT32 * (I think this is pedantic), the data is written, then
we use some inline asm and force the eieio instruction. To quote the
PPC docs:

"Loads and stores to memory that is both caching-inhibited and guarded,
and stores to memory that is write-through required. The eieio
instruction controls the order in which the accesses are performed in
main memory. It ensures that all applicable memory accesses caused by
instructions preceding the eieio instruction have completed with
respect to main memory before any applicable memory accesses caused by
instructions following the eieio instruction access main memory. It
acts like a barrier that flows through the memory queues and to main
memory, preventing the reordering of memory accesses across the
barrier. No ordering is performed for dcbz if the instruction causes
the system alignment error handler to be invoked."


I hope this helps. If your platform is x86 try to find the equivalent.

 

[Tom St Denis]

I wouldn't rely on that. I might be wrong but I think the only
consequence of volatile is to keep the compiler from optimizing away
reads


For the powerPC here's what we do at work to make sure memory mapped
IO registers are accessed in proper order.

The thread that won't end...

In *practice* GCC is fairly anal [re: safe] about volatile. It won't
spend a lot of time optimizing and generally does a fairly literal
translation. Most embedded programming that uses GCC [re: stuff for
the GBA, DS, PSP and GP32] work with this just fine.

However, if you need to gurantee an order use sequence points and
functions which do the damn writes in asm [hint: see the Linux kernel].

I win the thread.

Tom

 

[Chris Torek]

In *practice* GCC is fairly anal [re: safe] about volatile. It won't
spend a lot of time optimizing and generally does a fairly literal
translation. Most embedded programming that uses GCC [re: stuff for
the GBA, DS, PSP and GP32] work with this just fine.

However, if you need to gurantee an order use sequence points and
functions which do the damn writes in asm [hint: see the Linux kernel].

I win the thread.

And your prize is a PowerPC "eieio" instruction (which gcc will
not emit on its own).

The article to which you attached your follow-up included these
lines:

and additional mention of the need for the "eieio" instruction, in
some cases.

Note that if you write the "write to memory-mapped I/O port" routine
in assembly, you can indeed include the necessary memory-barrier
instructions ("eieio" on PowerPC, "membar" on SPARC-V9, and so on).
Alternatively, you can do things like:

volatile struct hw_regs *regs = ...;
...
regs->this = some_value;
memory_barrier();
regs->that = another_value;
memory_barrier();

and in some compilers, you can even arrange for the memory barrier
to be expanded in line (i.e., avoid a subroutine call, not that the
time expended in a subroutine call will be significant in most of
these cases -- the memory-mapped I/O port "memory access" may take
200 or more CPU-instructions worth of time, making a mere 1 or 2
cycle subroutine call disapepar into the noise).

 

[Thad Smith]

(e-mail address removed) a écrit :

It would be highly surprising that your compiler doesn't provide a
switch to turn instruction reordering OFF. Look again in your compiler's
documentation. Also, try to turn optimizations OFF and see if this changes.

As a last resort use the volatile keyword, as recommended by the other
posters

I would recommend using volatile as a first resort. The compiler cannot
reorder volatile accesses.

 

[junky_fellow]

My sincere thanks to everyone for sharing their thoughts. Before, I
posted this query here, I did a lot of search on the web and referred
to some books as well, but I always get the best and most satisfying
answers on this newsgroup.
thanks again.