on 11/12/02 7:03 AM, Jan Hudec at bulb@ucw.cz wrote:
>
> There are two things to the barrier. One is to make sure CPU does not
> prefetch the old value and another is to make sure, that compiler does
> not reorder the statements!
>
The first one is a hardware memory barrier:
#define mb() __asm__ __volatile__ ("lock; addl $0,0(%esp)": : :"memory")
The second one a software memory barrier:
#define barrier() __asm__ __volatile__ ("": : :"memory")
Hardware memory barrier force strict CPU ordering and is required when
you're talking to devices. See:
- http://www.xml.com/ldd/chapter/book/ch08.html
- Include/asm-i386/system.h
> It has the first string empty, so it expands to no code at all.
> But because of the memory clobber flag, gcc is forbiden to optimize
> across this point. Otherwise gcc could for example conclude that "I have
> A in register, I am not short of registers and I will need it few
> statements later. There is no need to store it in memory." ... and
> actually not store it.
>
> The mb() thing adds a "barrier" instruction to actualy stop CPU prefetch
> across the point. No such instruction is needed on IA32, but it's needed
> on some other arch with agressive prefetch (eg. sparc IIRC).
>
> (I am not absolutely sure, look it up in the code).
>
The hardware memory barrier is needed on IA32 only to prevent reads to pass
buffered writes. So the hardware memory barrier use a locking instruction
such as the LOCK prefix to insure that all buffered writes are drain to
memory before the reads are done. See:
- Intel Architecture Software Developer¹s Manual Volume 3: System
Programming
- Include/asm-i386/system.h
--
David Dufresne, Sys. admin. <dufresne@mediafusion.com>
Médiafusion Inc. <http://www.mediafusion.com>
700, rue Wellington Bureau 1200
Montreal (Quebec) H3C 1T4
Tel.(514) 599-5721 Fax.(514) 599-5724
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
