On Thu, Feb 29, 2024 at 01:01:45PM +0100, Grégory Vanuxem wrote:
> Hello,
>
> I hesitated to add this as an issue at GitHub.com (feature request), I
> put it here first.
>
> FriCAS supports what I would call preliminary support of FFI stuff via
> a set of CL macros. I would like to suggest adding more types in this
> regard. For example, it could be possible to add double-float arrays,
> boolean and the like. I modified, and well tested, the following for
> example. For information, only for SBCL and Clozure CL, but adding
> those additional types for other CL implementations should be easy I
> think:
Well, there are some things which are easy, but a limited use, like
adding 'void' or 'boolean' (but even boolean is not entirely
strightforward, as one needd to know corresponding C type, which
in principle could be 32-bit integer (I did not check what it is
in various implementations, but AFAICS C compiler can choose size
that it finds most convenient)).
IMO before going forward with implementation we should first
define what FFI should do. One basic question is "who owns
the data". sbcl FFI slightly prefers variant when C code
owns data. This avoid memory management by Lisp implementation.
But it also means that memory management is user responsibility.
This may be acceptable when you want to use existing C library
which requires manual memory management anyway. But for me
_main_ use case is using C code as fast "primitives" that
operate on Lisp data.
Concerning Lisp arrays, some years ago Clozure CL folks claimed
that the only correct way to pass Lisp arrays is to create temporary
copy in specially allocated memory and pass that to C code.
Basically, Clozure CL can move normal Lisp objects at any time, so
C code is not allowed direct access to Lisp data. In sbcl there is
'with-pinned-objects' which solves this problem. ECL does not moves
Lisp object (for ease of C interface) so no trouble here. IIUC GCL
has special "non-movable" allocation for things that are passed via
FFI, but with if we want freely pass Lisp arrays to FFI we would have
to allocate all of them in non-movable way and it is not clear to me
if this would fly if we allocate _all_ arrays in non-movable way. For
Clisp it seems that we need to copy. Poplog has similar approach to
GCL: there is non-movable pool of allocations for FFI.
So, one issue is how we properly pass Lisp objects to C. Note:
passing test do not really tell you if the code is correct. AFAIK
Lisp moves object during garbage collection, so to get bad behaviour
there are several conditions. Murphy says that such conditions will
never happen during test but only when what you compute is important
enough.
Another issue is how to specify foreign routines and foreign types
in Spad. One possiblity is modified 'import' statement. Minimally
one need here ablity to specify type. But frequently when using
FFI foreign name is different that the name we would like to use
in Spad, so probably we should add optional renaming. Instead
of 'import' statement we could try to add "foreign packages",
that is use normal package heading to specify types and add
some magic token like "Foreign('C)" as implementation so that
Spad compiler knows that is should create foreing calls for
all functions.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZeEiXyqdZimJz5ee%40fricas.org.
