[cffi-devel] Static vectors suitable for FFI

[John Fremlin]

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
>> numeric work.
>
> Now we only need to see if the trick of "manually" creating unboxed
> arrays works on other implementations: CMUCL, CCL, Clisp, ECL, ...
> Allegro and Lispworks already support this with make-array's :ALLOCATION
> key arg

Yes, though note that Allegro sometimes annoyingly makes a non-simple
array with certain allocations.

>> I should be very happy to make the Allegro CL interface.
>
> Thanks. See if Allegro has native functions for bit-bashing, otherwise
> implement {fill,copy}-foreign-memory in terms of memset/memcpy.

Why not just use memset and memcpy always? I rather expect that the C
library version are much better than things implemented by most Lisps
(Allegro especially seems to be stuck in the 1990s when it comes to CPU
memory/architectures).