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

[Timo Sintonen]

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.