On Friday, 25 October 2013 at 13:07:56 UTC, Daniel Murphy wrote:
"Timo Sintonen" <t.sinto...@luukku.com> wrote:

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)

It seems that it is two different things here. As far as I understand, sharing means something like 'somebody may change my data' and volatility is something like 'I have to know immediately if the data is changed'. It has become obvious that these two are not easy to fit together and make a working model.

The original question in this thread was to have a proper way to access hardware registers. So far, even the top people have offered only workarounds. I wonder how long D can be marketed as system language if it does not have a defined and reliable way to access system hardware.

Register access occurs often in time critical places like interrupt routines. A library routine or external function is not a choice. Whatever the feature is, it has to be built in the language. I don't care if it is related to variables, blocks or files as long as I do not have to put these files in a separate directory like I do now.

I would like to hear more what would be the options. Then we could make a decision what is the right way to go.

Reply via email to