DIP62: Volatile type qualifier for unoptimizable variables in embedded programming

[Steve Sobel via Digitalmars-d]

On Tuesday, 15 July 2014 at 21:28:24 UTC, Walter Bright wrote:
> 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.
>
> BTW, immutable data in D is designed to be placed in ROM for 
> embedded systems. So there's already a qualifier :-)

I just wrote some embedded code for a Bluetooth LE
microcontroller. The MCU in question has no less than 25 separate
peripheral systems, each with its own set of registers, which use
MMIO for configuration and operation. Just one of the header
files provided by the chip vendor for this SoC defines 524
volatile variables. I'm sure that this complexity is barely
anything compared to, say, the SoCs found in smart phones.

Of course, one confines MMIO accesses to one layer of the
program. Even so, that layer can be very broad given the sheer
amount of stuff it has to touch - potentially many thousands of
lines of code. With the code leverage that D has, I would not be
surprised if this made up 10% or more of an embedded program's
size.

Also, there are many ways to misconfigure these peripherals and
produce an effect physically similar to a compiler-eliminated
access. A single omission of peek() or poke() could take hours to
track down if one is unfortunate. If one is having trouble, for
example, with the bluetooth radio, it could be due to:

   - An illegal configuration amongst the many registers touching
BTLE
   - A legal configuration which is not accepted by the other
device (e.g. causes a timeout)
   - The chip is damaged
   - The other device is damaged
   - The other device has a bug
   - The compiler eliminated access to the BTLE control registers

Finally, the compiler could have eliminated access to other
registers that had a side-effect on the BTLE code (for example,
eliminating configuration of the memory protection unit). These
would probably be incredibly pernicious because the true error is
not in the code that has broken, and could feasibly be in any of
a large number of systems. I certainly would not have a lot of
fun scanning thousands of lines of code for a mistaken omission
of peek() or poke().

So in my opinion, and without prescribing the exact solution,
volatility is an important enough concept in embedded to merit a
standard solution that can be mechanically verified.