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

[Timo Sintonen]

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.

Yes, this is a simplest way to do it and works with gdc when 
compiled in separate file with no optimizations and inlining.

But todays peripherals may have tens of registers and they are 
usually represented as a struct. Using the peripheral often 
require several register access. Doing it this way will not make 
code very readable.

As a workaround I have all register access functions in a 
separate file and compile those files in a separate directory 
with no optimizations. The amount of code generated is 3-4 times 
more and this is a problem because in controllers memory and 
speed are always too small.