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. 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.
