DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Johannes Pfau via Digitalmars-d]

Am Tue, 15 Jul 2014 21:07:21 +0000
schrieb "bearophile" <bearophileHUGS at lycos.com>:

> Johannes Pfau:
> 
> > Well as described in the DIP it works just like shared from an
> > implementation point of view, so I doesn't add much complexity 
> > in the compiler / type system.
> 
> I am reading blogs about compiler bugs, and I see that the 
> implementation of volatile is the buggiest part of GCC/Clang (and 
> the Intel and Microsoft compilers). Despite numerous bug fixes, 
> it's still a stubbornly buggy part. So it can't be as simple to 
> implement correctly as you say. volatile fights against the 
> optimization stages all the time. And I recognize that Walter has 
> a significant experience on this topic, perhaps higher than yours.
> 

And how do you think peek/poke are easier to implement in this regard?
You still have to be very careful with inlining, instruction
scheduling, etc.

The main benefit of a volatile type qualifier is that it's similar to
the C volatile qualifier, so all these bugs have already been fixed.
GDC/LDC could probably just map to the volatile C qualifier.
If we invent some homebrew solution we can start at zero with bug
fixing.

Also what does buggy mean if C doesn't have a clear specification about
volatile?

> 
> > This just shows the priorities of the project leads:
> > Desktop apps matter, we add @nogc, c++ namespaces, shared, 
> > immutable,
> > const, -cov, ...
> > but for embedded systems we won't even add one qualifier.
> 
> Having priorities is not something to be ashamed of. D has a GC, 
> works only on 32+ bits, and several of its features are not meant 
> for embedded systems. Even if you can restrict it for such 
> restricted memory and CPU usages, D is not designed primarily for 
> them.

Well as long as those priorities are clearly communicated. If you tell
me 'we don't care about embedded programming' then I'll shut up and move
back to C.
But 'D is a systems programming language for low level tasks' and 'we
don't want to introduce a type qualifier for low level programming, but
@nogc is just fine' don't go together. This leaves all contributors and
devs hoping to see D on embedded systems in uncertainty.