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++


Paul Koning wrote:
"Michael" == Michael N Moran <mike@mnmoran.org> writes:


 Michael> Jason Merrill wrote:
 >> One proposed change is to the semantics of volatile.

 Michael> I'm not familiar with ia64 barrier instructions, but I *am*
 Michael> familiar with PowerPC barrier and synchronization
 Michael> instructions (eieio, sync, isync, etc.), and I would
 Michael> question the practice of automatically generating these as
 Michael> side effect of a variable being declared as volatile, if for
 Michael> no other reason than the possible presence of code that is
 Michael> unnecessary in some (perhaps most) circumstances.

I don't understand that.  My reaction is just the opposite -- obeying
the defined semantics of "volatile" (the present ones as well as the
proposed ones) requires the insertion of barrier or synchronizing
instructions on platforms where those are needed to ensure ordered
global visibility.

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.


Or are you talking about a system (such as the BCM1250 MIPS processor)
which implements coherency across most, but not all, of the system
blocks? In that case, yes, when you are using "volatile" to
communicate within the coherence domain, barrier instructions are not
needed -- but if you use "volatile" to communicate *outside* the
coherence domain, they are. If you assume most cases are in the first
set, then you'd want the compiler not to supply barriers, you'd
handcode them instead using "asm" or builtins. Conversely, if you
assume that most cases are in the second set, then your code will be
more reliable and only slightly slower if the compiler supplies the
barriers.

Again, remember that there is *much* existing code that expects the current implementation of volatile semantics.

For new code, the addition of a new qualifier specifically geared
toward this purpose would protect the current code base and allow
for a more precise specification of architectural intent.

Clearly, I come from the camp that appreciates fine grained
control. I don't like the idea of paying for features I don't
need/use.

IMHO, this concept is *very* important in systems programming
languages.


-- 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



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