James Bielman  <jamesjb@jamesjb.com> wrote:
+---------------
| > rpw3@rpw3.org (Rob Warnock) wrote:
| >> You want scary? I'll give you scary! Try peeking & poking hardware
| >> registers from within CMUCL, heh-heh!  MMAP some hardware into your
| >> VM and then do (setf (system:sap-ref-32 (system:int-sap addr) 0)
| >> new-value) [which in C is "*((u32*)(addr)+0) = new-value"]. I have a
| >> whole toolkit of such low-level hacks that I use to do user-mode
| >> debugging of hardware at my current POE.
| 
| FWIW, the CFFI library is largely implemented in terms of a low-level
| interface like this.  It could be useful for doing this sort of
| unsavory pointer manipulation in multiple implementations...
+---------------

Yes, possibly, if anybody wanted to do it with multiple implementations.
In my experience, when doing really low-level stuff like this one tends
to pick one implementation and stick with it unless some really major
problem pushes you off it.

But you might be right if one comes at it from a different angle.
I view such low-level hacks not so much as a "library" as a "pattern"
[in the Gabriel/Alexander sense, not in the GoF "pattern=class" sense].
I've implemented "r32/w32/dump32/mmap/mpin/etc." in Tcl, SCM, MzScheme,
and CMUCL. [So far...]  Yes, there might be a group of CL's for which
CFFI is a useful implementation technique for this pattern. But the
usefulness of the pattern (INHO) is broader than any single FFI or
even any single language.

+---------------
| Rob's expression above looks like this in CFFI:
|    (setf (mem-ref (make-pointer addr) :int) 0)
+---------------

Uh... Not quite. Look again at what I wrote. CMUCL's SYSTEM:SAP-REF-32
takes *two* arguments, a SAP and a fixnum offset. I think you probably
meant this:

     (setf (mem-ref (make-pointer (+ addr 0) :int) new-value)

or given the constant 0, this:

     (setf (mem-ref (make-pointer addr) :int) new-value)


-Rob

p.s. When I said "my current POE" above, I merely meant that I'm
doing user-mode debugging of hardware there recently with CMUCL.
But I've been doing user-mode debugging of hardware & user-mode
driver development as long as I've been in computing, all the
way back to 1970 on a PDP-10! Some of the user-mode drivers even
*stayed* in user mode, never making it into the kernel [no need].
(But the PDP-10's "user-mode I/O" and "realtime" features were
quite advanced. Unix/Linux could *still* learn from them...)

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607