DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 15 10:48:12 PDT 2014


Am Tue, 15 Jul 2014 17:42:47 +0000
schrieb "Kagamin" <spam at here.lot>:

> On Tuesday, 15 July 2014 at 17:13:09 UTC, Johannes Pfau wrote:
> > 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?
> 
> Maybe it can be automated by a wrapper template?
> 
> struct Volatile(T)
> {
>    T val;
>    void opAssign(T v)
>    {
>      volatile_store(val, v);
>    }
> }
> 
> extern(C) Volatile!byte led;
> 
> foreach(i;0..10)
> {
>    led=0;
>    led=1; //blink
> }

Then we have a templated struct. Which generates TypeInfo for every
instance. Which might generate an Initializer for every instance and
it might generate extended debug info for every instance.

These are exactly the kind of workarounds I don't want. Sure we can
make it work: @noTypeInfo @noInit @noDebug (struct volatile). But then
I don't see why we don't just use the proposal in this DIP. It's less
complicated, has got fewer corner case, ...

And that's why I say first class support: We don't have shared!(T) we
have shared T. And volatile should get it's own qualifier as well.

Also some things will just not work with Volatile!T, for example
volatile/nonvolatile member function overloading.


More information about the Digitalmars-d mailing list