http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #12 from Johannes Pfau <johannesp...@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...@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.
