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

[Johannes Pfau]

Am Fri, 25 Oct 2013 17:20:23 +0200
schrieb "Timo Sintonen" <t.sintonen at luukku.com>:

> 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.

What's wrong with the solution Iain mentioned, i.e the way shared
is implemented in GDC?

http://forum.dlang.org/thread/bifrvifzrhgocrejepvc@forum.dlang.org?page=4#post-mailman.2475.1382646532.1719.digitalmars-d:40puremagic.com
http://forum.dlang.org/thread/bifrvifzrhgocrejepvc@forum.dlang.org?page=4#post-mailman.2480.1382655175.1719.digitalmars-d:40puremagic.com