This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Heads-up: volatile and C++
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