[Openmcl-devel] mcl-doubles problem in openmcl 0.14.1

[Gary Byers]

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)
>     (blr))

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
there.

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
> number).
>

The value returned by LISP-IMPLEMENTATION-VERSION  differs with
each release.

> bil at ccrma.stanford.edu
>
> ---
>
> Rick Taube
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>