On Thursday, 24 October 2013 at 06:37:08 UTC, Iain Buclaw wrote:
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.
Well, I've done some reading about "shared" but I don't quite
grasp it yet. I still have some learning to do. That's my
problem, but if you feel like explaining how it can be used in
place of volatile for hardware register access, that would be
awfully nice.
