- cffi-devel - mailman3.common-lisp.net

Re: [cffi-devel] New patches: 3-Feb-2006: x86-64
by Hoehle, Joerg-Cyril 08 Feb '06

08 Feb '06

James, >Fri Feb 3 02:29:54 CST 2006 James Bielman <jamesjb(a)jamesjb.com> > * Add CFFI-FEATURES:X86-64 and push it on *FEATURES* on AMD64 Lisps. > - Currently this is supported under SBCL and CLISP. Could you please confirm my supposition that long-long works out of the box with clisp on your amd64 machine? I'm in the process of making long-long generally work in clisp, and I need a little input. So far, I'd presume the 64bit machines are not disturbed by the 10 year old long long code in clisp (because there, long = long long = 64bit, long-long is not used). ffi:uint64 conversion raising an error in the MS-VC builds is a different error. It was sort of a preprocessor confusion (HAVE_LONGLONG vs HAVE_LONG_LONG). It should work now (but I haven't tested CVS with MSVC for the last 6 month). I tested CLISP with MSVC about ffi:uint64 by backporting a one-line change to my 6 month old MSVC build tree. Is there anybody listening using MS-VC with CLISP? Please contact me. Thanks, Jorg Hohle.

2 1

[cffi-devel] optimization opportunities for type translators
by Hoehle, Joerg-Cyril 08 Feb '06

08 Feb '06

Hi, James Bielman wrote: >Thu Feb 2 18:41:28 CST 2006 James Bielman <jamesjb(a)jamesjb.com> > * Add an optimization for defining non-translatable types. Is that something akin to sealing? Maybe that's a good step towards optimization. I've noticed the following behaviour (with CFFI-CVS from last week or so), which led me to write this note: Since the addition of the new type translators, I'd got some bad feelings in my stomach (and wrote about it), without the time to look closer. Now I looked. Somehow I feel there's a missing API for compile-time transformations in the new branch, similar to the old duality provided by translate-to-c <-> to-c-FORM. To make a long story short, here's output for test struct.5 (defctype my-int :int) (defcstruct s5 (a my-int)) (deftest struct.5 (with-foreign-object (s 's5) (setf (foreign-slot-value s 's5 'a) 42) (foreign-slot-value s 's5 'a)) 42) The old CFFI produces (just skim over the rightmost column): 12 Bytecode-Instruktionen: 0 (LOAD&PUSH 1) 1 (CALL1&PUSH 0) ; FFI:FOREIGN-ADDRESS 3 (CONST&PUSH 1) ; 42 4 (LOAD&PUSH 1) 5 (CONST&PUSH 2) ; FFI:INT 6 (CONST&PUSH 3) ; 0 7 (CALL 4 4) ; FFI::WRITE-MEMORY-AS 10 (LOAD&PUSH 0) 11 (CONST&PUSH 2) ; FFI:INT 12 (CONST&PUSH 3) ; 0 13 (CALL 3 5) ; FFI:MEMORY-AS 16 (SKIP&RET 3) Neat. Perfect. The new branch of CFFI produces: 18 Bytecode-Instruktionen: 0 (LOAD&PUSH 1) 1 (CALL1&PUSH 0) ; FFI:FOREIGN-ADDRESS 3 (CONST&PUSH 1) ; 42 4 (CONST&PUSH 2) ; #<CFFI::FOREIGN-TYPEDEF MY-INT> 5 (CALL2&PUSH 3) ; CFFI::TRANSLATE-TYPE-TO-FOREIGN 7 (LOAD&PUSH 0) 8 (LOAD&PUSH 2) 9 (CONST&PUSH 4) ; FFI:INT 10 (CONST&PUSH 5) ; 0 11 (CALL 4 6) ; FFI::WRITE-MEMORY-AS 14 (SKIP 1) 16 (LOAD&PUSH 0) 17 (CONST&PUSH 4) ; FFI:INT 18 (CONST&PUSH 5) ; 0 19 (CALL&PUSH 3 7) ; FFI:MEMORY-AS 22 (CONST&PUSH 2) ; #<CFFI::FOREIGN-TYPEDEF MY-INT> 23 (CALL2 8) ; CFFI::TRANSLATE-TYPE-FROM-FOREIGN 25 (SKIP&RET 3) Ouch. Two generic function calls, which each call another generic function (e.g. translate-to-foreign), some of which cons, e.g. (defmethod translate-type-to-foreign (value (type foreign-typedef)) ;;We build a list out of the second value returned... ;;IMHO bug: 1. undocumented and 2. most don't provide a second value So we compare o 4 GF calls in total, and some consing o to nothing like this previously o with something a C compiler compiles to 2-4 native instructions. IMHO this hurts. It hurts even more so, since CFFI originaly started out from disatisfaction with UFFI on cmucl, where James Bielman observed boxing of float values IIRC, and he initially reported performance improvements over UFFI using his approach. Right now, I'd expect CFFI to lag far behind UFFI in performance (at least with typedefs and structs, other tests are still compiled fine). The type translators may have gained a lot of flexibility. However such gain should not come at the cost of lack of compile-time optimization. People often enough turn towards an FFI when some fast library is needed they don't want to port... I believe there's a need for some translate-*-FORM protocol, which can generate code for known types, and eliminate run-time GF calls when present, by which I mean that user-defined custom fancy converters may still call GF at run-time, they are welcome. But GF is not the typical case, which gets optimized as tight as can be. Regards, Jorg Hohle

5 4

[cffi-devel] Bit based structs
by Roger Sen Montero 07 Feb '06

07 Feb '06

Hi all!! Does defcstruct support bit fields? I've been looking the docs and code but found nothing. Supose I need to support a struct like: typedef struct ilovebits { int one:1; int two:1; int three:1; int four:1; int rest:4; } lovely; What should I do? Regards, rogersm.

1 0

AW: [cffi-devel] Re: unnamed callback (closures?)
by Hoehle, Joerg-Cyril 07 Feb '06

07 Feb '06

Jan Rychter wrote: > The problem is that the C side insists on identifying > callbacks to delete by a function pointer. In this approach all > callbacks would get the same function pointer on the C side -- that > of the dispatching callback function on the Lisp side. Which means I > won't be able to delete them on the C side afterwards. Then just don't delete them. If the C side only sees only one, there won't be such a memory loss (but analyse that, maybe there's some for each new window?). OTOH, as Martin Simmons said, other GUI (which one are you using?) don't suffer from such a braindamage. And more importantly, named callbacks are supported by all Lisps (?), whereas lambdas only work with sbcl + clisp. >2. I was actually wrong when I said I knew when the callback >would be no > longer needed. Not quite sure what to do about this yet. I know next > to nothing about finalizers -- can I expect them to be supported? Forget about finalizers. *YOU* are the only one to be able to tell when the other side has finished using a resource. A good time to free resource is generally when the application exists... Regards, Jörg Höhle.

1 0

[cffi-devel] New patches: 6-Feb-2006
by loliveira＠common-lisp.net 07 Feb '06

07 Feb '06

Mon Feb 6 12:54:39 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Remove note about unsupported FOREIGN-FUNCALL on Lispworks. M ./doc/cffi-manual.texinfo -3 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060206.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] wanted: testsuite .dll
by Hoehle, Joerg-Cyril 06 Feb '06

06 Feb '06

Hi, could some kowledgeable person please compile a .ddl version of the testsuite's C code, so that the testsuite can be used on MS-Windows (outside of cygwin/mingw?)? E.g. was the CFFI testsuite ever run on CormanLisp? I'd expect such a .dll to be tiny (maybe 4KB, need no debug build). Maybe it could be provided in the darcs tree for convenience to people? Thanks, Jorg Hohle.

2 1

[cffi-devel] New patches: 4-Feb-2006
by loliveira＠common-lisp.net 05 Feb '06

05 Feb '06

Sat Feb 4 02:29:12 CST 2006 James Bielman <jamesjb(a)jamesjb.com> tagged 0.9.0 Sat Feb 4 02:28:14 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Update system definition version to 0.9.0. M ./cffi.asd -1 +1 Fri Feb 3 10:36:36 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Use DEFINE-FOREIGN-LIBRARY to load the test shared library. M ./tests/bindings.lisp -15 +13 Fri Feb 3 10:36:02 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Build an additional 32-bit libtest.so on x86-64 Linux. M ./tests/Makefile -3 +12 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060204.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] CFFI 0.9.0 Release
by James Bielman 04 Feb '06

04 Feb '06

Hi, I've released the current darcs version of CFFI as 0.9.0. The darcs tree has been tagged and checkpointed, and I've uploaded a signed tarball to public_html/releases and updated the package link on CLiki. I consider this the "beta" release leading up to a real 1.0 version. I think the next step is to look at the TODO list and determine which things need to be done before 1.0, and which should wait until after. Primarily I'm concerned with bugfixes, finishing the incomplete sections of the manual, and adding tests to cover all CFFI functions. James

1 0

[cffi-devel] New patches: 3-Feb-2006
by loliveira＠common-lisp.net 04 Feb '06

04 Feb '06

Fri Feb 3 23:02:40 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Don't add CFFI-FEATURES:UNIX to *FEATURES* on SBCL/Win32 M ./src/cffi-sbcl.lisp -1 +1 Fri Feb 3 20:28:35 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Disable test DEFCFUN.VARARGS.FLOAT for now. M ./tests/defcfun.lisp +3 Fri Feb 3 13:57:05 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add tests for keyword arguments to FOREIGN-ALLOC. M ./TODO -1 M ./tests/memory.lisp +47 Fri Feb 3 10:12:10 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add two new tests for MAKE-POINTER and INC-POINTER. M ./tests/memory.lisp +17 Fri Feb 3 02:29:54 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add CFFI-FEATURES:X86-64 and push it on *FEATURES* on AMD64 Lisps. - Currently this is supported under SBCL and CLISP. It would be nice to implement this for Allegro on AMD64 as well, but I don't have a copy. M ./src/cffi-clisp.lisp -4 +7 M ./src/cffi-sbcl.lisp +1 M ./src/features.lisp -1 +1 Fri Feb 3 02:07:58 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * New test: callbacks.funcall Tests both declarations in a callback's body and foreign-funcalling a cffi callback. M ./tests/callbacks.lisp +12 Fri Feb 3 02:07:34 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Remove outdated comment about foreign-slot-value M ./src/types.lisp -3 Fri Feb 3 02:03:54 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Minor documentation updates. - Comment out sections that refer to unimplemented functionality. - Remove obsolete references to DEFINE-TYPE-TRANSLATOR. - Document the ERRORP argument to FOREIGN-ENUM-TYPE / FOREIGN-ENUM-KEYWORD. - Remove the documentation of the unimplemented slot name chaining feature in FOREIGN-SLOT-VALUE. M ./doc/cffi-manual.texinfo -143 +56 Fri Feb 3 01:35:57 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Update documentation for DEFCTYPE. M ./doc/cffi-manual.texinfo -5 +13 Fri Feb 3 01:25:47 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add tests for non-translatable typedefs. - Test as arguments and return value to a foreign function. - Test as arguments and return value from a callback. M ./tests/misc-types.lisp +28 Fri Feb 3 01:24:38 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Fix INVERSE-TRANSLATE-OBJECTS to respect TRANSLATE-P. M ./src/functions.lisp -4 +9 Fri Feb 3 00:52:49 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Parse and lift declarations properly for DEFCALLBACK. - Add a new utility function PARSE-BODY to CFFI-UTILS to pull the documentation string and declarations out of a body of code. - Use CFFI-UTILS:PARSE-BODY in DEFCALLBACK. M ./src/functions.lisp -9 +12 M ./src/utils.lisp +13 M ./tests/defcfun.lisp +1 Fri Feb 3 01:10:13 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add TODO entry to compile a 32-bit libtest on 64-bit Linux. M ./TODO +2 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060203.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James Bielman wrote: >Could we be using EQUALP instead for comparing pointers >(or is the fact that seems to work just a coincidence?) I realized I didn't specifically answer the question. No you cannot (or I'd have submitted a patch already :) You can even write a testcase to prove you cannot. Try EQUALP on (setq foo (foreign-alloc ...)) and (unsigned-foreign-address (foreign-address-unsigned foo)) ffi:set-foreign-pointer is the reason. Try (ffi:foreign-pointer foo) and on others. That's how in CLISP, you can link all sorts of foreign pointers together, and invalidate them all in one go. E.g. when calling foreign-free. See (SETF VALIDP) in the CLISP impnotes. And yes, INC-POINTER via addition is costly, compared to what could be otherwise thought of (e.g. Lispworks has an in-place incf-pointer). But that's not used in CFFI, maybe for fear of destructively modifying the argument? (the comment in cffi-lispworks invokes another reason). I could add a similar thing to CLISP, but would it help CFFI? Regards, Jorg Hohle.

1 0