-Many Lispy extensions have been retained from CMU CL:
-.TP 3
-\--
-CMU-CL-style safe implementation of type declarations:
-"Declarations are assertions."
-.TP 3
-\--
-the source level debugger (very similar to CMU CL's)
-.TP 3
-\--
-the profiler (now somewhat different from CMU CL's)
-.TP 3
-\--
-saving the state of the running SBCL process, producing a
-"core" file which can be restarted later
-.TP 3
-\--
-Gray streams (a de-facto standard system of overloadable CLOS classes
-whose instances can be used wherever ordinary ANSI streams can be used)
-.TP 3
-\--
-weak pointers and finalization (which have unfortunately
-suffered from at least some code rot, so that \fIe.g.\fR weak hash
-tables don't work)
-.PP
-
-Fundamental system interface extensions are also provided:
-.TP 3
-\--
-calling out to C code (a.k.a. FFI, foreign function interface,
-with very nearly the same interface as CMU CL)
-.TP 3
-\--
-some simple support for operations with a "scripting language" flavor,
-\fIe.g.\fR reading POSIX \f(CRargc\fR and \f(CRargv\fR, or executing a
-subprogram
-.PP
-
-.SH DIFFERENCES FROM CMU CL
-
-SBCL can be built from scratch using a plain vanilla ANSI Common Lisp
-system and a C compiler, and all of its properties are specified by
-the version of the source code that it was created from. This clean
-bootstrappability was the immediate motivation for forking off of the
-CMU CL development tree. A variety of implementation differences are
-motivated by this design goal.
-
-Maintenance work in SBCL since the fork has diverged somewhat from the
-maintenance work in CMU CL. Many but not all bug fixes and
-improvements have been shared between the two projects, and sometimes
-the two projects disagree about what would be an improvement.
-
-Most extensions supported by CMU CL have been unbundled from SBCL,
-including Motif support, the Hemlock editor, search paths, the
-low-level Unix interface, the WIRE protocol, various user-level macros
-and functions (\fIe.g.\fR \f(CRLETF\fR, \f(CRITERATE\fR, \f(CRMEMQ\fR,
-\f(CRREQUIRED\-ARGUMENT\fR), and many others.
-
-SBCL inplements multithreading, but in a completely different fashion
-from CMU CL: see the User Manual for details. As of 0.8.5 this is
-considered beta-quality and must be explicitly enabled at build time.
-
-SBCL has retained some extensions from its parent CMU CL. Many of the
-retained extensions are in these categories:
-.TP 3
-\--
-things which might be in the new ANSI spec, \fIe.g.\fR safe type
-declarations, weak pointers, finalization, foreign function
-interface to C, and Gray streams;
-.TP 3
-\--
-things which are universally available in Unix scripting languages,
-\fIe.g.\fR \f(CRRUN\-PROGRAM\fR and POSIX \f(CRargv\fR and \f(CRgetenv\fR;
-.TP 3
-\--
-hooks into the low level workings of the system which can be useful
-for debugging, \fIe.g.\fR requesting that a particular function be executed
-whenever GC occurs, or tuning compiler diagnostic output;
-.TP 3
-\--
-unportable performance hacks, \fIe.g.\fR \f(CRFREEZE\-TYPE\fR and
-\f(CRPURIFY\fR. For more information about these, look at the online
-documentation for symbols in the \f(CRSB\-EXT\fR package, and look at the user
-manual.
-.PP
-
-There are also a few retained extensions which don't fall into any
-particular category, \fIe.g.\fR the ability to save running Lisp images as
-executable files.
-
-Some of the retained extensions have new names and/or different
-options than their CMU CL counterparts. For example, the SBCL function
-which saves a Lisp image to disk and kills the running process is
-called \f(CRSAVE\-LISP\-AND\-DIE\fR instead of \f(CRSAVE\-LISP\fR, and
-SBCL's \f(CRSAVE\-LISP\-AND\-DIE\fR supports fewer keyword options
-than CMU CL's \f(CRSAVE\-LISP\fR does.
-
-(Why doesn't SBCL support more extensions natively? Why drop all
-those nice extensions from CMU CL when the code already exists? This
-is a frequently asked question on the mailing list. There are two
-principal reasons. First, it's a design philosophy issue: arguably
-SBCL has done its job by supplying a stable FFI, and the right design
-decision is to move functionality derived from that, like socket
-support, into separate libraries. Some of these are distributed with
-SBCL as "contrib" modules, others are distributed as separate software
-packages by separate maintainers. Second, it's a practical decision -
-focusing on a smaller number of things will, we hope, let us do a
-better job on them.)
-
-.SH THE COMPILER
-
-SBCL inherits from CMU CL the "Python" native code compiler. (Though
-we often avoid that name in order to avoid confusion with the
-scripting language also called Python.) This compiler is very clever
-about understanding the type system of Common Lisp and using it to
-optimize code, and about producing notes to let the user know when the
-compiler doesn't have enough type information to produce efficient
-code. It also tries (almost always successfully) to follow the unusual
-but very useful principle that "declarations are assertions", \fIi.e.\fR
-type declarations should be checked at runtime unless the user
-explicitly tells the system that speed is more important than safety.
-
-The compiler reportedly produces pretty good code for modern CPU
-architectures which have lots of registers, but its code for the X86
-is marred by many extra loads and stores to stack-based temporary
-variables. Because of this, and because of the extra levels of
-indirection in Common Lisp relative to C, the performance of SBCL
-isn't going to impress people who are impressed by small constant
-factors. However, even on the X86 it tends to be faster than byte
-interpreted languages (and can be a lot faster).
-
-The compiled code uses garbage collection to automatically
-manage memory. The garbage collector implementation varies considerably
-from CPU to CPU. In particular, on some CPUs the GC is nearly exact,
-while on others it's more conservative, and on some CPUs the GC
-is generational, while on others simpler stop and copy strategies
-are used.