37.1. Introduction

37.1. Introduction
Prev	Chapter 37. The CLISP bytecode specification	Next

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.