1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title>Overview Of SBCL, How It Works And Where It Came From</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><link rel="home" href="index.html" title="SBCL User Manual" /><link rel="up" href="intro.html" title="Chapter1.Introduction" /><link rel="previous" href="where-more.html" title="Where To Go For More Information About SBCL" /><link rel="next" href="compiler.html" title="Chapter2.The Compiler" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Overview Of SBCL, How It Works And Where It Came From</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="where-more.html">Prev</a></td><th width="60%" align="center">Chapter1.Introduction</th><td width="20%" align="right"><a accesskey="n" href="compiler.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="implementation"></a>Overview Of SBCL, How It Works And Where It Came From</h2></div></div><div></div></div><p>You can work productively with SBCL without knowing anything
understanding anything about where it came from, how it is implemented,
or how it extends the <span class="acronym">ANSI</span> Common Lisp standard. However,
a little knowledge can be helpful in order to understand error
messages, to troubleshoot problems, to understand why some parts of
the system are better debugged than others, and to anticipate which
known bugs, known performance problems, and missing extensions are
likely to be fixed, tuned, or added. </p><p><span class="application">SBCL</span> is descended from <span class="application">CMU CL</span>, which is itself descended from
Spice Lisp, including early implementations for the Mach operating
system on the IBM RT, back in the 1980s. Design decisions from that
time are still reflected in the current implementation:
</p><div class="itemizedlist"><ul type="disc"><li><p>The system expects to be loaded into a
fixed-at-compile-time location in virtual memory, and also expects
the location of all of its heap storage to be specified
at compile time.</p></li><li><p>The system overcommits memory, allocating large
amounts of address space from the system (often more than
the amount of virtual memory available) and then failing
if ends up using too much of the allocated storage.</p></li><li><p>A word is a 32-bit quantity. The system has been
ported to many processor architectures without altering this
basic principle. Some hacks allow the system to run on the Alpha
chip (a 64-bit architecture) but even there 32-bit words are
used. The assumption that a word is
32 bits wide is implicit in hundreds of places in the
system.</p></li><li><p>The system is implemented as a C program which is
responsible for supplying low-level services and loading a
Lisp “<span class="quote">.core</span>” file.
</p></li></ul></div><p>
</p><p><span class="application">SBCL</span> also inherited some newer architectural features from
<span class="application">CMU CL</span>. The most important is that it has a generational garbage
collector (“<span class="quote">GC</span>”), which has various implications (mostly good)
for performance. These are discussed in <a href="efficiency.html" title="Chapter3.Efficiency">
another chapter</a>.</p><p><span class="application">SBCL</span> has diverged from <span class="application">CMU CL</span> in that <span class="application">SBCL</span> is now
essentially a “<span class="quote">compiler-only implementation</span>” of
Common Lisp. A Common Lisp implementation is permitted to implement
both a compiler and an interpreter, and there's some special support
in the standard (e.g. the distinction between <tt class="function">functionp</tt>
and <tt class="function">compiled-function-p</tt>) to help support that. But <span class="application">SBCL</span>
has only a vestigial, rudimentary true interpreter. In <span class="application">SBCL</span>, the
<tt class="function">eval</tt> function only truly “<span class="quote">interprets</span>” a few
special classes of forms, such as symbols which are
<tt class="function">boundp</tt>. More complicated forms are evaluated by calling
<tt class="function">compile</tt> and then calling <tt class="function">funcall</tt> on the
returned result.
</p><p>The direct ancestor of <span class="application">SBCL</span> is the X86 port of <span class="application">CMU CL</span>. This
port was in some ways the most cobbled-together of all the <span class="application">CMU CL</span>
ports, since a number of strange changes had to be made to support the
register-poor X86 architecture. Some things (like tracing and
debugging) do not work particularly well there. <span class="application">SBCL</span> should be able
to improve in these areas (and has already improved in some other
areas), but it takes a while.</p><p>On the x86, <span class="application">SBCL</span> like the X86 port of <span class="application">CMU CL</span>, uses a
<span class="emphasis"><em>conservative</em></span> GC. This means that it doesn't maintain a
strict separation between tagged and untagged data, instead treating
some untagged data (e.g. raw floating point numbers) as
possibly-tagged data and so not collecting any Lisp objects that they
point to. This has some negative consequences for average time
efficiency (though possibly no worse than the negative consequences of
trying to implement an exact GC on a processor architecture as
register-poor as the X86) and also has potentially unlimited
consequences for worst-case memory efficiency. In practice,
conservative garbage collectors work reasonably well, not getting
anywhere near the worst case. But they can occasionally cause
odd patterns of memory usage.</p><p>The fork from <span class="application">CMU CL</span> was based on a major rewrite of the system
bootstrap process. <span class="application">CMU CL</span> has for many years tolerated a very unusual
“<span class="quote">build</span>” procedure which doesn't actually build the complete
system from scratch, but instead progressively overwrites parts of a
running system with new versions. This quasi-build procedure can cause
various bizarre bootstrapping hangups, especially when a major change
is made to the system. It also makes the connection between the
current source code and the current executable more tenuous than in
other software systems -- it's easy to accidentally
“<span class="quote">build</span>” a <span class="application">CMU CL</span> system containing characteristics not
reflected in the current version of the source code.</p><p>Other major changes since the fork from <span class="application">CMU CL</span> include
</p><div class="itemizedlist"><ul type="disc"><li><p><span class="application">SBCL</span> has dropped support for many <span class="application">CMU CL</span> extensions,
(e.g. IP networking, remote procedure call, Unix system interface, and X11
interface). Some of these are now available as contributed or
third-party modules.</p></li><li><p><span class="application">SBCL</span> has deleted or deprecated
some nonstandard features and code complexity which helped
efficiency at the price of maintainability. For example, the
<span class="application">SBCL</span> compiler no longer implements memory pooling internally
(and so is simpler and more maintainable, but generates more
garbage and runs more slowly), and various block-compilation
efficiency-increasing extensions to the language have been
deleted or are no longer used in the implementation of <span class="application">SBCL</span>
itself.</p></li></ul></div><p>
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="where-more.html">Prev</a></td><td width="20%" align="center"><a accesskey="u" href="intro.html">Up</a></td><td width="40%" align="right"><a accesskey="n" href="compiler.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Where To Go For More Information About SBCL</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">Chapter2.The Compiler</td></tr></table></div></body></html>
|
