Static vectors suitable for FFI

Attached is an implementation for SBCL. make-static-vector only
allocates instances of (simple-array (unsigned-byte 8) (*)) but that can
be extended to other unboxed arrays.
The current sharable vector interface doesn't work very well because it
doesn't allow me for instance to pin a list of vectors, but only a
single vector at a time. Also, I'd prefer to avoid pinning at all given
how it interferes with the GC.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.

(in-package :cffi)

(declaim (inline fill-foreign-memory))
(defun fill-foreign-memory (pointer length value)
  "Fill LENGTH octets in foreign memory area POINTER with VALUE."
  (declare (sb-ext:muffle-conditions sb-ext:compiler-note))
  (sb-kernel:system-area-ub8-fill value pointer 0 length))

(declaim (inline copy-foreign-memory))
(defun copy-foreign-memory (src-ptr dst-ptr length)
  "Copy LENGTH octets from foreign memory area SRC-PTR to DST-PTR."
  (sb-kernel:system-area-ub8-copy src-ptr 0 dst-ptr 0 length))

(defconstant +array-header-size+ (* 2 sb-vm:n-word-bytes))

(defun make-static-vector (size)

Re: Static vectors suitable for FFI

Stelian Ionescu <stelian.ionescu-zeus <at> poste.it> writes:

> Attached is an implementation for SBCL. make-static-vector only
> allocates instances of (simple-array (unsigned-byte 8) (*)) but that can
> be extended to other unboxed arrays.
> The current sharable vector interface doesn't work very well because it
> doesn't allow me for instance to pin a list of vectors, but only a
> single vector at a time. Also, I'd prefer to avoid pinning at all given
> how it interferes with the GC.

Thanks Stelian!

This would be really useful as the pinning business with
shareable-byte-vectors is a real nuisance.

If the current shareable-byte-vector interface is going to be reworked
can I suggest that we allow (at least) simple-array
single-float/double-float as well? Why not just allow all unboxed array
types the underlying Lisp supports? . . . Or a limited sensible subset?

Having portable unboxed C-sharable float arrays would be great for our
numeric work.

I should be very happy to make the Allegro CL interface.

Re: Static vectors suitable for FFI

On Thu, 2009-05-07 at 11:00 +0900, John Fremlin wrote:
> Stelian Ionescu <stelian.ionescu-zeus <at> poste.it> writes:
> 
> > Attached is an implementation for SBCL. make-static-vector only
> > allocates instances of (simple-array (unsigned-byte 8) (*)) but that can
> > be extended to other unboxed arrays.
> > The current sharable vector interface doesn't work very well because it
> > doesn't allow me for instance to pin a list of vectors, but only a
> > single vector at a time. Also, I'd prefer to avoid pinning at all given
> > how it interferes with the GC.
> 
> Thanks Stelian!
> 
> This would be really useful as the pinning business with
> shareable-byte-vectors is a real nuisance.
> 
> If the current shareable-byte-vector interface is going to be reworked
> can I suggest that we allow (at least) simple-array
> single-float/double-float as well? Why not just allow all unboxed array

That can be easily done.

> types the underlying Lisp supports? . . . Or a limited sensible subset?

I think that we should allow all types supported by the underlying
implementation but specify in the docs that very few are portable:
(probably, I haven't yet checked) only bit, [un]signed-byte-{8,16,32,64}
and single-float are portable

> Having portable unboxed C-sharable float arrays would be great for our

Re: Static vectors suitable for FFI

Stelian Ionescu <stelian.ionescu-zeus <at> poste.it> writes:
[...]
>> This would be really useful as the pinning business with
>> shareable-byte-vectors is a real nuisance.
>> 
>> If the current shareable-byte-vector interface is going to be reworked
>> can I suggest that we allow (at least) simple-array
>> single-float/double-float as well? Why not just allow all unboxed array
>
> That can be easily done.

Indeed. 

A better alternative to shareable byte-vectors is absolutely a good
idea.

Can you post the revised proposed interface? 

Can ClozureCL handle it, or does it need to be modified?

>> types the underlying Lisp supports? . . . Or a limited sensible subset?
>
> I think that we should allow all types supported by the underlying
> implementation but specify in the docs that very few are portable:
> (probably, I haven't yet checked) only bit, [un]signed-byte-{8,16,32,64}
> and single-float are portable

I guess double-float is more portable than [un]signed-byte-64 (not sure).

>> Having portable unboxed C-sharable float arrays would be great for our

Bus error ... ?! Help, please ...

Hi all:

While resurrecting Kenny Tilton's Cello and trying to reuse some code  
of the cl-opengl bindings (trying to unite the two) I came across this  
error:

Source:

(define-foreign-library OpenGL
   (:darwin (:framework "OpenGL"))
   (:windows "opengl32.dll" :calling-convention :stdcall)
   (:unix (:or "libGL.so" "libGL.so.2" "libGL.so.1")))

(use-foreign-library OpenGL)

(define-foreign-library GLU
   (:windows "glu32.dll")
   ((:and :unix (:not :darwin)) (:or "libGLU.so.1" "libGLU.so"))
   ((:not :darwin) (:default "libGLU")))

(use-foreign-library GLU)

(defconstant GL_VERSION #x1f02)
(defctype GLenum :unsigned-int)

(defmacro defglfun ((cname lname) result-type &body body)
   `(progn
      (declaim (inline ,lname))
      (defcfun (,cname ,lname :library OpenGL) ,result-type , <at> body)))

Re: Bus error ... ?! Help, please ...

Frank Goenninger wrote:

> Oh, btw, that happens no matter what function from OpenGL I try to
> call... So, something very fundamental must be wrong here. I just
> can't see what ... Please help!

Have you asked gdb for help, too?

  Leslie

--

-- 
http://www.linkedin.com/in/polzer

Re: Bus error ... ?! Help, please ...

Am 08.05.2009 um 15:43 schrieb Leslie P. Polzer:

>
> Frank Goenninger wrote:
>
>> Oh, btw, that happens no matter what function from OpenGL I try to
>> call... So, something very fundamental must be wrong here. I just
>> can't see what ... Please help!
>
> Have you asked gdb for help, too?
>
>  Leslie

Hadn't until you asked. But now I have. I started AllegroCL with

$ alisp

and then loaded my system via ASDF.

CL-USER > (asdf 'cello-nx)

... messages as expected ...

CL-USER >

At this point I started gdb and attached to the process. After  
enabling out logging I continued the alisp process.

CL-USER > (cello-nx::gl-get-version)

Fwd: Bus error ... ?! Help, please ... Additional info

In addition to the GDB session below I tried some more analysis on the  
Lisp side:

CL-USER> (foreign-symbol-pointer "glGetError")
2510410464
CL-USER> (foreign-funcall-pointer (foreign-symbol-pointer  
"glGetError") () :void :unsigned-int)
Received signal number 10 (Bus error)
...

I admit I am out of clues as to what I should analyse further ...

Frank

Anfang der weitergeleiteten E-Mail:

> Von: Frank Goenninger <frgo <at> me.com>
> Datum: 8. Mai 2009 19:08:23 MESZ
> An: cffi-devel <at> common-lisp.net
> Kopie: leslie.polzer <at> gmx.net
> Betreff: Re: [cffi-devel] Bus error ... ?! Help, please ...
>
> Am 08.05.2009 um 15:43 schrieb Leslie P. Polzer:
>
>>
>> Frank Goenninger wrote:
>>
>>> Oh, btw, that happens no matter what function from OpenGL I try to
>>> call... So, something very fundamental must be wrong here. I just
>>> can't see what ... Please help!

Re: Fwd: Bus error ... ?! Help, please ... Additional info

Am 08.05.2009 um 20:30 schrieb Mark Hoemmen:

> Frank Goenninger wrote:
>> In addition to the GDB session below I tried some more analysis on  
>> the
>> Lisp side:
>>
>> CL-USER> (foreign-symbol-pointer "glGetError")
>> 2510410464
>> CL-USER> (foreign-funcall-pointer (foreign-symbol-pointer
>> "glGetError") () :void :unsigned-int)
>> Received signal number 10 (Bus error)
>
> Wouldn't a "get" function either take or return a pointer?  Perhaps
> you're passing data of the wrong size that's getting interpreted as a
> pointer and then clobbered.
>
> mfh

Not really in this case. The function glGetError is defined as

GLenum glGetError(void);

So, no arguments passed. Just an unsigned int returned (that's what  
GLenum is typedef'ed to).

Cheers
    Frank

Re: Fwd: Bus error ... ?! Help, please ... Additional info

Frank Goenninger wrote:
> In addition to the GDB session below I tried some more analysis on the  
> Lisp side:
> 
> CL-USER> (foreign-symbol-pointer "glGetError")
> 2510410464
> CL-USER> (foreign-funcall-pointer (foreign-symbol-pointer  
> "glGetError") () :void :unsigned-int)
> Received signal number 10 (Bus error)

Wouldn't a "get" function either take or return a pointer?  Perhaps
you're passing data of the wrong size that's getting interpreted as a
pointer and then clobbered.

mfh