On Wed, 1 Dec 1999 19:31:34 +0200, Miki Tebeka <·······@iil.intel.com>
wrote:
>Hello All,
>
>Any pointers?
Many: www.harlequin.com, www.franz.com, and for cmucl see
www.cons.org.
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
* Miki Tebeka wrote:
> Hello All,
> Any pointers?
Apart from the various native-code Lisp compilers? Franz & Harlequin
both sell commercial native-code systems for Unix and PC. Digitool
sell one for Macs.
CMUCL (www.cons.org I think) has an industrial-strength open source
native code compiler which generates code for various RISC machines
and now x86 if you want to see the guts of such a system.
There are many others.
--tim
Miki Tebeka <·······@iil.intel.com> writes:
>
> Hello All,
>
> Any pointers?
Allegro Common Lisp
CMUCL
Harlequin LispWorks
Macintosh Common Lisp
all these products compile to native code, and some of the other Lisps
may do so as well.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Miki Tebeka <·······@iil.intel.com> writes:
> > Any pointers?
> Allegro Common Lisp
> CMUCL
> Harlequin LispWorks
> Macintosh Common Lisp
> all these products compile to native code, and some of the other Lisps
> may do so as well.
Lucid CL (now called Liquid by Harlequin) compiles to native code.
The Lisp machine Common Lisps compile to the native code of the
corresponding Lisp machine. KCL/AKCL/GCL compiles to native code via
C. Indeed, most Common Lisps compile to native code. The question
therefore tends to become: what Common Lisp implementations still
exist.
BTW, it's not unlikely that most Lisp implementations of any sort
compile to native code, if we omit various simple implementations
that people have written for their own enlightenment.
-- j
Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
···················@todday.aiai.ed.ac.uk...
> The Lisp machine Common Lisps compile to the native code of the
> corresponding Lisp machine.
The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to
a `byte code' that was interpreted by the microcode. The later machines had
some hardware
support to accelerate interpretation of certain byte-codes.
There was a `microcode compiler' available for the LMI-Lambda that compiled
Lisp, but
it was not in general use.
"Joe Marshall" <·········@alum.mit.edu> writes:
> Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
> ···················@todday.aiai.ed.ac.uk...
> > The Lisp machine Common Lisps compile to the native code of the
> > corresponding Lisp machine.
>
> The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to
> a `byte code' that was interpreted by the microcode.
It was my understanding that "native code" could refer to an
instruction set entirely or partly implemented in microcode.
Is that usage incorrect?
Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
···················@todday.aiai.ed.ac.uk...
> "Joe Marshall" <·········@alum.mit.edu> writes:
>
> > Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
> > ···················@todday.aiai.ed.ac.uk...
> > > The Lisp machine Common Lisps compile to the native code of the
> > > corresponding Lisp machine.
> >
> > The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to
> > a `byte code' that was interpreted by the microcode.
>
> It was my understanding that "native code" could refer to an
> instruction set entirely or partly implemented in microcode.
> Is that usage incorrect?
I didn't mean to say that you were incorrect. I just wanted to clarify that
the compiler for the Lisp machines is much closer to a `byte code' compiler
than a `native code' compiler because the Lisp machine order code was
so high level.
"Joe Marshall" <·········@alum.mit.edu> writes:
>
>
> Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
> ···················@todday.aiai.ed.ac.uk...
> > "Joe Marshall" <·········@alum.mit.edu> writes:
> >
> > > Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote in message
> > > ···················@todday.aiai.ed.ac.uk...
> > > > The Lisp machine Common Lisps compile to the native code of the
> > > > corresponding Lisp machine.
> > >
> > > The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to
> > > a `byte code' that was interpreted by the microcode.
> >
> > It was my understanding that "native code" could refer to an
> > instruction set entirely or partly implemented in microcode.
> > Is that usage incorrect?
>
> I didn't mean to say that you were incorrect. I just wanted to clarify that
> the compiler for the Lisp machines is much closer to a `byte code' compiler
> than a `native code' compiler because the Lisp machine order code was
> so high level.
Sorry. It's hard to tell sometimes, and I wanted to check.
-- jeff
From: Tim Bradshaw
Subject: Re: Compile Lisp to native code?
Date:
Message-ID: <ey3r9gp8l6l.fsf@cley.com>
* Joe Marshall wrote:
> The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to a
> `byte code' that was interpreted by the microcode. The later
> machines had some hardware support to accelerate interpretation of
> certain byte-codes.
But that's really the case for any highly-microcoded machine. I
think `native code' for such a machine *is* the language that the
microcode interprets.
--tim
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
> * Joe Marshall wrote:
>
> > The CONS, CADR, 3600, LMI-Lambda, and TI Explorer compiled lisp to a
> > `byte code' that was interpreted by the microcode. The later
> > machines had some hardware support to accelerate interpretation of
> > certain byte-codes.
>
> But that's really the case for any highly-microcoded machine. I
> think `native code' for such a machine *is* the language that the
> microcode interprets.
But the Lisp machine compiler was really more of a `byte code' compiler
because the microcode allowed it to be.
Native code - what is it?
I won't argue - but here is a fact about Common Lisp.
In Data General's Common Lisp implementation, about fifteen to
twenty years ago (circa "Mary Poppins edition" timeframe),
the lisp compiler generated code for a DG machine. That
machine, I remember, had 48 DIFFERENT instruction FORMATS,
and I don't know how many different instructions. Obviously, it
was highly microcoded. It was designed for Cobol and Fortran,
as well as assembly language programming, and to be compatible
with several earlier DG machines at the object code level.
Nevertheless, the lisp compiler generated machine instructions, in many,
(possibly all) of those formats. The speed of the generated code was
about the same as that generated by the Fortran compiler (then considered
fairly good) on the same machine. I don't remember if that machine had
a "writable" control store. I know we didn't use it, if it did. I also know
that
the common "lispy" opererations, such as call/return, were faster than
Fortran. I also know that DG was not alone: DEC demoed there new lisp
at the same AAAI conference that DG did, and there approach was very
similar: so similar, that BOTH implementations were relieved to learn that
the other implementation also took 8Mbytes for the entire system. That
was considered very large in those days.
ON a machine with OODLES of writable control store, it would be appropriate,
perhaps, to put user code into control store. But, since common lisp is now
somewhat larger than it used to be (clos, loop, etc.) and since control store
is
less "semantically dense" than normal "assembly level" instructions, it would
presumably truly have to be OODLES of wriable control store, or a SECOND
compiler for "small" user programs (or parts) to be able to use the control
store
for user code.