On Thursday, 24 October 2013 at 05:37:49 UTC, Walter Bright 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. 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.
Thanks for the answer, Walter. I think this would be acceptable
in many (most?) cases, but not where high performance is needed
I think these functions add too much overhead if they are not
inlined and in a critical path (bit-banging IO, for example).
Afterall, a read/write to a volatile address is a single atomic
instruction, if done properly.
Is there a way to tell D to remove the function overhead, for
example, like a "naked" attribute, yet still retain the
"volatile" behavior?
