[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lisp and C : explanations
- To: email@example.com
- Subject: Re: Lisp and C : explanations
- From: firstname.lastname@example.org (Emmanuel Charpentier)
- Date: Mon, 12 Sep 1994 09:46:22 +0200 (MET DST)
- In-reply-to: <9409091717.AA17876@ma2s2.mathematik.uni-karlsruhe.de> from "Bruno Haible" at Sep 9, 94 07:21:54 pm
> > > - To link these compiled lisp routines (and the lisp kernel needed)
> > > with my App and to call them from a C function.
> > >
> > > The problem is that CLisp just produce fasl files and not .o.
> > > gcl produce .o file but I didn't reach to do what I wanted.
> > akcl might be what you are looking for. Its compiler produces
> > C code which is handed to the cc compiler (gcc in my case). This
> > makes for a *slow* compiler, but gives *tight* and *fast* code.
> > Fair warning : akcl does not seems to be very alive, those days.
> > Furthermore, it is *not* in public domain : you'll have to request
> > a (free) license from some japanese university...
> No, if GCL doesn't serve David Rudloff's, its predecessor AKCL won't
> either. Maybe EcoLisp will serve his purpose?
I remember somewhat foggily helping a friend of mine with such a project.
The idea was to modify the back-end part of the compiler, adding a flag
allowing to "include" an almost-verbatim copy of the target C code and
generating a wrapper interface between C and lisp. I didn't achieve this
*myself*, but I heard that it worked and gave fast exeutions and *slowww*
compilations (as usual with akcl...).
BTW : I wasn't aware of gcl, even less of its akcl origin....
What is Ecolisp ?
> AKCL (the last release) and GCL don't require a license, they are covered
I wasn't aware of this "last version"...
> by LGPL. And the code produced by GCL is certainly not "tight", at least
> when compared to CLISPs code.
Hmmm... I think that my words betrayed me : what I wanted to say was not
related to the *size* of the code ; I meant that clisp generates code for
an abstract lmachine, which is then interpreted, while (a)kcl generates
C code which is then *compiled* by a *good* C compiler (gcc). The resulting
native code is larger (by maybe an order of magnitude) but what is executed
is smaller (and faster), since each clisp pseudo-instruction has to be
processed by an interpreter.
> Bruno Haible
BTW : this letter got me grabbing gcl, and I ran in trouble, but this is
another story (and another mail).