DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Mike via Digitalmars-d]

On Tuesday, 15 July 2014 at 21:57:56 UTC, Walter Bright wrote:

> Rest assured we definitely do care about embedded systems 
> programming.

That's most encouraging to read! D has a lot of potential for 
embedded programming, we just need to be thrown a few bones.

> It isn't about whether we want to introduce a type qualifier 
> for low level programming or not. It is about what is the best 
> solution for MMIO for low level programming.

Exactly, and I think a type qualifier is the right tool for the 
job.  I was all in favor of peek/poke after our brief 
conversation at DConf, but DIP62 sold me on a type qualifier... 
see below.

> Note that D already supports inp() and outp() as compiler 
> intrinsics, adding peek() and poke() will complement them 
> nicely:

OT:  Isn't inp/outp and Intel-only thing, though?

DIP62 addressed why peek/poke are not the right tool for the job 
in the "why a type qualifier" section.  In summary, one would 
never want to access volatile memory with non-volatile semantics, 
and a type qualifier is the only proposal I've seen that enforces 
that:  peek/poke intrinsics do not.

The Volatile!(T) workaround is proof that peek/poke is not the 
right tool.  The Volatile!(T) workaround is a jerry-rig on top of 
peek/poke to provide what a 'volatile' type qualifier would 
provide, and is necessary because the language lacks the proper 
tool.

 From what I've read in this thread, I suspect you favor peek/poke 
due to the complexity it introduces into the implementation. If a 
'volatile' type qualifier was a trivial implementation, and did 
not introduce complexity into implementation, would your position 
be different?

I and the others in favor of DIP62 will likely concede the 
following:
* Workarounds exist
* The workarounds are not overly burdensome
* 'volatile' as defined by DIP62 would not be a pervasive feature 
of the language with high leverage.  It is only used in the low 
level hardware abstractions (i.e. systems programming)

...but that's beside the point.

I remember watching a talk you gave where you compared code with 
an airplane, and how when you get it right, it just looks like it 
wants to fly.  I don't know how many people got that, but I sure 
did.

peek/poke delegates responsibility to the programmer, as at every 
usage s/he must make sure they employ it properly to beat their 
code into flying.  Volatile!(T) is an inelegant lever to make 
peek/poke more less prone to disobedience.

A type qualifier is an elegant tool for modeling one's hardware 
because at every usage, it already knows how, and wants to fly.


Mike