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.
