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