Messages in this thread | | | Date | Fri, 04 Dec 2009 09:30:10 -0800 | From | "H. Peter Anvin" <> | Subject | Re: x86: Is 'volatile' necessary for readb/writeb and friends? |
| |
On 12/04/2009 06:39 AM, Segher Boessenkool wrote: >> x86 memory-mapped IO register accessors cast the memory mapped address >> parameter to a one with the 'volatile' type qualifier. For example, here >> is readb() after cpp processing >> >> --> arch/x86/include/asm/io.h: >> >> static inline unsigned char readb(const volatile void __iomem *addr) { > > This "volatile" is meaningless.
Wrong. "volatile" here is an assertion that it is safe to pass pointer to a volatile object to this function.
>> unsigned char ret; >> asm volatile("movb %1, %0" > > This "volatile" is required; without it, if "ret" isn't used (or can > be optimised away), the asm() could be optimised away. > >> :"=q" (ret) >> :"m" (*(volatile unsigned char __force *)addr) > > This "volatile" has no effect, since the asm has a "memory" clobber. > Without that clobber, this "volatile" would prevent moving the asm > over other memory accesses. > > If you want to get all language-lawyery, if the object pointed to by > "addr" is volatile, the volatile here _is_ needed: accessing volatile > objects via a not volatile-qualified lvalue is undefined. But since > this is GCC-specific code anyway, do you care? :-)
Again, this comes from the prototype being volatile.
Either way, it works, it is guaranteed to be safe, and removing it can only introduce bugs, not remove them.
-hpa
-- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
| |