Andy Freeman <email@example.com> wrote:
| firstname.lastname@example.org (Rob Warnock) wrote:
| > You have to tell it. That's what the ANSI C "volatile" attribute is
| > all about.
| That's what I thought, which prompted my question about a compiler
| that supposedly figured it out on its own.
Well, if you're "just" worried about threads and software interrupts
(Unix signals known to the C compiler & runtime), I suppose a
sufficiently-globally optimizing compiler could perhaps "figure out
on its own" the side-effects *within* a single process, but how could
you *possibly* expect the compiler to understand *DMA* into the process's
address space without telling it explicitly??!?
This is not idle speculation. While doing hardware bringup & debugging,
I have written plenty of user-mode C programs which mpin'd some of their
pages in physical memory, found out where they were, and passed those
addresses (via PIOs to mmap'd /dev/mem which hit the bus) to devices
which then did DMA to/from those regions. And yes, I had to be very
careful to declare those areas "volatile"...
p.s. One also has to be *very* careful to catch interrupts (e.g., ^C)
so that the DMA can be shut *off* before the process exits [and the
pinned pages automatically get put back in the system pool!], otherwise
you leave a device doing DMA all over some *other* process's address
space!! [Not good. Not good at all.]
Anyway, to bring this back on-topic, I should imagine that Lisp-based
device drivers must have some way to ensure that the GC won't move DMA
buffers while the device is still active, yes?
Rob Warnock, 31-2-510 email@example.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA