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.
