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

[Mike]

On Thursday, 24 October 2013 at 06:40:14 UTC, Iain Buclaw wrote:
>>> 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.
>>
>
> Operations on volatile are *not* atomic. Nor do they establish a
> proper happens-before relationship for threading.  This is why 
> we have
> core.atomic as a portable synchronisation mechanism in D.
>
>
> Regards

I probably shouldn't have used the word "operations".  What I 
meant is reading/writing to a volatile, aligned word in memory is 
an atomic operation.  At least on my target platform it is.  That 
may not be a correct generalization, however.

The point I'm trying to make is the Peek/Poke function proposal 
adds function overhead compared to the "volatile" method in C, 
and I'm just want to know if there's a way to to eliminate/reduce 
it.