SBCL is derived from CMU CL, which implements many extensions to the ANSI standard. SBCL doesn't support as many extensions as CMU CL, but it still has quite a few.
SBCL provides extensive support for calling external C code, described in its own chapter.
SBCL provides additional garbage collection functionality not specified by ANSI. Weak pointers allow references to objects to be maintained without keeping them from being GCed. And "finalization" hooks are available to cause code to be executed when an object is GCed.
SBCL supports Gray streams, user-overloadable CLOS classes whose instances can be used as Lisp streams (e.g. passed as the first argument to format).
SBCL supports a MetaObject Protocol which is intended to be compatible with AMOP; exceptions to this (as distinct from current bugs) are that compute-effective-method only returns one value, not two.
The UNIX command line can be read from the variable sb-ext:*posix-argv*. The UNIX environment can be queried with the sb-ext:posix-getenv function.
The SBCL system can be terminated with sb-ext:quit, optionally returning a specified numeric value to the calling Unix process. The normal Unix idiom of terminating on end of file on input is also supported.
The behaviour of require when called with only one argument is implementation-defined. In SBCL it calls functions on the user-settable list sb-ext:*module-provider-functions* - see the require documentation string for details.
The toplevel repl prompt may be customized, and the function that reads user input may be replaced completely.
SBCL provides a profiler and other extensions to the ANSI trace facility. See the online function documentation for trace for more information.
The debugger supports a number of options. Its documentation is accessed by typing help at the debugger prompt.
Documentation for inspect is accessed by typing help at the inspect prompt.
SBCL has the ability to save its state as a file for later execution. This functionality is important for its bootstrapping process, and is also provided as an extension to the user See the documentation for sb-ext:save-lisp-and-die for more information.
Note: SBCL has inherited from CMU CL various hooks to allow the user to tweak and monitor the garbage collection process. These are somewhat stale code, and their interface might need to be cleaned up. If you have urgent need of them, look at the code in src/code/gc.lisp and bring it up on the developers' mailing list.
Note: SBCL has various hooks inherited from CMU CL, like sb-ext:float-denormalized-p, to allow a program to take advantage of IEEE floating point arithmetic properties which aren't conveniently or efficiently expressible using the ANSI standard. These look good, and their interface looks good, but IEEE support is slightly broken due to a stupid decision to remove some support for infinities (because it wasn't in the ANSI spec and it didn't occur to me that it was in the IEEE spec). If you need this stuff, take a look at the code and bring it up on the developers' mailing list.
The sb-ext:purify function causes SBCL first to collect all garbage, then to mark all uncollected objects as permanent, never again attempting to collect them as garbage. This can cause a large increase in efficiency when using a primitive garbage collector, or a more moderate increase in efficiency when using a more sophisticated garbage collector which is well suited to the program's memory usage pattern. It also allows permanent code to be frozen at fixed addresses, a precondition for using copy-on-write to share code between multiple Lisp processes. is less important with modern generational garbage collectors.
The sb-ext:truly-the operator does what the cl:the operator does in a more conventional implementation of Common Lisp, declaring the type of its argument without any runtime checks. (Ordinarily in SBCL, any type declaration is treated as an assertion and checked at runtime.)
The sb-ext:freeze-type declaration declares that a type will never change, which can make type testing (typep, etc.) more efficient for structure types.
The sb-ext:constant-function declaration specifies that a function will always return the same value for the same arguments, which may allow the compiler to optimize calls to it. This is appropriate for functions like sqrt, but is not appropriate for functions like aref, which can change their return values when the underlying data are changed.