[Openmcl-devel] mcl-doubles problem in openmcl 0.14.1
gb at clozure.com
Wed Feb 18 18:18:16 PST 2004
On Wed, 18 Feb 2004 taube at uiuc.edu wrote:
> [This question comes from a colleague, Bill Schottstaedt: bil at ccrma.stanford.edu]
> In openmcl 0.14.1 of recent vintage, the code I'm using
> in mcl-doubles.cl to get the address of a double-float
> array no longer works:
> (defppclapfunction %df-vect-data-to-macptr ((vect arg_y) (ptr arg_z))
> ;;; put address of df-vect data in macptr - 1999-09-03TA
> (addi arg_y arg_y arch::misc-dfloat-offset)
> (stw arg_y arch::macptr.address arg_z)
Since a GC can happen on any instruction boundary, creating pointers
that point at lisp data is a very, very bad idea: the address of
the double-float vector can change between the ADDI and the STW.
The fact that the symbol MACPTR.ADDRESS isn't in the "ARCH" package
anymore has nothing to do with this; this can only work reliably
if you somehow know that the address of the double-float vector
won't ever change. How do you know that ? (Hint: you don't.)
> dies with the complaint that arch::misc-dfloat-offset is
> not defined. I checked the current source against a version
> about a month old, and it appears that that entire part of
> openmcl has been changed. I didn't see any obvious
> way to fix this.
The release notes for the 0.14-031220 release noted that the contents
and organization of internal implementation-layer packages ("ARCH",
"PPC", etc.) was likely to change in the near future and would be
volatile for a while. They have and will be.
If some of these internal symbols are currently accessible through
the "TARGET" package, there's a fairly good chance that they'll stay
All of these changes are intended to support a port to PPC64; not
all of the changes are completed yet. Until they are, it's very
hard to predict what else might change.
> What do I do now to pass a double-float array through
> the FFI to C?
There is no support for directly passing first-class lisp objects to
foreign code, and there are good (GC-related) reasons for this prohibition.
There never has been any such support: even before native threads were
implemented, the issue was pretty clear.
There are two alternatives:
a) if the arrays in question are fairly small, copy them:
(defmacro with-foreign-double-float-array ((ptr-var lisp-array) &body body)
(let* ((length (gensym)) (size (gensym)))
`(let ((,length (length ,lisp-array))
(,size (* ,length 8)))
(%stack-block ((,ptr-var ,size))
(dotimes (i ,length)
(setf (%get-double-float ,ptr-var (* i 8)) (aref ,lisp-array i)))
, at body))))
b) Create the lisp array as a less-than-first-class lisp object, "nailed
down" in the foreign heap. There isn't an exported interface to this,
but there probably should be.
> How to I distinguish which version of
> openmcl I'm compiling in (the two have the same version
The value returned by LISP-IMPLEMENTATION-VERSION differs with
> bil at ccrma.stanford.edu
> Rick Taube
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel