[Bug 126] Add support for attribute to mark data as volatile.

[Mike Franklin via D.gnu]

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.sintonen at 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