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.
