[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4640ED7D.708@goop.org>
Date: Tue, 08 May 2007 14:37:01 -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:
> 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.
Hm. Is "asm volatile" necessary if you have a "memory" clobber? Would
probably be the safest thing, I guess.
> 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.
>
Yeah, they're completely different. They're not even analogous, really,
which was my point. People confer more meaning to "asm volatile" than
it actually has, because of the analogy with volatile variables/types.
They would have been better off with something like "asm static", which
isn't much more meaningful, but at least it doesn't mislead the reader
into thinking it has anything to do with the other volatile.
But yes, seems like a worthwhile thing to point out. Or just point to
the gcc manual, which is pretty clear about all this stuff.
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