[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.0.99.0705081423500.24138@chino.kir.corp.google.com>
Date: Tue, 8 May 2007 14:27:33 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>
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
On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:
> 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.
>
Ok, so let's take your second paragraph and my email of an hour ago:
In an asm construct, if all your input operands are modified and
specified as output operands as well, volatile must be added so
that the entire construct is not optimized away. Additionally,
it must be added if your construct modifies memory that is neither
listed in inputs nor outputs to the construct so that it is known
to have at least one side-effect. Then, the compiler cannot
delete your construct if it is reachable because it may produce
such side-effects.
and add it to any proposed change to CodingStyle that suggests against the
'volatile' keyword since there exists a distinct difference in behavior
between using the keyword as a type qualifier for an object and as a
qualifier for an asm construct.
David
-
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