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

[via D.gnu]

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

--- Comment #12 from Johannes Pfau <johannespfau at gmail.com> ---
> I've created a "design discussion" around this debate on the D wiki:  
> http://wiki.dlang.org/Language_design_discussions#volatile

Thanks, that's very useful. I did not even remember that we already had DIPs
for peek/poke functions.

> I'm under the impression, however, that this DIP will be a very tough sell to 
> Walter.

Regarding the old discussions I have to agree. But I think we need to make
using volatile memory as simple or even simpler as in C. The Hello World of
embedded programming is blinking a LED. If a C programmer sees something like
poke(addr, peek(addr) | 0b1); to set a bit in a register they'll probably
discard D immediately. I think this is a really important point.

> If we are to lobby the core design team to accept this DIP it would probably 
> be wise to review past discussions and prepare offensive and defensive 
> arguments.

Yes, that's a good point. I'll revisit these old discussions and make some
notes or update the DIP.

> Walter said in the past that there is debate about what 'volatile' really 
> means (http://forum.dlang.org/post/l4afr7$2pj8$1@digitalmars.com)

Fortunately with this DIP this should no longer be a valid point. In the end
what C does or did does not matter as long as we clearly specify what volatile
is supposed to do in D and I think the "Effects of volatile on code generation"
should describe all guarantees a compiler needs to provide.

> and argues > that peek() and poke() intrinsics is the "correct and guaranteed > way" to do memory-mapped I/O (http://forum.dlang.org
> /post/l4abnd$2met$1 at digitalmars.com)

Well, that's not an argument ;-) It's also easy to prove wrong, nobody uses
peek/poke on AVR, MSP430, ARM so it's probably not as undisputed as Walter
claims.

> Daniel Murphy argued that it is property of the load/store operation and not 
> the variable (http://forum.dlang.org/post/l4b1j4$acl$1@digitalmars.com) and, 
> I think this is the core of the debate.
> DIP62 makes a compelling case for why 'volatile' should be a property of the 
> type, but I think it would help to justify why 'volatile' is not a property 
> of the load/store operation.  I can actually see it both ways, and am 
> therefore somewhat on the fence.

Yes, this is an important point and I'll extend the DIP a little in this
regard.
I think the point that you must _always_ access such memory obeying volatile
rules shows why it is a property of the memory and not the access. There's no
reasonable example where you want one access to the same location to be
volatile and another time not. It's even dangerous sometimes (DIP 4.2.2).

One other way to think about it is that all 'only the access is volatile'
arguments apply in exactly the same way to 'shared' or 'immutable' variables.
Only the access is ever affected, cause in the end that's the only thing you
can do with variables. But we nevertheless have shared and immutable
qualifiers, simply because we want this memory to be _always_ accessed in
threadsafe/readonly ways, and it's exactly the same for volatile.

Another point is that using peek/poke without a special qualifier relies only
on conventions to ask programmers to always use the correct functions to access
a pointer, the type system doesn't help. People already admitted this was the
biggest mistake of D's volatile statement and I don't see how peek/poke would
be different in this regard.

And of course without a type qualifier there can't be transitivity. The
programmer always has to be careful to access struct members, array members,
and other types 'connected' via indirection with peek/poke.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20140602/b765bb7f/attachment.html>