Paul Koning wrote:
"Michael" == Michael N Moran <[EMAIL PROTECTED]> 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
