On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote:
> Again, I understand the need for ordering/synchronization, I > simply do not believe that volatile should be overloaded to > include these semantics. > > Part of my point is that there are existing uses of volatile > which whose performance would suffer should ordering and/or > synchronization instructions be added around each access. > > 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. 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. Jason
