Am Tue, 15 Jul 2014 19:44:51 +0200 schrieb Artur Skawina via Digitalmars-d <digitalmars-d@puremagic.com>:
> On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote: > > Am Tue, 15 Jul 2014 19:03:52 +0200 > > schrieb Artur Skawina via Digitalmars-d > > <digitalmars-d@puremagic.com>: > > > >> Compiler barriers are not "workarounds". "volatile" is not a > >> "better solution". It's used in C only because it's defined and > >> reasonably portable; barriers are a language extension, hence > >> dialect specific. > >> > >> First class support for "embedded programming" would be defining > >> barriers, not transplanting C's volatile. You can already express > >> all the described volatile semantics in GDC's D dialect, in a > >> completely portable way and without using a single asm instruction. > >> What's missing is just a defined standard interface which can be > >> supported by all D compilers. > > > > Did you even read the section that explains why volatility is a > > property of the memory address and not of the access (4.2.3)? > > What's your response to that? > > You're assuming that the raw memory needs to be exposed. It doesn't. > > IOW, instead of: > > struct HWRegs { uint a; uint b; /*...*/ } > auto ptr = cast(HWReg*)0xc0000000; > > do: > > struct HWRegs { uint a; uint b; /*...*/ } > auto ptr = cast(Volatile!HwRegs*)0xc0000000; You didn't say anything about a template in your last response. See my reply to Kagamin: - Template bloat: TypeInfo, Initializer, DebugInfo - Requires inlining to produce decent results - Requires force inlining: You wouldn't want any method implementations of Volatile to actually end up in object files. > > and the Volatile template will magically add all the access barriers. > > > Why do shared variables have the privilege to prevent accessing > > shared memory in inappropriate ways but it's fine to place the > > burden of checking that all accesses to volatile memory are backed > > by compiler barriers to the user? How is that 'first class' support? > > See above; just don't expose mmapped regs as normal memory. This is not only for mmaped regs. It's also for memory used in interrupt handlers with indirection. > I have > not seen any good argument for introducing a volatile type qualifier. > Could you show one (concrete) example where using 'volatile' is better > than my approach? > For one thing we should not dictate usage patterns (like don't expose raw memory) on users. Then volatile is very simple for every compiler to implement and optimize, your idea requires multiple pragmas/attributes to make sure there's no bloat and inlining always works. (For example, in gcc even a force inline attribute does not inline if -finline is not used. I don't consider that acceptable for this kind of code. So we might have to special case Volatile!T even more in the compiler, to really always inline) Otherwise Volatile!T is OK, but it's a new, fancy idea and might need lots of work, whereas a volatile qualifer could be implemented easily and we know right now for sure that it'll work 100% as expected.