Re: CLISP support for a new portable FFI library

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,
James Bielmann wrote:

>Accessor: %MEM-REF ptr type &optional (offset 0)
-- That remembers me of mem-read in my AFFI.
for offset 0:
(ffi:sort-of-foreign-value (ffi:foreign-variable ptr <converted-type>))
for non-zero offset:
(ffi:sort-of-foreign-value
 (ffi::%offset (ffi:foreign-variable ptr <any-type>) offset <converted-type>))
-- which could be made more efficient if need be.

foreign-variable requiries clisp>2.33.2. If you don't have something that new, contact me (or search the clisp-list archives for keywords like cast% or foreign-variable or with-foreign-object).

I wrote <sort-of-foreign-value> to stress that your spec. is underspecified w.r.t. to the exact value. More precisely, it's not yet underspecified, because it only knows about some immediate types like int, single-float and (untyped) :pointer, so ffi:foreign-value fits the bill, but no struct or union types and pointers to such beasts, which start to make UFFI with CLISP a challenge.

http://www.jamesjb.com/cffi-sys-specification.html

I recently reinforced my opinion that what's needed is more high-level specifications of FF. With high-level declarations, there's a chance that these can be turned into efficient code on all implementations.
Whereas with CLISP, if CFFI code translates to lots of nested primitive %MEM-REF invocations and bytecode, it would be potentially slowed down stronger than implementations compiling to native code.

OTOH, so far, my UFFI wrappers are oriented towards maximum performance.  Running the cl-sdl demos, CLISP and cmucl show the exact same fps rate, which shows that the FFI or even the Lisp is not the bottleneck in at least the cl-sdl demos.

Yet UFFI user code is full of contorted stuff causing extra code that's useless in clisp, consuming time and space. If UFFI had a high-level API, that could IMHO be avoided.


>It looks to me like it is necessary when using DEF-CALL-OUT to specify
>the library name each time a foreign function that is to be found in a
>shared library is defined.
UFFI also mentions Lispworks as requiring the :module parameter, so CLISP is not alone.

>In order to implement %FOREIGN-FUNCALL compatibly with other Lisps
a) better provide for a module name directly, or you'll get trouble with Lispworks as well;
b) CLISP can be made not to require a module name, but so far, we (me at least) prefer it that way, as it is more portable and has less restrictions! (in this particular point I'll change something in the future).


>The implementation is also missing a %LOAD-FOREIGN-LIBRARY function,
>which I couldn"t find a public interface for in CLISP.
I plan to export FFI::foreign-library.
AFAIK, foreign-library-close is already exported.

>Currently I lean toward not requiring NAME to be a full path to
>the library so we can search the system library directories
Why repeat functionality that's just built into many OS?
Edi Weitz is just proposing a patch to UFFI to let the OS search the library.


>There are a few operators that I didn"t figure out how to implement
>for CLISP (quoting from the spec):
>Macro: %FOREIGN-FUNCALL name {arg-type arg}* &optional result-type
Maybe two steps
a) define function
b) invoke it
Or expand to
(funcall
 (ffi:foreign-function
  (ffi::foreign-library-function
   name (ffi::foreign-library name)
   nil (ffi:parse-c-type '(c-function :arguments ... :return-type ...))))
 args...)
Look at (macroexpand-1'(ffi:def-call-out ...)) for insights.

Please insert appropriate LOAD-TIME-VALUE to try to separate things that change upon each call from constant stuff (the AMOP book if full of showing the value of doing so). Or read the AMOP and separate the constant cases from the varying path, e.g. creating a foreign function (proxy) object from invoking it.


Regards,
	Jorg Hohle.