DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Johannes Pfau via Digitalmars-d]

Am Tue, 15 Jul 2014 14:28:23 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 7/15/2014 1:43 PM, Johannes Pfau wrote:
> > But the problem there is that it produces quite some overhead right
> > now.
> 
> Are you sure? The compiler is pretty good at inlining trivial
> functions.

Yes, I actually tried tested that simple implementation with gdc. With
aggressive optimizations the code inlines just fine and it'll generate
the same asm as an access to a volatile variable in C. But it's not
space-effecient: Even if it inlines, the function is still in the
object file as a distinct function. There's TypeInfo and there's the
assert(this), there's an initializer symbol and I guess there could be
copy constructors as well. I expect many bug reports/fixes till we get
a Volatile!T wrapper to be really space-efficient.


I think if we decide that Volatile!T is the solution I'd probably hack
an attribute @TypeWrapper for gdc which simply recognized Volatile!T
and does the right thing. The 'standard D' option requires @forceinline
@noTypeinfo @noInitializer @noDebug and lots of boilerplate (all
opAssign methods have to be implemented as we don't rewrite RMW
operations into property get/set which also affects alias this to a
property).

> 
> >> 3. if you really hate peek/poke calls appearing in the code, you
> >> can use UFCS to make them look like variables
> > But you cant do REGISTER.peek() |= 0b1;
> 
> As you mentioned in the DIP, read-modify-write operations should be
> split up, as their semantics are murky.
> 
> 

But not necessarily in user code. REGISTER |= is quite common in C and
it's perfectly safe. If people will have to split this up into peek |=
poke that's a step backwards from C.


> > A few months
> > ago you suggested namespaces for D - in addition to modules - which
> > would have lead to a complexity disaster.
> 
> C++ namespaces are now implemented in D, and will they lead to
> complexity disaster? Certainly not in the implementation. For users?
> I don't think so, but we'll see.

You were initially in favor of an option which would have allowed to
use namespaces in D code as well (namespace A {}). The current
implementation is mostly limited to C++ so that's better, but my point
was that nobody cared about complexity back then.

> 
> > 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.
> 
> I don't think this is the right argument. It isn't about embedded
> systems should be acknowledged with a qualifier. I see it as about
> how often does MMIO logic appear in an actual embedded program? In
> the embedded systems I've written, it only appears in a handful of
> places. It is not pervasive.

But it's not only about frequency, it's also about convenience and
safety. How often is opDispatch actually used? The synchronized
statement? Nevertheless they are there, because someone thought these
use cases are important enough.

The perceived importance of a special qualifier for MMIO code is highly
subjective, but I think that most embedded programmers would say it's
necessary. In Andrei's Leverage talk he said (5:57): "Consider this:
Convenience, modeling power, efficiency: [...] You gonna have to have a
large language. This is a fact of life. [...]". We have
weak pure/ strong pure & immutable for functional programming, A
complete set of OO primitives, builtin unit tests, code coverage, ... I
think it's a correct argument to say that you think embedded system
programming is not important enough for the additional complexity
introduced by a new qualifier.