On 24 October 2013 06:37, Walter Bright <[email protected]> wrote: > On 10/23/2013 5:43 PM, Mike wrote: >> >> I'm interested in ARM bare-metal programming with D, and I'm trying to get >> my >> head wrapped around how to approach this. I'm making progress, but I >> found >> something that was surprising to me: deprecation of the volatile keyword. >> >> In the bare-metal/hardware/driver world, this keyword is important to >> ensure the >> optimizer doesn't cache reads to memory-mapped IO, as some hardware >> peripheral >> may modify the value without involving the processor. >> >> I've read a few discussions on the D forums about the volatile keyword >> debate, >> but noone seemed to reconcile the need for volatile in memory-mapped IO. >> Was >> this an oversight? >> >> What's D's answer to this? If one were to use D to read from >> memory-mapped IO, >> how would one ensure the compiler doesn't cache the value? > > > volatile was never a reliable method for dealing with memory mapped I/O.
Are you talking dmd or in general (it's hard to tell). In gdc, volatile is the same as in gcc/g++ in behaviour. Although in one aspect, when the default storage model was switched to thread-local, that made volatile on it's own pointless. As a side note, 'shared' is considered a volatile type in gdc, which differs from the deprecated keyword which set volatile at a decl/expression level. There is a difference in semantics, but it escapes this author at 6.30am in the morning. :o) In any case, using shared would be my recommended route for you to go down. > The correct and guaranteed way to make this work is to write two "peek" and > "poke" functions to read/write a particular memory address: > > int peek(int* p); > void poke(int* p, int value); > > Implement them in the obvious way, and compile them separately so the > optimizer will not try to inline/optimize them. +1. Using an optimiser along with code that talks to hardware can result in bizarre behaviour. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
