CMUCL is a free Common Lisp implementation, originally developed at Carnegie Mellon University.
| Original author(s) | Carnegie Mellon University |
|---|---|
| Developer(s) | Various |
| Initial release | Early 1980 |
| Stable release | 21e[1]
/ May 14, 2023 |
| Repository | |
| Operating system | Several POSIX-compliant OSs |
| Platform | Cross-platform |
| Available in | Common Lisp |
| Type | Compiler and runtime |
| License | Public domain |
| Website | cmucl |
CMUCL runs on most Unix-like platforms, including Linux and BSD; there is an experimental Windows port as well. Steel Bank Common Lisp is derived from CMUCL. The Scieneer Common Lisp was a commercial derivative from CMUCL.
History
editThe earliest implementation predates Common Lisp and was part of Spice Lisp, around 1980. In 1985 Rob MacLachlan started re-writing the compiler to what would become the Python compiler and CMUCL was ported to Unix workstations such as the IBM PC RT, MIPS and SPARC. Early CMUCL releases did not support Intel's x86 architecture due to a lack of registers. CMUCL strictly separated type-tagged and immediate data types and the garbage collector would rely on knowing that one half of the CPU registers could only hold tagged types and the other half only untagged types. This did not leave enough registers for a Python backend.
After CMU canceled the project (in favor of a Dylan implementation using some of CMUCL's compiler base) maintenance has been taken over by a group of volunteers. By 1996 this group was making regular releases on its own infrastructure.
Around the same time a port to Intel's x86 architecture was completed, first running on FreeBSD, later Linux. The problem of lacking registers was solved by a new conservative garbage collector. This new garbage collector accepts any value of any type in the registers, and treats anything that might be a pointer as a pointer for the purpose of not collecting or moving its target.
Compiler and other code execution units
edit- CMUCL features an interpreter that is mainly used for the REPL, but can be used for faster loading of Lisp files that don't need compilation.
- A machine to interpret compact bytecode (which can be emitted from the compiler). This is rarely used now, but was popular in early CMUCL releases because image sizes were drastically reduced at a time where download bandwidth on the Internet was low.
- A native code compiler named "Python" (not to be confused with the Python programming language). If Common Lisp source code has been written with appropriate declarations and is organized with speed in mind the Python compiler generates code that is almost free from overhead compared to code compiled from languages like C++. Some inefficiencies such as function call interfaces and lack of pointer-free arrays of user-defined data types are dictated by the Common Lisp standard and still need to be worked around (e.g. by inlining more and using macros to build constructs that look like user-defined structures but are actually accessing fields in preallocated specialized arrays). The Python compiler also features powerful type inferences, helping the programmer in writing overhead-free code by either inferring types automatically or issuing hints about missed optimization opportunities.
Features
edit- Generational garbage collection and multiprocessing capability on the x86 ports.
- A foreign function interface which allows interfacing with C code and system libraries, including shared libraries on most platforms, and direct access to Unix system calls.
- Support for interprocess communication and remote procedure calls.
- An implementation of CLOS, the Common Lisp Object System, which includes multimethods and a metaobject protocol.
- A graphical source-level debugger using a Motif interface, and a code profiler.
- An interface to the X11 Window System (CLX), and a sophisticated graphical widget library (Garnet).
- Programmer-extensible input and output streams.
- Hemlock, an Emacs-like editor implemented in Common Lisp.
