3 ;;;; tags which are set during the build process and which end up in
4 ;;;; CL:*FEATURES* in the target SBCL, plus some comments about other
5 ;;;; CL:*FEATURES* tags which have special meaning to SBCL or which
6 ;;;; have a special conventional meaning
8 ;;;; Note that the recommended way to customize the features of a
9 ;;;; local build of SBCL is not to edit this file, but instead to
10 ;;;; tweak customize-target-features.lisp. If you define a function
11 ;;;; in customize-target-features.lisp, it will be used to transform
12 ;;;; the target features list after it's read and before it's used.
13 ;;;; E.g. you can use code like this:
15 ;;;; (flet ((enable (x) (pushnew x list))
16 ;;;; (disable (x) (setf list (remove x list))))
17 ;;;; #+nil (enable :sb-show)
18 ;;;; (enable :sb-after-xc-core)
19 ;;;; #+nil (disable :sb-doc)
21 ;;;; By thus editing a local file (one which is not in the source
22 ;;;; distribution, and which is in .cvsignore) your customizations
23 ;;;; will remain local even if you do things like "cvs update",
24 ;;;; will not show up if you try to submit a patch with "cvs diff",
25 ;;;; and might even stay out of the way if you use other non-CVS-based
26 ;;;; methods to upgrade the files or store your configuration.
28 ;;;; This software is part of the SBCL system. See the README file for
29 ;;;; more information.
31 ;;;; This software is derived from the CMU CL system, which was
32 ;;;; written at Carnegie Mellon University and released into the
33 ;;;; public domain. The software is in the public domain and is
34 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
35 ;;;; files for more information.
39 ;; features present in all builds
44 ;; FIXME: Isn't there a :x3jsomething feature which we should set too?
45 ;; No. CLHS says ":x3j13 [...] A conforming implementation might or
46 ;; might not contain such a feature." -- CSR, 2002-02-21
51 ;; Douglas Thomas Crosher's conservative generational GC (the only one
52 ;; we currently support for X86).
53 ;; :gencgc used to be here; CSR moved it into
54 ;; local-target-features.lisp-expr via make-config.sh, as alpha,
55 ;; sparc and ppc ports don't currently support it. -- CSR, 2002-02-21
57 ;; We're running under a UNIX. This is sort of redundant, and it was also
58 ;; sort of redundant under CMU CL, which we inherited it from: neither SBCL
59 ;; nor CMU CL supports anything but UNIX (and "technically not UNIX"es
60 ;; such as *BSD and Linux). But someday, maybe we might, and in that case
61 ;; we'd presumably remove this, so its presence conveys the information
62 ;; that the system isn't one which follows such a change.
66 ;; features present in this particular build
69 ;; Setting this enables the compilation of documentation strings
70 ;; from the system sources into the target Lisp executable.
71 ;; Traditional Common Lisp folk will want this option set.
72 ;; I (WHN) made it optional because I came to Common Lisp from
73 ;; C++ through Scheme, so I'm accustomed to asking
74 ;; Emacs about things that I'm curious about instead of asking
75 ;; the executable I'm running.
78 ;; Do regression and other tests when building the system. You
79 ;; might or might not want this if you're not a developer,
80 ;; depending on how paranoid you are. You probably do want it if
81 ;; you are a developer.
84 ;; Make more debugging information available (for debugging SBCL
85 ;; itself). If you aren't hacking or troubleshooting SBCL itself,
86 ;; you probably don't want this set.
88 ;; At least two varieties of debugging information are enabled by this
90 ;; * SBCL is compiled with a higher level of OPTIMIZE DEBUG, so that
91 ;; the debugger can tell more about the state of the system.
92 ;; * Various code to print debugging messages, and similar debugging code,
93 ;; is compiled only when this feature is present.
95 ;; Note that the extra information recorded by the compiler at
96 ;; this higher level of OPTIMIZE DEBUG includes the source location
97 ;; forms. In order for the debugger to use this information, it has to
98 ;; re-READ the source file. In an ordinary installation of SBCL, this
99 ;; re-READing may not work very well, for either of two reasons:
100 ;; * The sources aren't present on the system in the same location that
101 ;; they were on the system where SBCL was compiled.
102 ;; * SBCL is using the standard readtable, without the added hackage
103 ;; which allows it to handle things like target features.
104 ;; If you want to be able to use the extra debugging information,
105 ;; therefore, be sure to keep the sources around, and run with the
106 ;; readtable configured so that the system sources can be read.
109 ;; Build SBCL with the old CMU CL low level debugger, "ldb". If
110 ;; are aren't messing with CMU CL at a very low level (e.g.
111 ;; trying to diagnose GC problems, or trying to debug assembly
112 ;; code for a port to a new CPU) you shouldn't need this.
115 ;; This isn't really a target Lisp feature at all, but controls
116 ;; whether the build process produces an after-xc.core file. This
117 ;; can be useful for shortening the edit/compile/debug cycle when
118 ;; you modify SBCL's own source code, as in slam.sh. Otherwise
119 ;; you don't need it.
122 ;; Enable extra debugging output in the assem.lisp assembler/scheduler
123 ;; code. (This is the feature which was called :DEBUG in the
124 ;; original CMU CL code.)
127 ;; Setting this makes SBCL more "fluid", i.e. more amenable to
128 ;; modification at runtime, by suppressing various INLINE declarations,
129 ;; compiler macro definitions, FREEZE-TYPE declarations; and by
130 ;; suppressing various burning-our-ships-behind-us actions after
131 ;; initialization is complete; and so forth. This tends to clobber the
132 ;; performance of the system, so unless you have some special need for
133 ;; this when hacking SBCL itself, you don't want this set.
136 ;; Enable code for collecting statistics on usage of various operations,
137 ;; useful for performance tuning of the SBCL system itself. This code
138 ;; is probably pretty stale (having not been tested since the fork from
139 ;; base CMU CL) but might nonetheless be a useful starting point for
140 ;; anyone who wants to collect such statistics in the future.
143 ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
145 ;; Some of the code which was #+high-security before the fork has now
146 ;; been either made unconditional, deleted, or rewritten into
147 ;; unrecognizability, but some remains. What remains is not maintained
148 ;; or tested in current SBCL, but I haven't gone out of my way to
152 ; :high-security-support
154 ;; multiprocessing support
156 ;; This is not maintained or tested in current SBCL. I haven't gone out
157 ;; of my way to break it, but since it's derived from an old version of
158 ;; CMU CL where multiprocessing was pretty shaky, it's likely to be very
160 ;; :MP enables multiprocessing
161 ;; :MP-I486 is used, only within the multiprocessing code, to control
162 ;; what seems to control processor-version-specific code. It's
163 ;; probably for 486 or later, i.e. could be set as long as
164 ;; you know you're not running on a 386, but it doesn't seem
165 ;; to be documented anywhere, so that's just a guess.
169 ;; This affects the definition of a lot of things in bignum.lisp. It
170 ;; doesn't seem to be documented anywhere what systems it might apply
171 ;; to. It doesn't seem to be needed for X86 systems anyway.
174 ;; This is probably true for some processor types, but not X86. It
175 ;; affects a lot of floating point code.
176 ; :negative-zero-is-not-zero
178 ;; This is set in classic CMU CL, and presumably there it means
179 ;; that the floating point arithmetic implementation
180 ;; conforms to IEEE's standard. Here it definitely means that the
181 ;; floating point arithmetic implementation conforms to IEEE's standard.
182 ;; I (WHN 19990702) haven't tried to verify
183 ;; that it does conform, but it should at least mostly conform (because
184 ;; the underlying x86 hardware tries).
187 ;; CMU CL had, and we inherited, code to support 80-bit LONG-FLOAT on the x86
188 ;; architecture. Nothing has been done to actively destroy the long float
189 ;; support, but it hasn't been thoroughly maintained, and needs at least
190 ;; some maintenance before it will work. (E.g. the LONG-FLOAT-only parts of
191 ;; genesis are still implemented in terms of unportable CMU CL functions
192 ;; which are not longer available at genesis time in SBCL.) A deeper
193 ;; problem is SBCL's bootstrap process implicitly assumes that the
194 ;; cross-compilation host will be able to make the same distinctions
195 ;; between floating point types that it does. This assumption is
196 ;; fundamentally sleazy, even though in practice it's unlikely to break down
197 ;; w.r.t. distinguishing SINGLE-FLOAT from DOUBLE-FLOAT; it's much more
198 ;; likely to break down w.r.t. distinguishing DOUBLE-FLOAT from LONG-FLOAT.
199 ;; Still it's likely to be quite doable to get LONG-FLOAT support working
200 ;; again, if anyone's sufficiently motivated.
204 ;; miscellaneous notes on other things which could have special significance
205 ;; in the *FEATURES* list
208 ;; notes on the :NIL and :IGNORE features:
210 ;; #+NIL is used to comment out forms. Occasionally #+IGNORE is used
211 ;; for this too. So don't use :NIL or :IGNORE as the names of features..
213 ;; notes on :SB-XC and :SB-XC-HOST features (which aren't controlled by this
214 ;; file, but are instead temporarily pushed onto *FEATURES* or
215 ;; *TARGET-FEATURES* during some phases of cross-compilation):
217 ;; :SB-XC-HOST stands for "cross-compilation host" and is in *FEATURES*
218 ;; during the first phase of cross-compilation bootstrapping, when the
219 ;; host Lisp is being used to compile the cross-compiler.
221 ;; :SB-XC stands for "cross compiler", and is in *FEATURES* during the second
222 ;; phase of cross-compilation bootstrapping, when the cross-compiler is
223 ;; being used to create the first target Lisp.
225 ;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
228 ;; This is a flag for whether we're in the assembler. It's
229 ;; temporarily pushed onto the *FEATURES* list in the setup for
230 ;; the ASSEMBLE-FILE function. It would be a bad idea
231 ;; to use it as a name for a permanent feature.
233 ;; notes on local features (which are set automatically by the
234 ;; configuration script, and should not be set here unless you
235 ;; really, really know what you're doing):
237 ;; machine architecture features:
239 ;; any Intel 386 or better, or compatibles like the AMD K6 or K7
241 ;; DEC/Compaq Alpha CPU
242 ;; (No other CPUs are supported by SBCL as of 0.6.12.15, but SPARC or
243 ;; PowerPC support could be ported from CMU CL if anyone is
244 ;; sufficiently motivated to do so, or if you're *really* motivated,
245 ;; you could write a port from scratch for a new CPU architecture.)
246 ;; (CMU CL also had a :pentium feature, which affected the definition
247 ;; of some floating point vops. It was present but not enabled or
248 ;; documented in the CMU CL code that SBCL is derived from, and is
249 ;; present but stale in SBCL as of 0.6.12.)
251 ;; properties derived from the machine architecture
252 ;; :control-stack-grows-downward-not-upward
253 ;; On the X86, the Lisp control stack grows downward. On the
254 ;; other supported CPU architectures as of sbcl-0.7.1.40, the
255 ;; system stack grows upward.
256 ;; Note that there are other stack-related differences between the
257 ;; X86 port and the other ports. E.g. on the X86, the Lisp control
258 ;; stack coincides with the C stack, meaning that on the X86 there's
259 ;; stuff on the control stack that the Lisp-level debugger doesn't
260 ;; understand very well. As of sbcl-0.7.1.40 things like that are
261 ;; just parameterized by #!+X86, but it'd probably be better to
262 ;; use new flags like :CONTROL-STACK-CONTAINS-C-STACK.
264 ;; operating system features:
265 ;; :linux = We're intended to run under some version of Linux.
266 ;; :bsd = We're intended to run under some version of BSD Unix. (This
267 ;; is not exclusive with the features which indicate which
268 ;; particular version of BSD we're intended to run under.)
269 ;; :freebsd = We're intended to run under FreeBSD.
270 ;; :openbsd = We're intended to run under FreeBSD.
271 ;; (No others are supported by SBCL as of 0.6.7, but :hpux or
272 ;; :solaris support could be ported from CMU CL if anyone is
273 ;; sufficiently motivated to do so, and it'd even be possible,
274 ;; though harder, to port the system to Microsoft Windows.)