Status of cmucl.

[Peter.VanEynde]

I actually shouldn't be writing this (there are more capable people), but
I feel a need for clarification about CMUCL.

It runs on sparc,hp,alpha,x86,mips and the ibm-rt :-). It has a
bytecompiler, and a native compiler that can perform miracles. At present
I can propagate type information (new are the added floating point
propagations), so that the most precise declaration is also the most
effective. For instance the compiler "knows" that

(defun f (x)
 (declare (type (integer -10 10) x))
 (* x x))

returns an (integer 0 100). The compiler knows a lot about the machine and
can (on riscs machines) produce code as fast as C. On x86 the code
generation isn't _that_  good. Yet. It beats all non-C compilers, but
still isn't fast enough.

As of the new releases _all_ math functions are _perfectly_ well behaving
in the complex plane. All branch-cuts are where they should be. This isn't
a trivial matter.

The CL standard library is _huge_. It would be a shame to throw all this
work away just to start over in a "new" Lisp.

It uses all the Unix tricks in the book. But it main interface to the OS
is mmap. (in the beginning, this was for a while the only function that
"worked" in the Linux port) So it is already pretty OS independent, it is
just UNIX centric because this was the only way to implement the advanced
features needed to simulate a lisp-workstation (IIRC the original intent
of "Spice Lisp").

Currently, people are working on improving the disassembler, improving the
backtrace, adding and improving the propagators, rewriting the random
number generator, writing a new generational GC (with features build-in
that should make multi-threading easy), more primitive vectors, etc.

The same people are also porting the free-clim effort, cl-http, series,
etc. I myself am trying to find time to fix a few bugs in clue wrt to 16
bit screens (I like afterstep).

The biggest problem at the moment is the lack of a portable GUI library.
People should look at free-clim (also on cons.org) and try to help. This
could also be used on other lisp compilers.

In the future I would like to see multi-threading. This would be done with
clone on Linux and playing around with shared and COW memory regions. I
don't see a need for much _more_ OS control. It would be nice to GC only
the memory _in_ memory, or to have page-in-out control, but all of this
can be done with a kernel module. At most we will need a few hooks in the
normal kernel.

It would also be _very_ nice to have clisp as a netscape plug-in like java
:-).

Groetjes, Peter

--
It's logic Jim, but not as we know it.
Look in keyservers for PGP key.
Version: 3.12
GS/CS/L/C d->? s+:++>+@ a-- C++(+++)>$ ULOS++>++++$ P+>++++ L+++>++++
E>++ W+(--) U++>+++ o>+ K? w--- O>+@ M-? V? PS++ PE(--) Y+ PGP+>++
t++>+++ 5++ X++>+++ R tv b+++>++++ DI++ D++@ G+>++ e++>++++ h!>+ r-@ y>+++**@