Heads-up: volatile and C++

Michael N. Moran mike@mnmoran.org
Fri Apr 15 12:33:00 GMT 2005


Jason Merrill wrote:
> On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote:
>>For example, device drivers that perform memory mapped I/O
>>on memory spaces which are "guarded" and thus need no additional
>>ordering/synchronization instructions.
> 
> You mentioned PowerPC in a previous post; while device memory doesn't need
> as much explicit ordering as cached memory,
> 
>  http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html
> 
> says
> 
>  All these rules don't prevent stores to device memory from being issued
>  out of program order with respect to loads from device memory, or vice
>  versa. Instead, the memory-barrier instructions, eieio and sync, must be
>  used when out of order operations could yield incorrect results.
> 
> you need an eieio between loads and stores, or between two loads, to ensure
> proper ordering.  Yes, the proposed volatile semantics are more than you
> need.  But you do need something.

This is not true regarding access to pages of memory marked
"guarded" (e.g.. memory mapped I/O.) Such pages
ensure that access are not re-ordered by the processor.

See the table under "Memory barrier instructions"

> That said, perhaps the current volatile semantics are a useful primitive
> for building on with more specific explicit ordering, but that's not clear
> to me.

I'm very much in favor of fine grained synchronization primitives
in the compiler, but not of changes to volatile semantics.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1




More information about the Gcc mailing list