ARM bare-metal programming in D (cont) - volatile

[Russel Winder]

On Sun, 2013-10-27 at 02:12 -0700, Walter Bright wrote:
[…]
> Bitfield code generation for C compilers has generally been rather crappy. If 
> you wanted performant code, you always had to do the masking yourself.

Endianism and packing have always been the bête noir of bitfields due to
it not being part of the standard but left as compiler specific – sort
of essentially in a way due to the vast difference in targets. Given a
single compiler for a given target I never found the generated code
poor. Using the UNIX compiler in early 1980s and the AVR compiler suites
we used in the 2000s generated code always seemed fine. What's your
evidence for hand crafted code being better than compiler generated
code?

> I've written device drivers, and have designed, built, and programmed single 
> board computers. I've never found dealing with the oddities of memory mapped I/O 
> and bit flags to be of any difficulty.

But don't you find:

	*x = (1 << 7) & (1 << 9)

to lead directly to the use of macros:

	SET_SOMETHING_READY(x)

to hide the lack of immediacy of comprehension of the purpose of the
expression?

> Do you really find & and | operations to be ugly? I don't find them any uglier 
> than + and *. Maybe that's because of my hardware background.

It's not the operations that are the problem, it is the expressions
using them that lead to code that is the antithesis of self-documenting.
Almost all code using <<, >>, & and | invariable ends up being replaced
with macros in C and C++ so as to avoid using functions.

The core point here is that this sort of code fails as soon as a
function call is involved, functions cannot be used as a tool of
abstraction. At least with C and C++.

Clearly D has a USP over C and C++ here in that macros can be replaced
by CTFE. But how to guarantee that a function is fully evaluated at
compile time and not allowed to generate a function call. Only then can
functions be used instead of macros to make such code self documenting.

Much better to have a bitfield system that works. Especially on
architectures such as AVR where there are areas of bit addressable
memory. Although Intel only have words accessible memory, not all
architectures do.

C (and thus C++) hacked a solution that worked fine for the one compiler
with the PDP and VAX targets. It was only when there were multiple
compilers and multiple targets that the problem arose. There is nothing
really wrong with the C bitfield syntax it was just that different
compilers did different things for the same target.
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder