with-alien-allocation & trying to avoid superfluous alloc+free
"Hoehle, Joerg-Cyril" <[email protected]> Fri, 22 Mar 2002 13:17:10 +0100
| Newsgroups | gmane.lisp.uffi.general |
|---|---|
| Message-ID | <[email protected]> |
Hi, Kevin wrote: > I've specialized with-foreign-object(s) so that it uses stack > allocation on LW and CMUCL and static for ACL. > I expect > I would translate with-foreign-object to CLISP code. A difficulty with CLISP is that stack-allocated things are only accessible encapsulated around a foreign function call (FFI::FOREIGN-CALL-OUT). They are not available separately in any way (like CMUCL's WITH-ALIEN or MCL's WITH-ALLOCATION which John DeSoi reported). This feature could be a useful extension to CLISP. If I were to add to CLISP some WITH- functionality, it would still not be as efficient as today, since every invocation would create FOREIGN-VARIABLE (Lisp) objects, which need to be GC'ed. CMUCL does a lot of compile time analysis to remove this sort of boxing. CLISP today, by integrating some WITH- functionality into FFI::FOREIGN-CALL-OUT, eliminates the need of explicit temporary objects for many common situations (at the cost of headaches in the few less common situations). > But, I still wonder > if I can translate the low level interface to CLISP. The low-level interface is really far away from what CLISP provides (and a lot of low-level work). I believe high-level interfaces are easier to translate to various platforms (more macro writing work). Again I believe (my DSL dream) that more declarative interfaces are easier to translate, whereas imperative code (e.g. allocate this, then that, then setf that, then call, then convert this, then free) is hard for portability. I think WITH- provides a useful abstraction, not hindering flexibility nor performance too much. John DeSoi wrote: >Lispworks also has something like this (with-dynamic-foreign-objects). From the documentation it's not sure it's stack-allocated, but the lifetime of foreign things is clearly documented as being limited by the WITH- form. So it could still be implemented as: (unwind-protect (progn (alloc-dynamic) &body ...) (free-dynamic)) or it could really do stack allocation. A nice abstracting macro, similar in expressiveness to the above WITH-ALIEN or WITH-ALLOCATION. Regards, Jorg Hohle.