>>>>> "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:
Michael> Jason Merrill wrote:
>> One proposed change is to the semantics of volatile.
Michael> Since IANALL, but I believe (as obviously you do) that
Michael> changing the semantics of volatile should be under-taken
Michael> with great care.
Agreed.
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.
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.
paul
