[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4640E98B.4030107@goop.org>
Date: Tue, 08 May 2007 14:20:11 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: David Rientjes <rientjes@...gle.com>
CC: Randy Dunlap <randy.dunlap@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Paul Sokolovsky <pmiscml@...il.com>,
linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>
Subject: Re: [RFC/PATCH] doc: volatile considered evil
David Rientjes wrote:
> Since 'volatile' has two different semantics depending on the context in
> which it is used, this warning should be appended to include the fact that
> it is legitimate to use for inline assembly.
>
It's probably worth noting that "asm volatile (...)" doesn't mean what
many people think it means: specifically, it *does not* prevent the asm
from being reordered with respect to the surrounding code. It may not
even prevent it from being reordered with respect to other asm
volatiles. *All* it means is that the asm code will be emitted even if
the compiler doesn't think its results will be used. Note that an
"asm()" with no outputs is implicitly "asm volatile()" - on the grounds
that it would be otherwise useless as far as gcc can tell.
If you need to guarantee ordering of asm statements, you must do it
explicitly, with either a "memory" clobber, or some finer-grain
serialization variable (like the _proxy_pda stuff). It would be useful
if you could tell gcc "I'm passing this variable to the asm for
serialization purposes, but there's no need to generate any explicit
references to it", but as far as I know there's no support for that.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists