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

[Russel Winder]

On Fri, 2013-10-25 at 13:04 -0700, Walter Bright wrote:
[…]
> I've written device drivers and embedded systems. The quantity of code that 
> deals with memory-mapped I/O is a very, very small part of those programs. The 
> subset of that code that needs to exactly control the read and write cycles is 
> tinier still. (For example, when writing to a memory-mapped video buffer, such 
> control is quite unnecessary.)
> 
> Any of the methods I presented are not a significant burden.
> 
> Adding two lines of inline assembler to get exactly what you want isn't hard, 
> and you can hide it behind a mixin if you like.
> 
> And, of course, you'll still need inline assembler to deal with the other 
> system-type operations needed for embedded systems work. For example, setting up 
> the program stack, setting the segment registers, etc. No language provides 
> support for them outside of inline assembler or assembler intrinsics.

My experience, admittedly late 1970s, early 1980s then early 2000s
concurs with yours that only a small amount of code requires this read
and write behaviour, but where it is needed it is crucial and in areas
where every picosecond matters (*). I disagree with your point about
memory video buffers as a general statement, it depends on the buffering
and refresh strategy of the buffer. Some frame buffers are very picky
and so exact read and write behaviour of the code is needed. Less so now
though fortunately.

Using functions is a burden here if it involves a function call, only
macros are feasible as units of abstraction. Moreover this is the
classic approach to inline assembler some form of macro so as to create
a comprehensible abstraction.

The problem with inline assembler is that you need versions for every
target architecture making it a source code and build nightmare. OK
there are directory hierarchy idioms and build idioms that make it
easier (**), but inline assembler should only really be an answer in
cases where there are hardware instructions on a given target that it
cannot reasonable be expected that the compiler can generate from the
source code. Classics here are the elliptic function libraries, and the
context switch operations.

So the issue is not the approach per se but how that is encoded in the
source code to make it readable and comprehensible AND performant.

Volatile as a variable modifier always worked for me in the past but it
got bad press and all compiler writers ignored it as a feature till it
became useless. Perhaps it is time to reclaim volatile for D give it a
memory barrier semantic so that there can be no instruction reordering
around the read and write operations, and make it a tool for those who
need it. After all no-one is actually using for anything just now are
they? 


(*) OK a small exaggeration in late 1970s where the time scale was 18ms,
but you get my point.

(**) Actually it is much easier to do with build tools such as SCons and
Waf than it ever was with Make, and the GNU "Auto" tools (especially on
Windows), and even CMake.

-- 
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