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

[Walter Bright]

On 10/28/2013 1:13 AM, Russel Winder wrote:
> 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.

I've not only built my own single board computers with video buffers, but I've 
written code for several graphics boards back in the 80's. None needed exact 
read/write behavior.

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

If you want every picosecond, you're really best off writing a few lines of 
inline asm. Then you can craft exactly what you need.


> The problem with inline assembler is that you need versions for every
> target architecture making it a source code and build nightmare.

When you're writing code for memory-mapped I/O, it is NOT going to be portable, 
pretty much by definition! (Are there any two different target architectures 
with exactly the same memory-mapped I/O stuff?)


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

Ask any two people, even ones in this thread, what "volatile" means, and you'll 
get two different answers. Note that the issues of reordering, caching, cycles, 
and memory barriers are separate and distinct issues. Those issues also vary 
dramatically from one architecture to the next.

(For example, what really happens with a+=1 ? Should it generate an INC, or an 
ADD, or a MOV/ADD/MOV triple for MMIO? Where do the barriers go? Do you even 
need barriers? Should a LOCK prefix be emitted? How is the compiler supposed to 
know just how the MMIO works on some particular computer board?)