[U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 21/12/2010 14:30, Alexander Holler a ?crit :
> Am 21.12.2010 13:51, schrieb Albert ARIBAUD:
>> Le 21/12/2010 13:35, Alexander Holler a ?crit :
>>
>>> Hmm, is there actual somethinbg which should forbid the compiler to
>>> generate such code which rereads something? It might not be nice, but I
>>> don't think that it is forbidden for a compiler to do so. So the proper
>>> way to handle such, might be to use asm to avoid that the compiler
>>> touches that register.
>>
>> Yes there is something that should prevent a compiler from inserting
>> reads: these accesses are to hardware, not memory, and may cause side
>> effects even on read (these could be acknowledges, for instance; I've
>> seen instances of that myself on some HW).
>>
>> Another way to look at it is that the semantics of " *ptr = value " is a
>> pure write and should not result in a write-then-read.
>
> I think it's something like atomic_read. E.g. when reading an 32bit int
> (uint32_t i = *bla;), nothing forbids that the compiler generates code
> which reads those 4 bytes byte by byte (and so becoming a non-atomic
> operation). It's unusual to do so on 32bit architectures but valid.

OTOH, this still respects the semantics (the compiler is allowed to do a 
non-atomic read) while the bug we're seeing does not repect the 
semantics (the compiler is not asked to do any read but does one).

> Regards,
>
> Alexander

Amicalement,
-- 
Albert.