Re: Portable memory barrier?

[Robert Eachus <rieachus@comcast.net>]

On Tuesday, May 9, 2017 at 3:57:50 PM UTC-4, Randy Brukardt wrote:
> "Robert Eachus" <rieachus@comcast.net> wrote in message 
> news:077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com...
> ...
> >The compiler will play some games, and certainly will leave Write_Index in 
> >a register if possible.
> 
> It better not is Write_Index is Atomic.

First, if FIFO has Atomic_Components, then it is not possible.  Atomic_Components would be overkill, but I haven't seen those declarations here.  If FIFO has just Volatile_Components (or no attribute) then this is possible.  But what is "this"?
> 
Sloppy wording, I should have said "keep a copy of Write_Index".  The write to Write_Index will occur to cache on modern systems where the whole system is cache-coherent.  But that is a detail.  What I was specifically referring to was that there are two subexpressions Write_Index+1.  As far as I can tell, if there are no synchronization points between them, the (overall system including) the compiler can do one read of Write_Index, then evaluate the expression once--or twice.

Why evaluate twice? (Other than the write to FIFO being a synchronization point?) Hardware  magic may combine the increment with the move, through a postincrement addressing mode. It would then write the incremented register copy to Write_Index.  One read, one write.  Same as if it did common subexpression elimination. It doesn't need to READ Write_Access twice.  I hope I'm right, because anything else is silly.  If a synchronization point did occur between the two reads, then the in register copy of Write_Index, or Write_Index + 1, if the implementation wants to keep that around instead, must be spoiled.

What if Write_Address is assigned to a special address which other hardware can access?  Doesn't matter.  Think of the cache system as treating addresses as names, and moving them around.  As long as everyone sees the same version of that name, the contents of the location named are the only reality we can be concerned with.  Since CPUs now contain the (physical) memory managers, as well as cache, the "external effect" of a program has to be interpreted as the view of memory offered by the CPU.  Nothing else is available.  (Writes to disk, or to the display screen are all memory writes from the CPU's viewpoint.)

There is another issue here, which we need to allow compilers to get right.  Assume that the records in FIFO are X bytes long.  A common compiler optimization is to use a value FIFO'Address + X x Write_Index instead of Write_Index to do the writes.  Is that legal?  Or better, under which attributes of FIFO and Write_Index is the system allowed to do that optimization?

> Only the compiler vendor need worry about this level of discussion. 
> Honestly, I doubt anyone else is qualified. (I'm not, and I AM a compiler 
> vendor... ;-)

I used to be a compiler writer, on at least three Ada compilers, but the deep level understanding of what is going on comes from my work on radar systems.  There access times in microseconds are important, and sometimes in nanoseconds. (I think the worst real-time requirement I ever saw was for 200 nanoseconds. Ouch!)