DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Andrei Alexandrescu via Digitalmars-d]

On 7/15/14, 9:25 AM, Johannes Pfau wrote:
> DIP62 describes how to solve this problem and make embedded programming
> a first-class citizen in D:
> http://wiki.dlang.org/DIP62
[snip]

The good:

This is a very crisply-written and comprehensive proposal. It could use 
a little work (e.g. define the typing relationships among volatile, 
other qualifiers, and unqualified if any) but completeness is outstanding.

The bad:

I think we should reject this proposal. Moreover, the comprehensiveness 
of the DIP gives me confidence to assess that no amount of work on the 
proposal could take it to acceptance.

The ugly:

There's none! Actually there's some nice stuff: we could use a bunch of 
this proposal to specify alternative approaches such as peek/poke.

=============

My rationale:

* I reject he premise ("The volatile qualifier is often used for 
embedded programming in C/C++[1]".) At most I agree with "often" as in 
"you'll see at least one use of volatile in some, maybe many, embedded 
programs" but not "volatile is present many times in a typical embedded 
application". Hardware/firmware providers often focus on giving access 
to low-level hardware facilities by using classic encapsulation and 
exposing APIs, as opposed to just publishing the raw addresses of 
various ports. Furthermore, the link given as a justification 
(http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword) is 
not support for the statement in text, but instead a mere description of 
volatile, which is also technically incorrect (viz. the use of volatile 
with threads).

* "volatile" has been one of the most awkward parts of the C and C++ 
specifications. If we're to learn of anything about it, it's we must 
stay away from it. It is extremely heavy for what it provides.

* Currently C++ defines observable behavior as "reads and writes of 
volatile variables and sequences of calls to certain library functions". 
There is only a small burden associated with sequences of function 
calls, but the volatile parts are complicating the specification 
enormously. We'd be better off specifying sequences of calls to 
functions as defined behavior.

* Adding qualifiers is heavy for the language definition and 
implementation. Probably they're the most impactful artifact to add.

* Transitivity is only partially justified. For immutable and shared 
data, transitivity is motivated by code access patterns that chase 
pointers, but for volatile data there's no hardware reality reflected by 
transitivity: MMIO only pertains simple address ranges, not node-based 
volatile structures. The justification in section "Transitivity" is 
valid but puts undue emphasis on obscure interrupt service routines; 
even C doesn't go that far (instead it just limits the functions such 
routines may call).

* The DIP is correct in mentioning that "volatility" is a property of 
the memory location so it should apply to the respective variable's 
type, as opposed to just letting the variable have a regular type and 
then unsafely relying on calls to e.g. peek and poke. But here's a 
practicality argument that's been already mentioned - such volatile data 
is rare and classic encapsulation techniques can be applied to it.

* The scalability aspect should be emphasized: a large system may have 
more need to synchronize threads or to characterize parts of it as 
functional (pure + immutable). In contrast, a large embedded system does 
not manifest a proportionally larger presence of volatile data.

==============

I think an approach based on functions peek/poke is a lot more 
promising. D programs must define sequences of std calls anyway, 
otherwise even the simplest programs that use writeln("What's your 
name?") followed by a readln() are incorrect. So in a way peek/poke come 
for "free".

Clearly an approach that adds a qualifier would have superior 
abstraction capabilities, but my experience with C++ (both specification 
and use) has been that the weight to power ratio of volatile is enormous.


Andrei