Subject: Re: Common Lisp and Python performance
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 3 Jan 2001 04:22:35 GMT
Newsgroups: comp.lang.lisp
Message-ID: <92u9eb$kbs8h$1@fido.engr.sgi.com>
Andy Freeman  <anamax@earthlink.net> wrote:
+---------------
| rpw3@rigden.engr.sgi.com (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"...


-Rob

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		rpw3@sgi.com
SGI Network Engineering		http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA