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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
