Re: asm issues

[Linus Torvalds <torvalds at transmeta dot com>]

On Sat, 8 May 1999, Joern Rennecke wrote:
> 
> volatile often makes the work of the optimizers harder to do right,

I agree completely. And 99% of the hardness is the lack of hard "meaning" 
for volatile in the first place. It's always hard to implement something
that isn't all that well defined. 

I also agree with Mark: handling concurrency is hard. And I don't think
"volatile" is any good for it - I used to have a rule in the Linux kernel
that whenever there was a "volatile" there was a bug. That is generally a
very very good rule - volatile is simply not very useful for any real
work. 

The only way to handle synchronization issues is to have memory access
barriers. We have some of that: under gcc I can say

	asm volatile("": : :"memory");

and it will do exactly what I want when I need to tell gcc not to re-order
accesses, and it is even "portable" within gcc across all architectures I
have ever seen ;)

But to do more complex barriers I have to resort to tricks and
undocumented behaviour of gcc (for example, right now I know that gcc will
_not_ select another address for "m" arguments, and I basically depend on
that for spinlocks, but I'd be really happy if that would be made explicit
int he documentation some way). 

So basically I'm not suggesting that much work be spent on trying to make
"volatile" really work rigth - because I don't believe it is all that
useful anyway. Instead, I'm looking for alternative solutions to get the
much more well-specified behaviour I something need.

			Linus