DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Walter Bright via Digitalmars-d]

On 7/15/2014 1:43 PM, Johannes Pfau wrote:
>> 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.
>
> Well as described in the DIP it works just like shared from an
> implementation point of view, so I doesn't add much complexity in the
> compiler / type system.

It's not so easy. All the interactions between volatile and other modifiers have 
to be carefully designed, documented, and implemented.


> Indeed there's nothing about peek/poke in DIP62, I thought I added that.
> The main point is that we can not leak pointers to volatile memory to
> users and pretend it's normal memory. This will lead to many problems:

I have a hard time seeing that MMIO is used so much in an embedded system that 
this will be a significant problem. And if it is, you can build a wrapper type 
and control access.


> This is like saying we don't need the shared qualifier as people
> should use atomicOp to access the data.

Shared use, however, is pervasive in concurrent code.


> But the problem there is that it produces quite some overhead right
> now.

Are you sure? The compiler is pretty good at inlining trivial functions.


>> 3. if you really hate peek/poke calls appearing in the code, you can
>> use UFCS to make them look like variables
> But you cant do REGISTER.peek() |= 0b1;

As you mentioned in the DIP, read-modify-write operations should be split up, as 
their semantics are murky.


>> 4. they are simple to explain and understand, they do not introduce a
>> numbing complexity to the type system
> Sorry, but I don't buy any of these complexity arguments.

No need to be sorry. Your opinion is not invalid.


> A few months
> ago you suggested namespaces for D - in addition to modules - which
> would have lead to a complexity disaster.

C++ namespaces are now implemented in D, and will they lead to complexity 
disaster? Certainly not in the implementation. For users? I don't think so, but 
we'll see.

> This just shows the priorities of the project leads:
> Desktop apps matter, we add @nogc, c++ namespaces, shared, immutable,
> const, -cov, ...
> but for embedded systems we won't even add one qualifier.

I don't think this is the right argument. It isn't about embedded systems should 
be acknowledged with a qualifier. I see it as about how often does MMIO logic 
appear in an actual embedded program? In the embedded systems I've written, it 
only appears in a handful of places. It is not pervasive.

BTW, immutable data in D is designed to be placed in ROM for embedded systems. 
So there's already a qualifier :-)


>> 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.
>
> actually peek/poke are not that different from atomicOp from a
> syntax perspective ;-)

That's correct.


> You'll still have to educate people about the difference.

Peek/poke has a 40 year history of being used for MMIO, and I've never heard of 
it being used for concurrency. I don't think there's endemic confusion, quite 
unlike volatile.