0.7.13.34
[sbcl/lichteblau.git] / base-target-features.lisp-expr
blob2bef56042e4bf2b41840a0281e2cc45b46704820
1 ;;;; -*- Lisp -*-
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
7 ;;;;
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:
14 ;;;;    (lambda (list)
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)
20 ;;;;        list))
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.
30 ;;;;
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.
38  ;;
39  ;; features present in all builds
40  ;;
42  ;; our standard
43  :ansi-cl :common-lisp
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
48  ;; our dialect
49  :sbcl
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.
63  :unix
65  ;;
66  ;; features present in this particular build
67  ;;
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.
76  :sb-doc
78  ;; Do regression and other tests when building the system. You might
79  ;; or might not want this if you're not a developer, depending on how
80  ;; paranoid you are. You probably do want it if you are a developer.
81  ;; This test does not affect the target system (in much the same way
82  ;; as :sb-after-xc-core, below).
83  :sb-test
85  ;; Make more debugging information available (for debugging SBCL
86  ;; itself). If you aren't hacking or troubleshooting SBCL itself,
87  ;; you probably don't want this set.
88  ;;
89  ;; At least two varieties of debugging information are enabled by this
90  ;; option:
91  ;;   * SBCL is compiled with a higher level of OPTIMIZE DEBUG, so that
92  ;;     the debugger can tell more about the state of the system.
93  ;;   * Various code to print debugging messages, and similar debugging code,
94  ;;     is compiled only when this feature is present.
95  ;;
96  ;; Note that the extra information recorded by the compiler at
97  ;; this higher level of OPTIMIZE DEBUG includes the source location
98  ;; forms. In order for the debugger to use this information, it has to
99  ;; re-READ the source file. In an ordinary installation of SBCL, this
100  ;; re-READing may not work very well, for either of two reasons:
101  ;;   * The sources aren't present on the system in the same location that
102  ;;     they were on the system where SBCL was compiled.
103  ;;   * SBCL is using the standard readtable, without the added hackage
104  ;;     which allows it to handle things like target features.
105  ;; If you want to be able to use the extra debugging information,
106  ;; therefore, be sure to keep the sources around, and run with the
107  ;; readtable configured so that the system sources can be read.
108  ; :sb-show
110  ;; Build SBCL with the old CMU CL low level debugger, "ldb". If 
111  ;; are aren't messing with CMU CL at a very low level (e.g. 
112  ;; trying to diagnose GC problems, or trying to debug assembly
113  ;; code for a port to a new CPU) you shouldn't need this.
114  ; :sb-ldb
116  ;; This isn't really a target Lisp feature at all, but controls
117  ;; whether the build process produces an after-xc.core file. This
118  ;; can be useful for shortening the edit/compile/debug cycle when
119  ;; you modify SBCL's own source code, as in slam.sh. Otherwise
120  ;; you don't need it.
121  ; :sb-after-xc-core
123  ;; Enable extra debugging output in the assem.lisp assembler/scheduler
124  ;; code. (This is the feature which was called :DEBUG in the
125  ;; original CMU CL code.)
126  ; :sb-show-assem
128  ;; Setting this makes SBCL more "fluid", i.e. more amenable to
129  ;; modification at runtime, by suppressing various INLINE declarations,
130  ;; compiler macro definitions, FREEZE-TYPE declarations; and by
131  ;; suppressing various burning-our-ships-behind-us actions after
132  ;; initialization is complete; and so forth. This tends to clobber the
133  ;; performance of the system, so unless you have some special need for
134  ;; this when hacking SBCL itself, you don't want this set.
135  ; :sb-fluid
137  ;; Enable code for collecting statistics on usage of various operations,
138  ;; useful for performance tuning of the SBCL system itself. This code
139  ;; is probably pretty stale (having not been tested since the fork from
140  ;; base CMU CL) but might nonetheless be a useful starting point for
141  ;; anyone who wants to collect such statistics in the future.
142  ; :sb-dyncount
144  ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
145  ;;
146  ;; Some of the code which was #+high-security before the fork has now
147  ;; been either made unconditional, deleted, or rewritten into
148  ;; unrecognizability, but some remains. What remains is not maintained
149  ;; or tested in current SBCL, but I haven't gone out of my way to
150  ;; break it, either. 
151  ;;
152  ; :high-security
153  ; :high-security-support
155  ;; multiprocessing support
156  ;;
157  ;; This is not maintained or tested in current SBCL. I haven't gone out
158  ;; of my way to break it, but since it's derived from an old version of 
159  ;; CMU CL where multiprocessing was pretty shaky, it's likely to be very
160  ;; flaky now.
161  ;;   :MP enables multiprocessing
162  ;;   :MP-I486 is used, only within the multiprocessing code, to control
163  ;;            what seems to control processor-version-specific code. It's
164  ;;            probably for 486 or later, i.e. could be set as long as
165  ;;            you know you're not running on a 386, but it doesn't seem
166  ;;            to be documented anywhere, so that's just a guess.
167  ; :mp
168  ; :mp-i486
170  ;; This affects the definition of a lot of things in bignum.lisp. It
171  ;; doesn't seem to be documented anywhere what systems it might apply
172  ;; to. It doesn't seem to be needed for X86 systems anyway.
173  ; :32x16-divide
175  ;; This is probably true for some processor types, but not X86. It
176  ;; affects a lot of floating point code.
177  ; :negative-zero-is-not-zero
179  ;; This is set in classic CMU CL, and presumably there it means
180  ;; that the floating point arithmetic implementation
181  ;; conforms to IEEE's standard. Here it definitely means that the
182  ;; floating point arithmetic implementation conforms to IEEE's standard.
183  ;; I (WHN 19990702) haven't tried to verify
184  ;; that it does conform, but it should at least mostly conform (because
185  ;; the underlying x86 hardware tries).
186  :ieee-floating-point
188  ;; CMU CL had, and we inherited, code to support 80-bit LONG-FLOAT on the x86
189  ;; architecture. Nothing has been done to actively destroy the long float
190  ;; support, but it hasn't been thoroughly maintained, and needs at least
191  ;; some maintenance before it will work. (E.g. the LONG-FLOAT-only parts of
192  ;; genesis are still implemented in terms of unportable CMU CL functions
193  ;; which are not longer available at genesis time in SBCL.) A deeper
194  ;; problem is SBCL's bootstrap process implicitly assumes that the
195  ;; cross-compilation host will be able to make the same distinctions
196  ;; between floating point types that it does. This assumption is
197  ;; fundamentally sleazy, even though in practice it's unlikely to break down
198  ;; w.r.t. distinguishing SINGLE-FLOAT from DOUBLE-FLOAT; it's much more
199  ;; likely to break down w.r.t. distinguishing DOUBLE-FLOAT from LONG-FLOAT.
200  ;; Still it's likely to be quite doable to get LONG-FLOAT support working
201  ;; again, if anyone's sufficiently motivated.
202  ; :long-float
204  ;;
205  ;; miscellaneous notes on other things which could have special significance
206  ;; in the *FEATURES* list
207  ;;
209  ;; notes on the :NIL and :IGNORE features:
210  ;;
211  ;; #+NIL is used to comment out forms. Occasionally #+IGNORE is used
212  ;; for this too. So don't use :NIL or :IGNORE as the names of features..
214  ;; notes on :SB-XC and :SB-XC-HOST features (which aren't controlled by this
215  ;; file, but are instead temporarily pushed onto *FEATURES* or
216  ;; *TARGET-FEATURES* during some phases of cross-compilation):
217  ;;
218  ;; :SB-XC-HOST stands for "cross-compilation host" and is in *FEATURES*
219  ;; during the first phase of cross-compilation bootstrapping, when the
220  ;; host Lisp is being used to compile the cross-compiler.
221  ;;
222  ;; :SB-XC stands for "cross compiler", and is in *FEATURES* during the second
223  ;; phase of cross-compilation bootstrapping, when the cross-compiler is
224  ;; being used to create the first target Lisp.
226  ;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
227  ;; this file):
228  ;;
229  ;; This is a flag for whether we're in the assembler. It's
230  ;; temporarily pushed onto the *FEATURES* list in the setup for
231  ;; the ASSEMBLE-FILE function. It would be a bad idea
232  ;; to use it as a name for a permanent feature.
234  ;; notes on local features (which are set automatically by the
235  ;; configuration script, and should not be set here unless you
236  ;; really, really know what you're doing):
237  ;; 
238  ;; machine architecture features:
239  ;;   :x86
240  ;;      any Intel 386 or better, or compatibles like the AMD K6 or K7
241  ;;   :alpha
242  ;;      DEC/Compaq Alpha CPU
243  ;;   :sparc
244  ;;      any Sun UltraSPARC (possibly also non-Ultras -- currently untested)
245  ;;   :ppc
246  ;;      any PowerPC CPU
247  ;;   :hppa
248  ;;      any PA-RISC CPU
249  ;;   :mips
250  ;;      any MIPS CPU (in little-endian mode with :little-endian -- currently
251  ;;      untested)
252  ;;   
253  ;; (CMU CL also had a :pentium feature, which affected the definition
254  ;; of some floating point vops. It was present but not enabled or
255  ;; documented in the CMU CL code that SBCL is derived from, and has
256  ;; now been moved to the backend-subfeatures mechanism.)
257  ;;
258  ;; properties derived from the machine architecture
259  ;;   :control-stack-grows-downward-not-upward
260  ;;     On the X86, the Lisp control stack grows downward. On the
261  ;;     other supported CPU architectures as of sbcl-0.7.1.40, the
262  ;;     system stack grows upward. 
263  ;;   Note that there are other stack-related differences between the
264  ;;   X86 port and the other ports. E.g. on the X86, the Lisp control
265  ;;   stack coincides with the C stack, meaning that on the X86 there's
266  ;;   stuff on the control stack that the Lisp-level debugger doesn't
267  ;;   understand very well. As of sbcl-0.7.1.40 things like that are
268  ;;   just parameterized by #!+X86, but it'd probably be better to
269  ;;   use new flags like :CONTROL-STACK-CONTAINS-C-STACK.
270  ;;
271  ;; operating system features:
272  ;;   :linux   = We're intended to run under some version of Linux.
273  ;;   :bsd     = We're intended to run under some version of BSD Unix. (This
274  ;;              is not exclusive with the features which indicate which
275  ;;              particular version of BSD we're intended to run under.)
276  ;;   :freebsd = We're intended to run under FreeBSD.
277  ;;   :openbsd = We're intended to run under OpenBSD.
278  ;;   :sunos   = We're intended to run under Solaris user environment
279  ;;              with the SunOS kernel.
280  ;;   :osf1    = We're intended to run under Tru64 (aka Digital Unix
281  ;;              aka OSF/1).
282  ;; (No others are supported by SBCL as of 0.7.5, but :hpux or :irix
283  ;; support could be ported from CMU CL if anyone is sufficiently
284  ;; motivated to do so, and it'd even be possible, though harder, to
285  ;; port the system to Microsoft Windows or MacOS X.)