Am Fri, 25 Oct 2013 17:20:23 +0200 schrieb "Timo Sintonen" <[email protected]>:
> On Friday, 25 October 2013 at 13:07:56 UTC, Daniel Murphy wrote: > > "Timo Sintonen" <[email protected]> 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/[email protected]?page=4#post-mailman.2475.1382646532.1719.digitalmars-d:40puremagic.com http://forum.dlang.org/thread/[email protected]?page=4#post-mailman.2480.1382655175.1719.digitalmars-d:40puremagic.com
