Re: [PATCH] Document Linux's memory barriers [try #4]

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Tue, 14 Mar 2006, David Howells wrote:

> Sergei Organov <osv@javad.com> wrote:
>
>> "You can prevent an `asm' instruction from being deleted by writing the
>> keyword `volatile' after the `asm'. [...]
>> The `volatile' keyword indicates that the instruction has important
>> side-effects.  GCC will not delete a volatile `asm' if it is reachable.
>> (The instruction can still be deleted if GCC can prove that
>> control-flow will never reach the location of the instruction.)  *Note
>> that even a volatile `asm' instruction can be moved relative to other
>> code, including across jump instructions.*"
>
> Ummm... If "asm volatile" statements don't form compiler barriers, then how do
> you specify a compiler barrier? Or is that what the "memory" bit in:
>
> 	#define barrier() __asm__ __volatile__("": : :"memory")
>
> does?
>
> David

Yeh. This is the problem (restated) that I mentioned the other
day when you must do a dummy read of the PCI/Bus to flush all
the writes, to some variable that gcc can't decide isn't
important. That's why (void)readl(PCI_STATUS) won't work
(with gcc 3.3.3 anyway). Some assignment needs to be made
to something gcc thinks is important or it might be moved or
removed altogether.

  	#define barrier() __asm__ __volatile__("": : :"memory")

Just tells the compiler that memory may have been modified. Therefore,
it will re-read any variables that might be setting in registers, before
it uses them. This is very useful since it basically makes all variables
temporarily "volatile" in its effects.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/