cffi-devel October 2006

cffi-devel@common-lisp.net

10 participants
8 discussions

RE: [Ecls-list] [cffi-devel] More patches for ECL
by Goffioul Michael 17 Oct '06

17 Oct '06

> > Why in %mem-ref/%mem-set is used > > (+ offset type-size) > > instead of > > (* offset type-size)? > > I don't know. It looks like a bug, but this is a part of > cffi-ecl.lsp which I still have not revised: I only changed > convert-foreign-type to > cffi-type->ecl.type No, this is intentional. %mem-ref dereferences a a pointer starting at address "ptr" with an offset "offset" in bytes. What the function is doing is: 1) compute the size of "type" in bytes (-> ffi:size-of-foreign-type) 2) make sure the data pointed by "ptr" is large enough to allow dereferencing: this means that the data should be at least (offset+type_size) bytes large (-> si:foreign-data-recast) 3) dereference the data at address (ptr+offset) of size type_size (-> si:foreign-data-ref-elt) Without the step 2, step 3 would fail if the internal data size stored in the foreign-data object is not large enough. This situation occurs for instance when dealing with foreign object of type (* :int), where the actual data size is not known. Michael.

1 0

[cffi-devel] More patches for ECL
by Juan Jose Garcia-Ripoll 16 Oct '06

16 Oct '06

Hi, I had some time to work on the port of CFFI to ECL and I have attached most of the fixes. They include + Fixed the port to architectures without dynamical FFI. (In these ports CFFI foreign function calls only work when lisp code is compiled) + ECL supplies its own version of RT hence this need not appear in the ASDF cffi-test. + Tests with too large number of arguments (> 34) are marked as expected to fail, since ECL's FFI does not support such function calls. I had to play a few tricks because CFFI does not allow us to include headers function declarations and ECL cannot rely on the arguments to FOREIGN-FUNCALL which are most of the time bogus. For instance, :string is an alias to :pointer and when you call (foreign-funcall "strlen" :string .. ) we cannot produce a proper C declaration to strlen that does not collide with the one provided by the header <string.h>. So in the end I end up always using the routine dlsym() to discover the functions and coerce them to a function pointer created with the information given by CFFI. The outcome is therefore much less efficient than what ECL can potentially do. Regards Juanjo

4 13

[cffi-devel] C99 complex datatypes?
by Mark Hoemmen 15 Oct '06

15 Oct '06

Greetings! We're working on a linear algebra package (called lisp-matrix for lack of a more marketable name ;) ) in CL. We plan to call the BLAS and LAPACK for matrix-matrix multiplications and factorizations, and we want to use CFFI for maximum portability (the older package Matlisp has only been ported to SBCL and Allegro CL). The BLAS and LAPACK fully support complex numbers (single-float and couple-float), and they are stored with the same layout in memory as a C struct would use. C99 supports complex floating-point types. As such, we would like to include complex number support in lisp-matrix. However, CFFI doesn't support passing C structs by value, so we can't implement a complex number interface in CFFI using DEFCSTRUCT. We would be glad to help implement complex number support in CFFI, but would like some advice on the difficulty of such a project, and how we might proceed. We've written up some plans for the lisp-matrix project -- you can see them here: http://www.cs.berkeley.edu/~mhoemmen/lisp-matrix/ Best, mfh

3 4

[cffi-devel] New Unpaid Item Message from tany70 : #294653688662
by eBay＠common-lisp.net 14 Oct '06

14 Oct '06

1 0

[cffi-devel] New patches: 12-Oct-2006
by loliveira＠common-lisp.net 13 Oct '06

13 Oct '06

Thu Oct 12 20:28:17 EDT 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Use ECL's RT. M ./cffi-tests.asd -1 +4 M ./tests/bindings.lisp -1 +1 Thu Oct 12 18:47:06 EDT 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Add declarations to cffi-sbcl.lisp Patch courtesy of Yaroslav Kavenchuk. M ./src/cffi-sbcl.lisp +24 Thu Oct 12 18:00:14 EDT 2006 Luis Oliveira <loliveira(a)common-lisp.net> * ECL port update - Fixed the port to architectures without dynamical FFI. - Tests with too large number of arguments (> 34) are marked as expected to fail. Patch courtesy of Juan Jose Garcia-Ripoll. M ./src/cffi-ecl.lisp -42 +53 M ./tests/bindings.lisp -1 +1 M ./tests/callbacks.lisp -6 +6 M ./tests/defcfun.lisp -2 +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-061012.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Design problem?
by Juan Jose Garcia-Ripoll 12 Oct '06

12 Oct '06

Hi, on looking at CFFI from a porters point of view, I find what I consider a design failure. Namely, C functions are used without declaring them or even with fake declarations. First of all, every time you call a function with foreign-funcall you have to supply the types of the arguments. The aliasing of all pointer types to :pointer means that type information is lost. Not all pointer type are equivalent, because some types have alignment restrictions. Supplying the argument types is extremely tricky in some cases and might not be enough type information. For example, int f1(int i, ...) is not the same function as int f2(int i, int j) even though when we invoke f1(1, 2) the (2) is coerced to type int. The information about "..." is taken cared of by DEFCFUN, but not by FOREIGN-FUNCALL. That may seem useless but really, it is not the same thing to call f1 and f2, because the C compiler does produce different assembly code. For instance, using AMD64, in the first case it has to push the arguments on the stack, while in the second case everything goes into registers Similar things happen with a PPC backend. My current approach to coerce all functions to the first form is really a hack. And I wonder whether this design will survive newer architectures to come. Regards, Juanjo -- Max-Planck-Institut für Quantenoptik Hans-Kopfermann-Str. 1, Garching, D-85748, Germany Phone: +49 89 32905 345 Fax: +49 89 32905 336 http://www.mpq.mpg.de/Theorygroup/CIRAC/

3 3

[cffi-devel] Typification and optimization in cffi-sbcl.lisp
by Yaroslav Kavenchuk 12 Oct '06

12 Oct '06

For example: from (defun pointer-eq (ptr1 ptr2) "Return true if PTR1 and PTR2 point to the same address." (sb-sys:sap= ptr1 ptr2)) to (declaim (inline pointer-eq)) (defun pointer-eq (ptr1 ptr2) "Return true if PTR1 and PTR2 point to the same address." (declare (type system-area-pointer ptr1 ptr2)) (sb-sys:sap= ptr1 ptr2)) This is need? Do it? And for other files? Thanks! -- WBR, Yaroslav Kavenchuk.

3 5

[cffi-devel] Re: CFFI defcallback closures?
by Luís Oliveira 05 Oct '06

05 Oct '06

On 9/25/06, Lars Brinkhoff <lars(a)nocrew.org> wrote: > Can CFFI defcallbacks be closures, e.g. > > (let ((x 42)) > (defcallback foo :int ((y :int)) > (+ x y))) Unfortunately, last time I checked, not all Lisps support non top-level DEFCALLBACKs. See: <http://common-lisp.net/project/cffi/manual/html_node/defcallback.html> -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel October 2006