On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
Am Tue, 24 Jun 2014 10:46:11 +0000
schrieb "Timo Sintonen" <t.sinto...@luukku.com>:
To keep this thread going, I had a quick look at the reference
material of the dip and picked some thoughts.
In some languages volatile has a stronger meaning, like
guaranteeing an atomic access. In some languages it may not
guarantee anything.
In this proposal volatile is only for optimization, not for
protection. It does not add any code, it just prevents the
optimizer removing some code.
Agreed. In fact if this proposal reaches the main forum, we may
hear proposals to introduce a "don't optimize" pragma or some
other workaround. I considered it myself :(
Walter has been against this and now also Martin. I think
there is no use to bring this to the main forum. I understand
the point that it is not very good to have something in the
language specs that can not be guaranteed.
I think we should at least try to bring this to the main
newsgroup,
however I got distracted with other things and I want to extend
the DIP
a little (Only rationale stuff, no technical changes). The
newsgroups have been quite busy lately and there've been
discussions
about two new DIPs. Neither Andrei nor Walter even posted a
response
in these threads so now is probably not a good time to start the
discussion on this DIP.
Agreed, it would be a shame to not try. And looking for a low in
controversial topics on the main forum would probably be a good
idea. It would be bad for the passions of one discussion to
spill over into this one.
Walter told me at DConf that he was in favor of compiler
intrinsic peek/poke functions as proposed in DIP20 and he said,
in the meantime, I could get by with Martin's
volatileGet/volatileSet assembly workaround.
This tells me two things that are working against DIP62:
1) Walter believes volatile is a property of the load/store
operation.
2) He doesn't consider volatile semantics a big priority.
DIP20 has Walter's support, but has been collecting mold on the
DIP list for a year and a half. Getting DIP62 approved will be a
challenge, to put it mildly, but it will still need to be
implemented and accepted into DMD.
I was in favor of Walter's suggestion (DIP20) until DIP62. What
sold me on DIP62 was the fact that one would never want to access
volatile memory with non-volatile semantics. This is an
irrefutable truth, and, as I can tell, only a type qualifier can
enforce provide this enforcement.
DIP62 will also be a difficult sell given the simple assembly
workaround. I concede, the workaround will solve the problem and
is a trivial implementation, but as Iain said, it is "...an
excuse to *not* implement a feature that is rather essential for
a systems language".
I define a systems programming language as one that is generally
accepted and used to implement operating systems (kernels and
hardware drivers), and I think this is the traditional definition
before the language marketers redefined it. D currently requires
the help of C and/or other techniques to do this and lacks a
runtime suitable for such development, so it is not a systems
programming language IMO. But, out of all the other languages I
have encountered, D has the most potential of any to be the
systems programming language of choice in the future, and DIP62
is a step in that direction. The work of all those currently
participating on this thread also shows some encouraging momentum
in that direction.
Unfortunately, there just doesn't seem to be very many people
using D for systems programming, likely because of the reasons I
gave above, and this poses another hurdle for DIP62: volatile
has very little use outside of systems programming. DIP62 has my
support, but I know that doesn't mean much. It will likely need
the support of those with some clout in the D community.
Mike
