1 ;;;; tags which are set during the build process and which end up in
2 ;;;; CL:*FEATURES* in the target SBCL, plus some comments about other
3 ;;;; CL:*FEATURES* tags which have special meaning to SBCL or which
4 ;;;; have a special conventional meaning
6 ;;;; Note that the recommended way to customize the features of a
7 ;;;; local build of SBCL is not to edit this file, but instead to
8 ;;;; tweak customize-target-features.lisp. E.g. you can use code like
11 ;;;; (flet ((enable (x) (pushnew x list))
12 ;;;; (disable (x) (setf list (remove x list))))
13 ;;;; #+nil (enable :sb-show)
14 ;;;; (enable :sb-after-xc-core)
15 ;;;; #+nil (disable :sb-doc)
17 ;;;; That way, because customize-target-features.lisp is in
18 ;;;; .cvsignore, your local changes will remain local even if you use
19 ;;;; "cvs diff" to submit patches to SBCL.
21 ;;;; This software is part of the SBCL system. See the README file for
22 ;;;; more information.
24 ;;;; This software is derived from the CMU CL system, which was
25 ;;;; written at Carnegie Mellon University and released into the
26 ;;;; public domain. The software is in the public domain and is
27 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
28 ;;;; files for more information.
32 ;; features present in all builds
37 ;; FIXME: Isn't there a :x3jsomething feature which we should set too?
42 ;; Douglas Thomas Crosher's conservative generational GC (the only one
43 ;; we currently support for X86)
46 ;; We're running under a UNIX. This is sort of redundant, and it was also
47 ;; sort of redundant under CMU CL, which we inherited it from: neither SBCL
48 ;; nor CMU CL supports anything but UNIX (and "technically not UNIX"es
49 ;; such as *BSD and Linux). But someday, maybe we might, and in that case
50 ;; we'd presumably remove this, so its presence conveys the information
51 ;; that the system isn't one which follows such a change.
55 ;; features present in this particular build
58 ;; Setting this enables the compilation of documentation strings
59 ;; from the system sources into the target Lisp executable.
60 ;; Traditional Common Lisp folk will want this option set.
61 ;; I (WHN) made it optional because I came to Common Lisp from
62 ;; C++ through Scheme, so I'm accustomed to asking
63 ;; Emacs about things that I'm curious about instead of asking
64 ;; the executable I'm running.
67 ;; When this is set, EVAL is implemented as an "IR1 interpreter":
68 ;; code is compiled into the compiler's first internal representation,
69 ;; then the IR1 is interpreted. When this is not set, EVAL is implemented
70 ;; as a little bit of hackery wrapped around a call to COMPILE, i.e.
71 ;; the system becomes a "compiler-only implementation" of Common Lisp.
72 ;; As of sbcl-0.6.7, the compiler-only implementation is prototype code,
73 ;; and much less mature than the old IR1 interpreter. Thus, the safe
74 ;; thing is to leave :SB-INTERPRETER set. However, the compiler-only
75 ;; system is noticeably smaller, so you might want to omit
76 ;; :SB-INTERPRETER if you have a small machine.
78 ;; Probably, the compiler-only implementation will become more
79 ;; stable someday, and support for the IR1 interpreter will then be
80 ;; dropped. This will make the system smaller and easier to maintain
81 ;; not only because we no longer need to support the interpreter,
82 ;; but because code elsewhere in the system (the dumper, the debugger,
83 ;; etc.) no longer needs special cases for interpreted code.
86 ;; Do regression and other tests when building the system. You
87 ;; might or might not want this if you're not a developer,
88 ;; depending on how paranoid you are. You probably do want it if
89 ;; you are a developer.
92 ;; :SB-PROPAGATE-FLOAT-TYPE and :SB-PROPAGATE-FUN-TYPE enable
93 ;; some numeric optimizer code in the target compiler. They
94 ;; correspond to the :PROPAGATE-FLOAT-TYPE and :PROPAGATE-FUN-TYPE
95 ;; features in the original CMU CL code, and while documentation
96 ;; existed for those, it seemed a little inconsistent. Despite the
97 ;; name, :SB-PROPAGATE-FLOAT-TYPE seems to control not only
98 ;; floating point optimizations, but some integer optimizations as
101 ;; CROSS-FLOAT-INFINITY-KLUDGE:
102 ;; * Even when these target features are enabled, the optimizations
103 ;; aren't enabled in the cross-compiler, because some of them
104 ;; depend on floating point infinities, which aren't in general
105 ;; supported on the cross-compilation host.
106 ;; * This is supported by hacking the features out of the
107 ;; *SHEBANG-FEATURES* list while we're building the cross-compiler.
108 ;; This is ugly and confusing and weird, but all the alternatives
109 ;; that I could think of seem messy and error-prone. That doesn't
110 ;; mean there's not a better way, though. Suggestions are welcome;
111 ;; or if you'd like to submit patches to make this code work
112 ;; without requiring floating point infinities, so that the entire
113 ;; problem goes away, that might be even better! -- WHN 2001-03-22
114 :sb-propagate-float-type
115 :sb-propagate-fun-type
117 ;; Make more debugging information available (for debugging SBCL
118 ;; itself). If you aren't hacking or troubleshooting SBCL itself,
119 ;; you probably don't want this set.
121 ;; At least two varieties of debugging information are enabled by this
123 ;; * SBCL is compiled with a higher level of OPTIMIZE DEBUG, so that
124 ;; the debugger can tell more about the state of the system.
125 ;; * Various code to print debugging messages, and similar debugging code,
126 ;; is compiled only when this feature is present.
128 ;; Note that the extra information recorded by the compiler at
129 ;; this higher level of OPTIMIZE DEBUG includes the source location
130 ;; forms. In order for the debugger to use this information, it has to
131 ;; re-READ the source file. In an ordinary installation of SBCL, this
132 ;; re-READing may not work very well, for either of two reasons:
133 ;; * The sources aren't present on the system in the same location that
134 ;; they were on the system where SBCL was compiled.
135 ;; * SBCL is using the standard readtable, without the added hackage
136 ;; which allows it to handle things like target features.
137 ;; If you want to be able to use the extra debugging information,
138 ;; therefore, be sure to keep the sources around, and run with the
139 ;; readtable configured so that the system sources can be read.
142 ;; Build SBCL with the old CMU CL low level debugger, "ldb". If
143 ;; are aren't messing with CMU CL at a very low level (e.g.
144 ;; trying to diagnose GC problems) you shouldn't need this.
147 ;; This isn't really a target Lisp feature at all, but controls
148 ;; whether the build process produces an after-xc.core file. This
149 ;; can be useful for shortening the edit/compile/debug cycle if
150 ;; you're messing around with low-level internals of the system,
151 ;; as in slam.sh. Otherwise you don't need it.
154 ;; Enable extra debugging output in the assem.lisp assembler/scheduler
155 ;; code. (This is the feature which was called :DEBUG in the
156 ;; original CMU CL code.)
159 ;; Setting this makes SBCL more "fluid", i.e. more amenable to
160 ;; modification at runtime, by suppressing various INLINE declarations,
161 ;; compiler macro definitions, FREEZE-TYPE declarations; and by
162 ;; suppressing various burning-our-ships-behind-us actions after
163 ;; initialization is complete; and so forth. This tends to clobber the
164 ;; performance of the system, so unless you have some special need for
165 ;; this when hacking SBCL itself, you don't want this set.
168 ;; Enable code for collecting statistics on usage of various operations,
169 ;; useful for performance tuning of the SBCL system itself. This code
170 ;; is probably pretty stale (having not been tested since the fork from
171 ;; base CMU CL) but might nonetheless be a useful starting point for
172 ;; anyone who wants to collect such statistics in the future.
175 ;; Peter Van Eynde's increase-bulletproofness code
177 ;; This is not maintained or tested in current SBCL, but I haven't
178 ;; gone out of my way to remove or break it, either.
181 ; :high-security-support
183 ;; multiprocessing support
185 ;; This is not maintained or tested in current SBCL. I haven't gone out
186 ;; of my way to break it, but since it's derived from an old version of
187 ;; CMU CL where multiprocessing was pretty shaky, it's likely to be very
189 ;; :MP enables multiprocessing
190 ;; :MP-I486 is used, only within the multiprocessing code, to control
191 ;; what seems to control processor-version-specific code. It's
192 ;; probably for 486 or later, i.e. could be set as long as
193 ;; you know you're not running on a 386, but it doesn't seem
194 ;; to be documented anywhere, so that's just a guess.
198 ;; This affects the definition of a lot of things in bignum.lisp. It
199 ;; doesn't seem to be documented anywhere what systems it might apply
200 ;; to. It doesn't seem to be needed for X86 systems anyway.
203 ;; This is probably true for some processor types, but not X86. It
204 ;; affects a lot of floating point code.
205 ; :negative-zero-is-not-zero
207 ;; It's unclear to me what this does (but it was enabled in the code
208 ;; that I picked up from Peter Van Eynde, called CONSTRAIN-FLOAT-TYPE
209 ;; instead of SB-CONSTRAIN-FLOAT-TYPE). -- WHN 19990224
210 :sb-constrain-float-type
212 ;; This is set in classic CMU CL, and presumably there it means
213 ;; that the floating point arithmetic implementation
214 ;; conforms to IEEE's standard. Here it definitely means that the
215 ;; floating point arithmetic implementation conforms to IEEE's standard.
216 ;; I (WHN 19990702) haven't tried to verify
217 ;; that it does conform, but it should at least mostly conform (because
218 ;; the underlying x86 hardware tries).
221 ;; This seems to be the pre-GENCGC garbage collector for CMU CL, which was
222 ;; AFAIK never supported for the X86.
225 ;; CMU CL had, and we inherited, code to support 80-bit LONG-FLOAT on the x86
226 ;; architecture. Nothing has been done to actively destroy the long float
227 ;; support, but it hasn't been thoroughly maintained, and needs at least
228 ;; some maintenance before it will work. (E.g. the LONG-FLOAT-only parts of
229 ;; genesis are still implemented in terms of unportable CMU CL functions
230 ;; which are not longer available at genesis time in SBCL.) A deeper
231 ;; problem is SBCL's bootstrap process implicitly assumes that the
232 ;; cross-compilation host will be able to make the same distinctions
233 ;; between floating point types that it does. This assumption is
234 ;; fundamentally sleazy, even though in practice it's unlikely to break down
235 ;; w.r.t. distinguishing SINGLE-FLOAT from DOUBLE-FLOAT; it's much more
236 ;; likely to break down w.r.t. distinguishing DOUBLE-FLOAT from LONG-FLOAT.
237 ;; Still it's likely to be quite doable to get LONG-FLOAT support working
238 ;; again, if anyone's sufficiently motivated.
242 ;; miscellaneous notes on other things which could have special significance
243 ;; in the *FEATURES* list
246 ;; notes on the :NIL and :IGNORE features:
248 ;; #+NIL is used to comment out forms. Occasionally #+IGNORE is used
249 ;; for this too. So don't use :NIL or :IGNORE as the names of features..
251 ;; notes on :SB-XC and :SB-XC-HOST features (which aren't controlled by this
252 ;; file, but are instead temporarily pushed onto *FEATURES* or
253 ;; *TARGET-FEATURES* during some phases of cross-compilation):
255 ;; :SB-XC-HOST stands for "cross-compilation host" and is in *FEATURES*
256 ;; during the first phase of cross-compilation bootstrapping, when the
257 ;; host Lisp is being used to compile the cross-compiler.
259 ;; :SB-XC stands for "cross compiler", and is in *FEATURES* during the second
260 ;; phase of cross-compilation bootstrapping, when the cross-compiler is
261 ;; being used to create the first target Lisp.
263 ;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
266 ;; This is a flag for whether we're in the assembler. It's
267 ;; temporarily pushed onto the *FEATURES* list in the setup for
268 ;; the ASSEMBLE-FILE function. It would be a bad idea
269 ;; to use it as a name for a permanent feature.
271 ;; notes on local features (which are set automatically by the
272 ;; configuration script, and should not be set here unless you
273 ;; really, really know what you're doing):
275 ;; machine architecture features:
277 ;; any Intel 386 or better, or compatibles like the AMD K6 or K7
279 ;; DEC/Compaq Alpha CPU
280 ;; (No other CPUs are supported by SBCL as of 0.6.12.15, but SPARC or
281 ;; PowerPC support could be ported from CMU CL if anyone is
282 ;; sufficiently motivated to do so, or if you're *really* motivated,
283 ;; you could write a port from scratch for a new CPU architecture.)
284 ;; (CMU CL also had a :pentium feature, which affected the definition
285 ;; of some floating point vops. It was present but not enabled or
286 ;; documented in the CMU CL code that SBCL is derived from, and is
287 ;; present but stale in SBCL as of 0.6.12.)
289 ;; operating system features:
290 ;; :linux = We're intended to run under some version of Linux.
291 ;; :bsd = We're intended to run under some version of BSD Unix. (This
292 ;; is not exclusive with the features which indicate which
293 ;; particular version of BSD we're intended to run under.)
294 ;; :freebsd = We're intended to run under FreeBSD.
295 ;; :openbsd = We're intended to run under FreeBSD.
296 ;; (No others are supported by SBCL as of 0.6.7, but :hpux or
297 ;; :solaris support could be ported from CMU CL if anyone is
298 ;; sufficiently motivated to do so, and it'd even be possible,
299 ;; though harder, to port the system to Microsoft Windows.)