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

Timo Sintonen t.sintonen at luukku.com
Fri Oct 25 08:20:23 PDT 2013


On Friday, 25 October 2013 at 13:07:56 UTC, Daniel Murphy wrote:
> "Timo Sintonen" <t.sintonen at 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.


More information about the Digitalmars-d mailing list