On 10/24/2013 9:30 PM, Mike wrote:
Using peek and poke functions is, well, nah... Better methods exist. Using
inline assembly is a reasonable alternative, as is linking to an external C
library, but why use D then? Is low-level/embedded software development a
design goal of the D language?
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.
