ARM bare-metal programming in D (cont) - volatile

[eles]

On Monday, 28 October 2013 at 08:42:12 UTC, Walter Bright wrote:
> On 10/28/2013 1:13 AM, Russel Winder wrote:
> Ask any two people, even ones in this thread, what "volatile" 
> means, and you'll get two different answers. Note that the 
> issues of reordering, caching, cycles, and memory barriers are 
> separate and distinct issues. Those issues also vary 
> dramatically from one architecture to the next.

"volatile" => "fickle"

> (For example, what really happens with a+=1 ? Should it 
> generate an INC, or an ADD, or a MOV/ADD/MOV triple for MMIO? 
> Where do the barriers go? Do you even need barriers? Should a 
> LOCK prefix be emitted? How is the compiler supposed to know 
> just how the MMIO works on some particular computer board?)

read [address] into registry (mov)
registry++ (add)
write registry to [address] (mov)

You cannot do it otherwise (that is, a shortcut operator).

"Shortcut" operators on fickle memory location shall be simply 
forbidden. Compiler is able to complain about that. Only explicit 
reads and writes shall be possible.

OK, go with peek() and poke() if you feel it's better and easier 
(this avoids the a+=1 problem). At least as a first step. But put 
those into the compiler/phobos, not force somebody to write ASM 
or C for that.

If D send people back to a C compiler, it would never displace C.

Templated peek() and poke() are 5 LOCs. Put those in a 
std.hardware module and, if you prefer, leave it undocumented.

Since we discuss this matter, it could have been solved 10 times.