This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Heads-up: volatile and C++


On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <mike@mnmoran.org> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]