DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Johannes Pfau via Digitalmars-d]

Am Tue, 15 Jul 2014 19:03:52 +0200
schrieb Artur Skawina via Digitalmars-d <digitalmars-d at puremagic.com>:

> Compiler barriers are not "workarounds". "volatile" is not a "better
> solution". It's used in C only because it's defined and reasonably
> portable; barriers are a language extension, hence dialect specific.
> 
> First class support for "embedded programming" would be defining
> barriers, not transplanting C's volatile. You can already express
> all the described volatile semantics in GDC's D dialect, in a
> completely portable way and without using a single asm instruction.
> What's missing is just a defined standard interface which can be
> supported by all D compilers.
> 
> artur

Did you even read the section that explains why volatility is a property
of the memory address and not of the access (4.2.3)? What's your
response to that?

Why do shared variables have the privilege to prevent accessing shared
memory in inappropriate ways but it's fine to place the burden of
checking that all accesses to volatile memory are backed by compiler
barriers to the user? How is that 'first class' support?

I intentionally didn't put any technical information into this post to
make sure that people actually read the DIP and the only think you
responded to were the non-technical parts of my first post...