<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c11">Comment # 11</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126">bug 126</a>
from <span class="vcard"><a class="email" href="mailto:slavo5150@yahoo.com" title="Mike <slavo5150@yahoo.com>"> <span class="fn">Mike</span></a>
</span></b>
<pre>Ok, clearly I have not fully understood shared semantics.
<span class="quote">> In future, the compiler would memoize the loop and go straight for the
> assignment.
>
> mov $12, _D4test4globi(%rip)</span >
That would be very bad for my memory-mapped I/O needs.
<span class="quote">> Regarding peek/poke functions: Don't you think that's too cumbersome?
> I also think shared + peek/poke has the drawback that you can still
> accidentally access it like a normal shared variable, without the peek/poke
> guarantees.</span >
I do find it cumbersome, but I'm ok with it because I'll be wrapping it in a
mixin or a template. But you make a good point about "accidental" access.
<span class="quote">> BTW: I finally finished the volatile DIP, see <a href="http://wiki.dlang.org/DIP62">http://wiki.dlang.org/DIP62</a>.
> It'd be great to get some early feedback from you and Iain, and feel free to
> edit the DIP :-)</span >
The DIP is extremely well written. I've read it a couple of times and I'm
currently studying some of the references. I think you've made a very
compelling case for adding volatile semantics, and I support it, but I must be
honest, peek() and poke() intrinsics would also be fine for me (more about that
later). I'm under the impression, however, that this DIP will be a very tough
sell to Walter.
I've created a "design discussion" around this debate on the D wiki:
<a href="http://wiki.dlang.org/Language_design_discussions#volatile">http://wiki.dlang.org/Language_design_discussions#volatile</a>
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.
Walter said in the past that there is debate about what 'volatile' really means
(<a href="http://forum.dlang.org/post/l4afr7$2pj8$1@digitalmars.com">http://forum.dlang.org/post/l4afr7$2pj8$1@digitalmars.com</a>) and argues that
peek() and poke() intrinsics is the "correct and guaranteed way" to do
memory-mapped I/O (<a href="http://forum.dlang.org/post/l4abnd$2met$1@digitalmars.com">http://forum.dlang.org/post/l4abnd$2met$1@digitalmars.com</a>)
Daniel Murphy argued that it is property of the load/store operation and not
the variable (<a href="http://forum.dlang.org/post/l4b1j4$acl$1@digitalmars.com">http://forum.dlang.org/post/l4b1j4$acl$1@digitalmars.com</a>) 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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>