DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Artur Skawina via Digitalmars-d]

On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote:
> 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.
> 
> 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?

You're assuming that the raw memory needs to be exposed. It doesn't.

IOW, instead of:

   struct HWRegs { uint a; uint b; /*...*/ }
   auto ptr = cast(HWReg*)0xc0000000;

do:

   struct HWRegs { uint a; uint b; /*...*/ }
   auto ptr = cast(Volatile!HwRegs*)0xc0000000;

and the Volatile template will magically add all the access barriers.

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

See above; just don't expose mmapped regs as normal memory.

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

Because the technical details don't matter when the point is that
'volatile' is not necessary. I did read your DIP, when you announced
it originally and also the gdc ml discussion that followed. I have
not seen any good argument for introducing a volatile type qualifier.
Could you show one (concrete) example where using 'volatile' is better
than my approach?

artur