Hello,
I would like to have an idea of how much of the lisp compilers you know
are written in lisp and how much is written in something else.
A similar but probably a bit different question is: how much of the lisp
compilers you know involves lisp-level program transformation, and how
much actually involves traduction to machine code ?
Thanks
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
Didier Verna ha scritto:
> I would like to have an idea of how much of the lisp compilers you know
> are written in lisp and how much is written in something else.
Once Upon A Time, there were these strange thingies called "Lisp
Machines"...
-JO
From: Duane Rettig
Subject: Re: How much of a lisp compiler is written in lisp ?
Date:
Message-ID: <o0bq40a3jv.fsf@gemini.franz.com>
Didier Verna <······@lrde.epita.fr> writes:
> Hello,
>
> I would like to have an idea of how much of the lisp compilers you know
> are written in lisp and how much is written in something else.
For Allegro CL:
Well, the flip answer has already been given: 100%. If you include
the interpreter, the runtime, etc., then the answer is still a very
high percentage of lisp code - mostly Common Lisp, but some "runtime"
lisp code that uses low-level constructs (I described this in the
tutorial I gave at ILC07) and which uses our compiler to compile to
asm statements. All of this is lisp-compiling-lisp, and makes up at
least 3/4 of the runtime. The rest of the runtime is written in C,
which is still the best way to interpret the .h files that interface
to standard libraries. Also, there is one .s or .asm file per
architecture, but it has code which I've been slowly transforming into
our runtime lisp format, for readability and to ensure that no offset
magnitude bugs creep in (the offsets are symbolic in the runtime lisp
code). So these assembler files are becoming smaller and smaller; I'd
estimate less than 100 lines of asm code left.
> A similar but probably a bit different question is: how much of the lisp
> compilers you know involves lisp-level program transformation, and how
> much actually involves traduction to machine code ?
Yes, different. All of this is 100% lisp. At the very back end is
the code generation, which either feeds to an in-core assembler (in
lisp, of course) or to an assembler-source generator. In the middle
is compiler tree generation, type-propagation, flow analysis, register
assignment, and various optimizations. At the front end is
macro-expansion, which includes compiler-macro expansion and
code-walking and which interleaves with the compiler-tree generation.
This front-end has grown considerably in the past few revisions due to
the advent of Environments Access, which allows a lot more of the
analysis and transformation to be done at the front end to source
code, before the code makes the transition into unintelligible
compiler-tree land. We even get a healthy dose of type propagation
that aids the source transformation process, before the formal
type-propagation phase even begins. So in short, we're working on
pushing more and more of the compilation process up-front into the
user-visible source arena.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 23 avr, 19:23, Duane Rettig <·····@franz.com> wrote:
> Didier Verna <······@lrde.epita.fr> writes:
> > Hello,
>
> > I would like to have an idea of how much of the lisp compilers you know
> > are written in lisp and how much is written in something else.
>
> For Allegro CL:
>
> Well, the flip answer has already been given: 100%. If you include
> the interpreter, the runtime, etc., then the answer is still a very
> high percentage of lisp code - mostly Common Lisp, but some "runtime"
> lisp code that uses low-level constructs (I described this in the
> tutorial I gave at ILC07) and which uses our compiler to compile to
> asm statements. All of this is lisp-compiling-lisp, and makes up at
> least 3/4 of the runtime. The rest of the runtime is written in C,
> which is still the best way to interpret the .h files that interface
> to standard libraries. Also, there is one .s or .asm file per
> architecture, but it has code which I've been slowly transforming into
> our runtime lisp format, for readability and to ensure that no offset
> magnitude bugs creep in (the offsets are symbolic in the runtime lisp
> code). So these assembler files are becoming smaller and smaller; I'd
> estimate less than 100 lines of asm code left.
>
> > A similar but probably a bit different question is: how much of the lisp
> > compilers you know involves lisp-level program transformation, and how
> > much actually involves traduction to machine code ?
>
> Yes, different. All of this is 100% lisp. At the very back end is
> the code generation, which either feeds to an in-core assembler (in
> lisp, of course) or to an assembler-source generator. In the middle
> is compiler tree generation, type-propagation, flow analysis, register
> assignment, and various optimizations. At the front end is
> macro-expansion, which includes compiler-macro expansion and
> code-walking and which interleaves with the compiler-tree generation.
> This front-end has grown considerably in the past few revisions due to
> the advent of Environments Access, which allows a lot more of the
> analysis and transformation to be done at the front end to source
> code, before the code makes the transition into unintelligible
> compiler-tree land. We even get a healthy dose of type propagation
> that aids the source transformation process, before the formal
> type-propagation phase even begins. So in short, we're working on
> pushing more and more of the compilation process up-front into the
> user-visible source arena.
>
> --
> Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
> 555 12th St., Suite 1450 http://www.555citycenter.com/
> Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Hi all,
My memory is not so bad :) ...
I search the tutorial in Franz website, and I don't found it ...
Is it possible to download this ?
Best regards,
Christophe
CLforJava compiles to Java bytecode (the file compiler writes bytecode
into jar files). We use the ASM library from Objectweb as the emitter.
Since it's in Java, we just wrapped each of their methods in a Lisp
function. The bootstrap compiler was written entirely in Java, but
we're in the process of building a new compiler entirely in Lisp
(about damn time!).
Jerry
···········@mac.com writes:
> CLforJava compiles to Java bytecode (the file compiler writes bytecode
> into jar files). We use the ASM library from Objectweb as the emitter.
> Since it's in Java, we just wrapped each of their methods in a Lisp
> function. The bootstrap compiler was written entirely in Java, but
> we're in the process of building a new compiler entirely in Lisp
> (about damn time!).
>
> Jerry
I think I haven't heard about CLforJava before. Is it available for
download? Is it a full Common Lisp implementation? How does it compare
to ABCL (which is the only other CL implemented on the JVM, as far as I
know)?
--
Dimitre Liotev
(format t "~{~a~}" (reverse '("et" "n" "in." "a" "zn" ·@" "l" "d")))
On Sun, 27 Apr 2008 12:18:07 -0400, Dimitre Liotev <·····@email.com> wrote:
> I think I haven't heard about CLforJava before. Is it available for
> download? Is it a full Common Lisp implementation?
http://justfuckinggoogleit.com/search.pl?query=CLForJava
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Sun, 27 Apr 2008 12:18:07 -0400, Dimitre Liotev <·····@email.com> wrote:
>
>> I think I haven't heard about CLforJava before. Is it available for
>> download? Is it a full Common Lisp implementation?
>
> http://justfuckinggoogleit.com/search.pl?query=CLForJava
I did search a bit, but did not find the answers, so I thought it would
be best to hear straight from the horse's mouth...
--
Dimitre Liotev
(format t "~{~a~}" (reverse '("et" "n" "in." "a" "zn" ·@" "l" "d")))
On Lisp machines, of course, the compiler was entirely written in
Lisp, as was everything else.
In Corman Common Lisp, I believe that the entire compiler is written
in C. Not counting macros, of course. It does seem to be pretty fast
(I have not benchmarked it).
On 2008-04-29, ··········@gmail.com <··········@gmail.com> wrote:
> In Corman Common Lisp, I believe that the entire compiler is written
> in C. Not counting macros, of course.
Only the bootstrap code is written in C/C++ for Corman Lisp as well, it seems.
From http://www.cormanlisp.com/features.html:
"Source Code. The source code for Corman Lisp is included with this release.
Most of this source is in Common Lisp, and self-compiles. The bootstrap kernel
code is written in C/C++, and Intel assembler, and is included with the
standard Corman Lisp release. Complete instructions for rebuilding Corman Lisp
from sources are included with this package."
--
Oyvin
Edi Weitz wrote:
> On Sun, 27 Apr 2008 12:18:07 -0400, Dimitre Liotev <·····@email.com> wrote:
>
>> I think I haven't heard about CLforJava before. Is it available for
>> download? Is it a full Common Lisp implementation?
>
> http://justfuckinggoogleit.com/search.pl?query=CLForJava
>
Ah community:
http://preview.tinyurl.com/3ktatl
Compared with:
http://preview.tinyurl.com/467plh
OR
http://preview.tinyurl.com/4ho32u
Didier Verna <······@lrde.epita.fr> writes:
> Hello,
>
> I would like to have an idea of how much of the lisp compilers you know
> are written in lisp and how much is written in something else.
clisp, : implemented mostly in C ; compiler and some library functions
implemented in CL.
mcl, openmcl, sbcl, cmucl : implemented almost 100% in CL (plus some
"bootstrap" or low level C).
emacs-cl : implemented mostly in emacs-lisp, plus some library in CL.
100% lisp then...
ecl, gcl : mostly in lisp, with some C libraries (eg. binutils,
gmp). compilers implemented in CL.
abcl : mostly in java, some CL ? (I've not checked).
> A similar but probably a bit different question is: how much of the lisp
> compilers you know involves lisp-level program transformation, and how
> much actually involves traduction to machine code ?
And how much involves intermediate code transformation and
optimization. IIRC, in sbcl it's the most part of the compiler.
Also, you could consider that all the macros, being compiler hooks,
are lisp-level program transformations, and weight heavily on that
side.
--
__Pascal Bourguignon__
On 23 avr, 12:26, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Didier Verna <······@lrde.epita.fr> writes:
> > Hello,
>
> > I would like to have an idea of how much of the lisp compilers you know
> > are written in lisp and how much is written in something else.
>
> clisp, : implemented mostly in C ; compiler and some library functions
> implemented in CL.
>
> mcl, openmcl, sbcl, cmucl : implemented almost 100% in CL (plus some
> "bootstrap" or low level C).
>
> emacs-cl : implemented mostly in emacs-lisp, plus some library in CL.
> 100% lisp then...
>
> ecl, gcl : mostly in lisp, with some C libraries (eg. binutils,
> gmp). compilers implemented in CL.
>
> abcl : mostly in java, some CL ? (I've not checked).
>
> > A similar but probably a bit different question is: how much of the lisp
> > compilers you know involves lisp-level program transformation, and how
> > much actually involves traduction to machine code ?
>
> And how much involves intermediate code transformation and
> optimization. IIRC, in sbcl it's the most part of the compiler.
>
> Also, you could consider that all the macros, being compiler hooks,
> are lisp-level program transformations, and weight heavily on that
> side.
>
> --
> __Pascal Bourguignon__
Hi all,
To speak about real Common Lisp in real World :
Allegro Cl : if my memory is good : Lisp, a % (I don't know the value)
of C and a very little % of ASM .
About Lispworks, I don't know.
Best Regards,
Christophe
Christophe <····················@birdtechnology.net> wrote:
> To speak about real Common Lisp in real World :
>
> Allegro Cl : if my memory is good : Lisp, a % (I don't know the value)
> About Lispworks, I don't know.
So, you actually don't know much about Real Common Lisp in Real World,
do you :-p
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On 23 avr, 14:29, Didier Verna <······@lrde.epita.fr> wrote:
> Christophe <····················@birdtechnology.net> wrote:
> > To speak about real Common Lisp in real World :
>
> > Allegro Cl : if my memory is good : Lisp, a % (I don't know the value)
> > About Lispworks, I don't know.
>
In the website Planet Lisp, there is a topic about it.
> So, you actually don't know much about Real Common Lisp in Real World,
> do you :-p
>
It's just to make the distinction between :
"Hobby" Lisp and serious Lisp .
Pascal just speaks about "hobby" Lisp.
Best Regards,
Christophe
Christophe <····················@birdtechnology.net> wrote:
> In the website Planet Lisp, there is a topic about it.
Thanks.
> It's just to make the distinction between : "Hobby" Lisp and serious
> Lisp .
>
> Pascal just speaks about "hobby" Lisp.
I know, I've seen your crusade against free software elsewhere. ;-)
'not sure I wanna go down that road though...
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
In article <···············@uzeb.lrde.epita.fr>,
Didier Verna <······@lrde.epita.fr> wrote:
> Hello,
>
> I would like to have an idea of how much of the lisp compilers you know
> are written in lisp and how much is written in something else.
To make sure that people understand your question correct,
what is a Lisp compiler? A Lisp compiler is that part of a
Lisp system that transforms source code into some machine or
byte code. Only that.
A Lisp compiler is NOT: the Lisp interpreter,
the byte code interpreter, the runtime, the memory management,
the FFI interface, the CL library (streams, files, pathnames, ...),
the IDE, and so on.
By that definition, most compilers are written in almost 100%
Lisp. I can't really think of a Common Lisp compiler that
is not written in some form of Lisp (most are written in
Common Lisp).
>
> A similar but probably a bit different question is: how much of the lisp
> compilers you know involves lisp-level program transformation, and how
> much actually involves traduction to machine code ?
>
> Thanks
--
http://lispm.dyndns.org/