[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lisp and C : explanations

> > > - 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
>                     haible@ma2s2.mathematik.uni-karlsruhe.de

BTW : this letter got me grabbing gcl, and I ran in trouble, but this is
another story (and another mail).

	Sincerely yours,
Emmanuel Charpentier