Re: [Chicken-users] libffi

[felix winkelmann]

On Tue, 18 Jan 2005 10:37:42 +0000, Category 5 <address@hidden> wrote:
> felix wrote:
> 
> > Also: the darcs repository now has preliminary support for using
> > libffi (http://freshmeat.net/redir/libffi/17361/url_homepage/libffi)
> > to overcome the 126-argument limit: C_apply uses this facility to
> > portably construct function calls with more than 126 arguments
> > (currently with an arbitrary limit of 1000).
> 
> This is really cool.  A few questions:
> 
> - Assuming this is stable, will Chicken end up incorporating libffi and
>   using this system by default on platforms that support it?  It looks
>   like libffi is fairly small and the license is very permissive.  (Is
>   it still under development / being ported to more platforms?)

Well, adding libffi to the Chicken distribution would probably be
most user-friendly, even though I don't like adding third party
libraries too much. I'm also not sure about the maturity of libffi
(on the other hand it seems to work perfectly on x86, but that's
the only platform I have access to).
The official libffi version is rather old, but a newer version is
here:

http://www.call-with-current-continuation.org/libffi-new.tgz

(Stolen fom Andreas Rottmann's g-wrap)

IIRC, this new version is also supposed to work on Darwin (?)
(Andreas, perhaps you know more about this?)

I'm not sure now how to integrate it. For the time being it has
to be downloaded and installed separately.

> 
> - Are there any disadvantages to doing things this way?

None that I know of.

> 
> - Any idea on the relative performance hit in doing something like
>       (apply + (make-list 1000000 1))
>   with Chicken+libffi vs. other Scheme compilers?

Now using libffi is likely to be much slower than a direct call, but since
this is only used when more than 120 arguments are passed, and since
all other argument passing schemes are likely to be more involved
(by passing arguments in a global buffer, etc.) I don't think that using
libffi is inherently slower. A Scheme using a calling convention that 
passes all arguments to Scheme function in an argument array 
(argv-style) will of course be more efficient in the large-argument-list case,
but very likely be slower for calls with a few args (the code compiled
to C will naturally use C calling conventions).

It would be interesting to see how other Scheme compilers handle this.
Gambit (IMHO) passes arguments via an intermediate data structure (array),
but bigloo definitely uses C calling conventions. I don't know how
it implements apply. Stalin probably just ignores this issue...

> 
> As a side issue not related to libffi, at least in 1.66 the following
> happens to me:
> 
>   Version 1, Build 66 - netbsd-gnu-ultrasparc
>   #;1> (require-extension srfi-1)
>   ; loading library srfi-1 ...
>   #;2> (apply + (make-list 1000000 1))
>   zsh: bus error (core dumped)  csi
> 

Can you try out 1.89?


cheers,
felix