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

[Iain Buclaw]

On 24 October 2013 06:37, Walter Bright <newshound2 at digitalmars.com> 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';