DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Johannes Pfau via Digitalmars-d]

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

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

You didn't say anything about a template in your last response. See my
reply to Kagamin:
- Template bloat: TypeInfo, Initializer, DebugInfo
- Requires inlining to produce decent results
- Requires force inlining: You wouldn't want any method implementations
  of Volatile to actually end up in object files.

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

This is not only for mmaped regs. It's also for memory used in
interrupt handlers with indirection.

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

For one thing we should not dictate usage patterns (like don't expose
raw memory) on users. Then volatile is very simple for every compiler
to implement and optimize, your idea requires multiple
pragmas/attributes to make sure there's no bloat and inlining always
works.

(For example, in gcc even a force inline attribute does not inline if
-finline is not used. I don't consider that acceptable for this kind of
code. So we might have to special case Volatile!T even more in the
compiler, to really always inline)

Otherwise Volatile!T is OK, but it's a new, fancy idea and might need
lots of work, whereas a volatile qualifer could be implemented easily
and we know right now for sure that it'll work 100% as expected.