DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Walter Bright via Digitalmars-d]

On 7/15/2014 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

This is a particularly well-written DIP, thank you and the other contributors to it.


> * Although it's explained in the DIP in detail, I must mention this
>    here again: We need _first-class_ support for embedded programming in
>    D. Workarounds might be available (peek/poke, inline asm) but it will
>    be obvious to most C programmers that C has got the better solution
>    with the volatile qualifier. D enthusiasts might be happy if they can
>    use workarounds to make D work on microcontrollers. But if we want to
>    appeal to outsiders we can't confront them with obvious workarounds
>    and hacks as the first thing they see in D. And if they think embedded
>    programming is a second class citizen in D, why should they use it
>    at all?

1. Volatile has caused a major increase in the complexity of the C++ type system 
- a complexity far out of proportion to the value it provides. It would have a 
similar complex and pervasive effect on the D type system.

2. You mention peek/poke here, but not in the DIP. [Background: I've designed 
and built embedded systems, and written the software for them.] There aren't 
that many memory-mapped I/O registers. They just aren't worth bending the entire 
language around them. Peek/poke work just fine:

1. they can be implemented as compiler intrinsics so there is no efficiency cost 
for using them

2. they make it clear in user code when memory-mapped I/O is accessed

3. if you really hate peek/poke calls appearing in the code, you can use UFCS to 
make them look like variables

4. they are simple to explain and understand, they do not introduce a numbing 
complexity to the type system

5. peek/poke will not add to the confusion about the difference between volatile 
and shared. No sane person would be tempted to use peek/poke to implement 
concurrency. The semantics of volatile in other languages won't confuse things 
for D peek/poke.


The one thing peek/poke doesn't offer is transitivity. C/C++ don't offer 
volatile transitivity either. I'm not at all sure that anyone builds a data 
structure in memory-mapped registers, so I'm not convinced this is a need.