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
