The CLISP compiler compiles Common Lisp programs into instruction codes
for a virtual processor. This bytecode is optimized for saving space in
the most common cases of Common Lisp programs. The main advantages/drawbacks
of this approach, compared to native code compilation, are:
- Bytecode compiled programs are a lot smaller than
when compiled to native code. This results in better use of CPU
caches, and in less virtual memory paging. Users perceive this as good
responsiveness.
- Maximum execution speed (throughput in tight loops)
is limited.
- Since no bytecode instructions are provided for
"unsafe" operations (like unchecked array accesses,
or "fast"
CAR/CDR), programs run with all safety
checks enabled even when compiled. - Execution speed of a program can easily be
understood by looking at the output of the
DISASSEMBLE function.
A rule of thumb is that every elementary instruction costs 1 time
unit, whereas a function call costs 3 to 4 time units.
- Needing to do no type inference, the compiler is
pretty straightforward and fast. As a consequence, the definition of
CLOS generic functions, which needs to compile small pieces of
generated code, is not perceived to be slow.
- The compiler is independent from the hardware CPU.
Different back-ends, one for each hardware CPU, are not needed. As a
consequence, the compiler is fairly small (and would have been easily
maintainable if it were written in a less kludgey way...), and it is
impossible for the compiler writer to introduce CPU dependent bugs.