From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Date: Tue, 21 Dec 2010 14:30:06 +0100 Subject: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends. In-Reply-To: <4D10A2E7.6050302@free.fr> References: <1292711230-3234-1-git-send-email-holler@ahsoftware.de> <4D0DB994.1020703@googlemail.com> <4D0DDCEF.2040806@ahsoftware.de> <4D0E643A.9040001@ahsoftware.de> <4D0EA9BB.4050002@ahsoftware.de> <4D0F8E75.2010107@ahsoftware.de> <4D105324.2080201@googlemail.com> <4D105583.8070703@free.fr> <4D1066CD.2040409@googlemail.com> <4D1083B4.2060704@free.fr> <20101221105303.4E3EDB715C@gemini.denx.de> <4D109F06.1040109@ahsoftware.de> <4D10A2E7.6050302@free.fr> Message-ID: <4D10ABDE.7010303@ahsoftware.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. Regards, Alexander