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

Daniel Murphy yebblies at nospamgmail.com
Fri Oct 25 06:07:53 PDT 2013


"Timo Sintonen" <t.sintonen at luukku.com> wrote in message 
news:qdvhyrzshckafkiekvnw at forum.dlang.org...
> On Thursday, 24 October 2013 at 13:22:50 UTC, Iain Buclaw wrote:
>
>> In gdc:
>> ---
>> asm {"" ::: "memory";}
>>
>> An asm instruction without any output operands will be treated
>> identically to a volatile asm instruction in gcc, which indicates that
>> the instruction has important side effects.  So it creates a point in
>> the code which may not be deleted (unless it is proved to be
>> unreachable).
>>
>> The "memory" clobber will tell the backend to not keep memory values
>> cached in registers across the assembler instruction and not optimize
>> stores or loads to that memory.  (That does not prevent a CPU from
>> reordering loads and stores with respect to another CPU, though; you
>> need real memory barrier instructions for that.)
>
> I have not (yet) had any problems when writing io registers but more with 
> read access. Any operation after write should read the register back from 
> real memory and not in processor registers.  Any repetitive read should 
> always read the real io register in memory. The hardware may change the 
> register value at any time.
>
> Now a very common task like
> while (regs.status==0) ...
> may be optimized to an endless loop because the memory is read only once 
> before the loop starts.
>
> I understood from earlier posts that variables should not be volatile but 
> the operation should. It seems it is possible to guide the compiler like 
> above. So would the right solution be to have a volatile block, similar to 
> synchronized? Inside that block no memory access is optimized.  This way 
> no information of volatility is needed outside the block or in variables 
> used there.
>

Volatile blocks are already in the language, but they suck.  You don't want 
to have to mark every access as volatile, because all accesses to that 
hardware register are going to be volatile.  You want it to be automatic.

I'm really starting to think intrinsics are the way to go.  They are safe, 
clear, and can be inlined.  The semantics I imagine would be along the lines 
of llvm's volatile memory accesses 
(http://llvm.org/docs/LangRef.html#volatile-memory-accesses) 




More information about the Digitalmars-d mailing list