Projects: improvements to CMUCL
Here is a (partial) list of projects which are either underway, or
would be useful to CMUCL users. Please join the cmucl-imp mailing list if you are interested in
contributing to one of these projects.
- Searching for, and resolving, any remaining divergences from the ANSI
Common Lisp specification (many of which have been fixed during the
year 2002). The ansi-test suite in CLOCC, and the test suite included with the
GCL source code, are useful for this.
- Peter Van Eynde is working on changing CMUCL's memory management
so that it can allocate memory lazily, thus overcoming the
overcommiting problem on recent linux kernels.
- cross-compile from an ANSI Common Lisp: Bill Newman has developed a
derivative of CMUCL called Steel Bank Common Lisp which is
able to cross-compile itself from an arbitrary Common Lisp
implementation (currently the only way to port CMUCL to a new hardware
architecture is to cross-compile it from a CMUCL running on a
currently supported architecture, which is a delicate process). Some
of the cleanups made to SBCL could advantageously be back-ported to
- reviving the HPPA port.
- win32 port: a few people investigated the possibility
of using the POSIX emulation layer provided by the cygwin32 tools
to port CMUCL to win32. Given the problems with memory
management facilities provided by this library, as well as
licencing issues, a native port would be more useful. The primary
issues to resolve are memory management and signal handling.
- add 64-bit support. CMUCL currently only works with 32 bit addresses,
even on platforms like UltraSPARC, which could support 64-bit
applications. Raymond Toy is thinking about how to approach this
- add a peephole optimizer to the CMUCL assembler, to remove useless
bits of the instruction stream.
- Porting multiprocessing to other
platforms than x86. This requires knowledge of assembly and of the
internals of CMUCL.
- Write a soft-real-time garbage collector for CMUCL, for applications
such as games where bounded response time is very important.
- improving Garnet: the Garnet user-interface toolkit is no longer
maintained by the CMU Interfaces group which developed it. There are
always bugfixes to integrate in the code and improvements to add. Fred
Gilham is looking after this.
- Allow PCL to emit LAP bytecode, instead of calling the compiler at
runtime. This would allow small CLOS-enabled CMUCL images to be built.
(Currently, it is possible to build quite small "runtime"
images without the compiler, but these cannot be built with CLOS
support, because PCL requires the compiler to be present at runtime.)
- The McCLIM project aims to
produce a free version of the CLIM user-interface specification. It
would make a good subtrate for sophisticated interactors, browsers and
code navigation tools.
- A port to the
Flux OSKit, to produce CMUCL-OS.