In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
>>The bigger problem here is the lack of a stardard C interface for
>>lisps. Until that exists, any package, such as Winterp will only run
>>on top of the lisp version it was built for.
>
>I don't think that makes too much sense. The semantics of alien
>integration for the various implmentations of Lisp are too
>different. Just a few points:
Yes, the differences in implementations make it hard. But not that
hard....
>- Is your Lisp runtime capable of holding alien data in Lisp data
> structures, so that the alien data for arguments doesn't have to be
> rebuild on every invocation on a function?
>
> CMUCl does so using (with-alien ...) and friends
Don't understand this one...
>- Is the Lisp runtime capable of *using* alien data? That means,
> if a Lisp variable holds an alien structure, can you access
> individual fields and use that data in Lisp?
>
> CMUCL can.
No, you must write an interface function. Of course you might decide
to implement something to generate it.
>- Will you need an additional level of subroutines like the Java VM
> from Sun does (and many Scheme implementations)?
Yes, you must write an interface function. Of course you might decide
to implement something to generate it. And a particular implementation
might decide to ignore it if it thinks it can do better.
> Or, more general, do you need C code in addition to the alien code?
Yes in general, but a particular implementation might decide not to
make use of it.
>- Will memory allocated in aliens be handled by the Lisp Garbage
> collector?
Of course not. Maybe there will be hooks in case you do though.
>One example are Strings in CMUCL. In CMUCL, strings are represented as
>a data structure that has a plain chain of simple characters inside
>it. It always keeps a NULL at the end, although it mananges the length
>of the string different for its own needs.
>
>The result is that you can pass a string to a C alien subroutine just
>by passing a pointer past the header of this Lisp object. No
>conversion has to be done.
>
>How should a portable alien interface preserve this advantage?
C functions expect NULL terminated. Lisp implementations are sometimes
not NULL terminated. If not, then they must convert. If so, then don't
convert. No problem.
>I think any solution for this that has a performance disadvantage is
>doomed to do more harm than good, damaging Lisp performance
>reputation.
I can't see how.
>There is, BTW, some kind of a "standard" alien interface. It is part
>of ILU, Xerox's distributed objects system. ILU defines a Lisp macro
>that describes an alien function in a portable manner. Someone how
>will port ILU to a new Lisp implementation should implement this macro
>so that the native alien description is generated.
>
>But, and that is my point from above, this solution will convert data
>on every call. So, for example CMUCL's abitity to hold C data in Lisp
>structures so that ot can be reused over several invocations of the
>alien routine is not used.
>
>In addition, a simple Lisp macro will not be sufficient to do it for
>*all* Lisp implementations. For example, the aliens of Scheme-48/scsh
>need additional C code. If you generated the C code on invocation of
>this Lisp macro, you would rebuild the whole C stuff on every load of
>the Lisp file.
>
>A standard alien interface that keeps the maximum performance of every
>Lisp implementation will need abstract layers for:
>- Describing an Alien function
>- Describing alien data
>- Definition of Lisp variables that hold alien data
>- A mechanism to access data inside alien data hold by Lisp
> variables.
Yes fine. But even if only a subset of the possible functionality was
available it would be ok. In most cases the ultimate performance is
not an issue.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
·············@Alcatel.com.au (Chris Bitmead) writes:
>In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
>>>The bigger problem here is the lack of a stardard C interface for
>>>lisps. Until that exists, any package, such as Winterp will only run
>>>on top of the lisp version it was built for.
>>
>>I don't think that makes too much sense. The semantics of alien
>>integration for the various implmentations of Lisp are too
>>different. Just a few points:
>Yes, the differences in implementations make it hard. But not that
>hard....
>>- Is your Lisp runtime capable of holding alien data in Lisp data
>> structures, so that the alien data for arguments doesn't have to be
>> rebuild on every invocation on a function?
>>
>> CMUCl does so using (with-alien ...) and friends
>Don't understand this one...
When you have data structures you need for more than one invocation of
an alien function, is there a way that you can hold the alien
representation of the structure in a Lisp variable so that you don't
need several conversions?
Consider this code I use to use regular expressions in CMU Common
Lisp:
(let ((slist '("__bla__" "_bfa__" "___Bfa__" "__ddd__")))
(with-alien ((cre (struct regex_t))
(matches (array (struct re_match) 10))
)
(format t
"~%Res of compilation: ~a"
(regcomp (addr cre) "b\\([lf]a\\)" 0))
;;; cre now holds the compiled representation of
;;; the regular expression
(print "; match-p")
(dolist (s slist)
(format t "~%Res with ~a: ~a" s (match-p (addr cre) s)))
>>- Is the Lisp runtime capable of *using* alien data? That means,
>> if a Lisp variable holds an alien structure, can you access
>> individual fields and use that data in Lisp?
>>
>> CMUCL can.
>No, you must write an interface function. Of course you might decide
>to implement something to generate it.
This is correct but misleading
In CMUCL, I define an alien struct this way:
(def-alien-type nil
(struct regex_t
(re_magic int)
(re_nsub size_t)
(re_endp c-string)
(re_g voidptr)
))
This definition generates Lisp macros to access the fields from Lisp.
But this is no different from the way (defstruct ...) works, so your
point that using alien data from Lisp requires additional setup is not
correct.
>>- Will you need an additional level of subroutines like the Java VM
>> from Sun does (and many Scheme implementations)?
>Yes, you must write an interface function. Of course you might decide
>to implement something to generate it. And a particular implementation
>might decide to ignore it if it thinks it can do better.
>> Or, more general, do you need C code in addition to the alien code?
>Yes in general, but a particular implementation might decide not to
>make use of it.
>>- Will memory allocated in aliens be handled by the Lisp Garbage
>> collector?
>Of course not. Maybe there will be hooks in case you do though.
"Or course?". A Lisp that uses a conservative collector anyway can do
so, of course.
>>One example are Strings in CMUCL. In CMUCL, strings are represented as
>>a data structure that has a plain chain of simple characters inside
>>it. It always keeps a NULL at the end, although it mananges the length
>>of the string different for its own needs.
>>
>>The result is that you can pass a string to a C alien subroutine just
>>by passing a pointer past the header of this Lisp object. No
>>conversion has to be done.
>>
>>How should a portable alien interface preserve this advantage?
>C functions expect NULL terminated. Lisp implementations are sometimes
>not NULL terminated. If not, then they must convert. If so, then don't
>convert. No problem.
It is a problem as soon as you want an abstract layer for alien
definitions.
Although an interface may hide and automate the conversion, the
programmer needs to know about it because a conversion may cause a
totally different performance behaviour of the program.
>>I think any solution for this that has a performance disadvantage is
>>doomed to do more harm than good, damaging Lisp performance
>>reputation.
>I can't see how.
>>There is, BTW, some kind of a "standard" alien interface. It is part
>>of ILU, Xerox's distributed objects system. ILU defines a Lisp macro
>>that describes an alien function in a portable manner. Someone how
>>will port ILU to a new Lisp implementation should implement this macro
>>so that the native alien description is generated.
>>
>>But, and that is my point from above, this solution will convert data
>>on every call. So, for example CMUCL's abitity to hold C data in Lisp
>>structures so that ot can be reused over several invocations of the
>>alien routine is not used.
>>
>>In addition, a simple Lisp macro will not be sufficient to do it for
>>*all* Lisp implementations. For example, the aliens of Scheme-48/scsh
>>need additional C code. If you generated the C code on invocation of
>>this Lisp macro, you would rebuild the whole C stuff on every load of
>>the Lisp file.
>>
>>A standard alien interface that keeps the maximum performance of every
>>Lisp implementation will need abstract layers for:
>>- Describing an Alien function
>>- Describing alien data
>>- Definition of Lisp variables that hold alien data
>>- A mechanism to access data inside alien data hold by Lisp
>> variables.
>Yes fine. But even if only a subset of the possible functionality was
>available it would be ok. In most cases the ultimate performance is
>not an issue.
In the case of FFI, I think it is very often, much more often than for
Lisp code in general.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin