Subject: [clisp-list] FFI , UFFI and extensions (was: array of strings?)

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Fri Feb 27 00:44:06 2004

Hi,

Sam wondered:
>does this mean that CLISP will support UFFI-2 automatically?
Nope. 1. Somebody has to do a porting job.
2. Kevin Kosenberg and possibly others has to be convinced that something very close to CLISP is the perfect candidate for UFFIv2. For now, UFFIv2 is possibly not more than a word (trademark :-).

>>>>>(setq z (allocate-shallow '(c-array char 1000)))
>I get #(97 110 115 32 61 10 32 32 49 46 50 50 52 54 101 45 48 49 54 10)
>yuk.
1. Oops, there's that difference between ffi:character and ffi:char...
2. you should have gotten 1000 signed bytes out of c-array, not the above 20. 

>> I don't understand why. No user of the other Lisps would write C
>> code.
>to avoid FFI overhead you mention below.
From the Amiga POV, writing C code to interface to existing dynamic libraries is unacceptable. Similarly, I don't want to have to add C stubs to interface to existing shared libraries on UNIX or MS-Windows -- unless the addtional performance is beneficial. The idea is: the library, the Lisp system is there, just combine the two and run (no intermediate Makefiles, C compilation, link kits, separate memory images). I still know how to use CLISP extensions with just a unique image file.

>Do you think AFFI is more appropriate as the UFFI substrate?
I think I already said no in clisp-devel. I expressed the idea that AFFI *only* provides a low-level layer, on which lots of things (except callbacks) can be built (like any good low-level layer provides for seemless topping).
BTW, how current are sf's mailing archives??

I recommend using the FFI for UFFI, and possibly enhance some issues (e.g. better variable-sized arrays support).

E.g. I recently thought that either FFI:ELEMENT or FFI:DEREF (preferably) could be extended to provide pointer arithmetic like in C: *(p+i). This way, one wouldn't have to dynamically construct a FOREIGN-VARIABLE object of the given `(C-ARRAY x ,size) type, just to extract some value.

I believe some of the people posting here could make use of this (I forgot whose posting lead me to come up with this idea).

(DEREF #<FOREIGN-VARIABLE (C-ptr char)> &optional signed-index)
-> foreign_value(*(address+signed-index))

Of course, people should know that block- or array-oriented operations are faster than their element by element counterpart.
One should work with c-string and c-array[-max] as much as possible, instead of dealing with individual characters.
Yet, here, for short arrays, the overhead of building up the foreign-variable object's C-type may outweight the inherent performance advantage. That's a very implementation dependent area: with compilers to native code, there wouldn't be much of a difference.

There are more than a dozen conceivable useful extensions to the FFI.

Another example would be the ability to convert part of a foreign array, possibly open-ended to and from Lisp. I already mentioned AFFI's MEM-READ/WRITE once. Something similar, based on #<FOREIGN-*> objects, could be added to FFI. Then people would continue to be able to use fast array operations, instead of elementwise using that DEREF extension.

One has to carefully choose. IMHO, something low-level (from an application POV) like any FFI is not suited for a hundred utility functions, which would all provide somehow similar functionality.

I can't remember where I had my notes about a page full of possible extensions.

Regards,
	Jörg Höhle.