-
Notifications
You must be signed in to change notification settings - Fork 0
/
base-target-features.lisp-expr
272 lines (244 loc) · 12.4 KB
/
base-target-features.lisp-expr
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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
;;;; tags which are set during the build process and which end up in
;;;; CL:*FEATURES* in the target SBCL, plus some comments about other
;;;; CL:*FEATURES* tags which have special meaning to SBCL or which
;;;; have a special conventional meaning
;;;;
;;;; Note that the preferred way to customize the features of a local
;;;; build of SBCL is not to edit this file, but to tweak
;;;; customize-target-features.lisp.
;;;; This software is part of the SBCL system. See the README file for
;;;; more information.
;;;;
;;;; This software is derived from the CMU CL system, which was
;;;; written at Carnegie Mellon University and released into the
;;;; public domain. The software is in the public domain and is
;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.
(
;;
;; features present in all builds
;;
;; our standard
:ansi-cl :common-lisp
;; FIXME: Isn't there a :x3jsomething feature which we should set too?
;; our dialect
:sbcl
;; Douglas Thomas Crosher's conservative generational GC (the only one
;; we currently support)
:gencgc
;; We're running under a UNIX. This is sort of redundant, and it was also
;; sort of redundant under CMU CL, which we inherited it from: neither SBCL
;; nor CMU CL supports anything but UNIX (and "technically not UNIX"es
;; such as *BSD and Linux). But someday, maybe we might, and in that case
;; we'd presumably remove this, so its presence conveys the information
;; that the system isn't one which follows such a change.
:unix
;;
;; features present in this particular build
;;
;; Setting this enables the compilation of documentation strings
;; from the system sources into the target Lisp executable.
;; Traditional Common Lisp folk will want this option set.
;; I (WHN) made it optional because I came to Common Lisp from
;; C++ through Scheme, so I'm accustomed to asking
;; Emacs about things that I'm curious about instead of asking
;; the executable I'm running.
:sb-doc
;; When this is set, EVAL is implemented as an "IR1 interpreter":
;; code is compiled into the compiler's first internal representation,
;; then the IR1 is interpreted. When this is not set, EVAL is implemented
;; as a little bit of hackery wrapped around a call to COMPILE, i.e.
;; the system becomes a "compiler-only implementation" of Common Lisp.
;; As of sbcl-0.6.7, the compiler-only implementation is prototype code,
;; and much less mature than the old IR1 interpreter. Thus, the safe
;; thing is to leave :SB-INTERPRETER set. However, the compiler-only
;; system is noticeably smaller, so you might want to omit
;; :SB-INTERPRETER if you have a small machine.
;;
;; Probably, the compiler-only implementation will become more
;; stable someday, and support for the IR1 interpreter will then be
;; dropped. This will make the system smaller and easier to maintain
;; not only because we no longer need to support the interpreter,
;; but because code elsewhere in the system (the dumper, the debugger,
;; etc.) no longer needs special cases for interpreted code.
:sb-interpreter
;; Do regression and other tests when building the system. You
;; might or might not want this if you're not a developer,
;; depending on how paranoid you are. You probably do want it if
;; you are a developer.
:sb-test
;; :SB-PROPAGATE-FLOAT-TYPE and :SB-PROPAGATE-FUN-TYPE enable
;; some numeric optimizer code in the target compiler. They
;; correspond to the :PROPAGATE-FLOAT-TYPE and :PROPAGATE-FUN-TYPE
;; features in the original CMU CL code, and while documentation
;; existed for those, it seemed a little inconsistent. Despite the
;; name, :SB-PROPAGATE-FLOAT-TYPE seems to control not only
;; floating point optimizations, but some integer optimizations as
;; well.
;;
;; CROSS-FLOAT-INFINITY-KLUDGE:
;; * Even when these target features are enabled, the optimizations
;; aren't enabled in the cross-compiler, because some of them
;; depend on floating point infinities, which aren't in general
;; supported on the cross-compilation host.
;; * This is supported by hacking the features out of the
;; *SHEBANG-FEATURES* list while we're building the cross-compiler.
;; This is ugly and confusing and weird, but all the alternatives
;; that I could think of seem messy and error-prone. That doesn't
;; mean there's not a better way, though. Suggestions are welcome;
;; or if you'd like to submit patches to make this code work
;; without requiring floating point infinities, so that the entire
;; problem goes away, that might be even better! -- WHN 2001-03-22
:sb-propagate-float-type
:sb-propagate-fun-type
;; Setting this makes more debugging information available.
;; If you aren't hacking or troubleshooting SBCL itself, you
;; probably don't want this set.
;;
;; At least two varieties of debugging information are enabled by this
;; option:
;; * SBCL is compiled with a higher level of OPTIMIZE DEBUG, so that
;; the debugger can tell more about the state of the system.
;; * Various code to print debugging messages, and similar debugging code,
;; is compiled only when this feature is present.
;;
;; Note that the extra information recorded by the compiler at
;; this higher level of OPTIMIZE DEBUG includes the source location
;; forms. In order for the debugger to use this information, it has to
;; re-READ the source file. In an ordinary installation of SBCL, this
;; re-READing may not work very well, for either of two reasons:
;; * The sources aren't present on the system in the same location that
;; they were on the system where SBCL was compiled.
;; * SBCL is using the standard readtable, without the added hackage
;; which allows it to handle things like target features.
;; If you want to be able to use the extra debugging information,
;; therefore, be sure to keep the sources around, and run with the
;; readtable configured so that the system sources can be read.
; :sb-show
;; Enable extra debugging output in the assem.lisp assembler/scheduler
;; code. (This is the feature which was called :DEBUG in the
;; original CMU CL code.)
; :sb-show-assem
;; Setting this makes SBCL more "fluid", i.e. more amenable to
;; modification at runtime, by suppressing various INLINE declarations,
;; compiler macro definitions, FREEZE-TYPE declarations; and by
;; suppressing various burning-our-ships-behind-us actions after
;; initialization is complete; and so forth. This tends to clobber the
;; performance of the system, so unless you have some special need for
;; this when hacking SBCL itself, you don't want this set.
; :sb-fluid
;; Enable code for collecting statistics on usage of various operations,
;; useful for performance tuning of the SBCL system itself. This code
;; is probably pretty stale (having not been tested since the fork from
;; base CMU CL) but might nonetheless be a useful starting point for
;; anyone who wants to collect such statistics in the future.
; :sb-dyncount
;; Peter Van Eynde's increase-bulletproofness code
;;
;; This is not maintained or tested in current SBCL, but I haven't
;; gone out of my way to remove or break it, either.
;;
; :high-security
; :high-security-support
;; multiprocessing support
;;
;; This is not maintained or tested in current SBCL. I haven't gone out
;; of my way to break it, but since it's derived from an old version of
;; CMU CL where multiprocessing was pretty shaky, it's likely to be very
;; flaky now.
;; :MP enables multiprocessing
;; :MP-I486 is used, only within the multiprocessing code, to control
;; what seems to control processor-version-specific code. It's
;; probably for 486 or later, i.e. could be set as long as
;; you know you're not running on a 386, but it doesn't seem
;; to be documented anywhere, so that's just a guess.
; :mp
; :mp-i486
;; This affects the definition of a lot of things in bignum.lisp. It
;; doesn't seem to be documented anywhere what systems it might apply
;; to. It doesn't seem to be needed for X86 systems anyway.
; :32x16-divide
;; This is probably true for some processor types, but not X86. It
;; affects a lot of floating point code.
; :negative-zero-is-not-zero
;; It's unclear to me what this does (but it was enabled in the code
;; that I picked up from Peter Van Eynde, called CONSTRAIN-FLOAT-TYPE
;; instead of SB-CONSTRAIN-FLOAT-TYPE). -- WHN 19990224
:sb-constrain-float-type
;; This is set in classic CMU CL, and presumably there it means
;; that the floating point arithmetic implementation
;; conforms to IEEE's standard. Here it definitely means that the
;; floating point arithmetic implementation conforms to IEEE's standard.
;; I (WHN 19990702) haven't tried to verify
;; that it does conform, but it should at least mostly conform (because
;; the underlying x86 hardware tries).
:ieee-floating-point
;; This seems to be the pre-GENCGC garbage collector for CMU CL, which was
;; AFAIK never supported for the X86.
; :gengc
;; CMU CL had, and we inherited, code to support 80-bit LONG-FLOAT on the x86
;; architecture. Nothing has been done to actively destroy the long float
;; support, but it hasn't been thoroughly maintained, and needs at least
;; some maintenance before it will work. (E.g. the LONG-FLOAT-only parts of
;; genesis are still implemented in terms of unportable CMU CL functions
;; which are not longer available at genesis time in SBCL.) A deeper
;; problem is SBCL's bootstrap process implicitly assumes that the
;; cross-compilation host will be able to make the same distinctions
;; between floating point types that it does. This assumption is
;; fundamentally sleazy, even though in practice it's unlikely to break down
;; w.r.t. distinguishing SINGLE-FLOAT from DOUBLE-FLOAT; it's much more
;; likely to break down w.r.t. distinguishing DOUBLE-FLOAT from LONG-FLOAT.
;; Still it's likely to be quite doable to get LONG-FLOAT support working
;; again, if anyone's sufficiently motivated.
; :long-float
;;
;; miscellaneous notes on other things which could have special significance
;; in the *FEATURES* list
;;
;; notes on the :NIL and :IGNORE features:
;;
;; #+NIL is used to comment out forms. Occasionally #+IGNORE is used
;; for this too. So don't use :NIL or :IGNORE as the names of features..
;; notes on :SB-XC and :SB-XC-HOST features (which aren't controlled by this
;; file, but are instead temporarily pushed onto *FEATURES* or
;; *TARGET-FEATURES* during some phases of cross-compilation):
;;
;; :SB-XC-HOST stands for "cross-compilation host" and is in *FEATURES*
;; during the first phase of cross-compilation bootstrapping, when the
;; host Lisp is being used to compile the cross-compiler.
;;
;; :SB-XC stands for "cross compiler", and is in *FEATURES* during the second
;; phase of cross-compilation bootstrapping, when the cross-compiler is
;; being used to create the first target Lisp.
;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
;; this file):
;;
;; This is a flag for whether we're in the assembler. It's
;; temporarily pushed onto the *FEATURES* list in the setup for
;; the ASSEMBLE-FILE function. It would be a bad idea
;; to use it as a name for a permanent feature.
;; notes on local features (which are set automatically by the
;; configuration script, and should not be set here unless you
;; really, really know what you're doing):
;;
;; machine architecture features:
;; :x86 ; any Intel 386 or better, or compatibles like the AMD K6 or K7
;; (No others are supported by SBCL as of 0.6.7, but :alpha or
;; :sparc support could be ported from CMU CL if anyone is
;; sufficiently motivated to do so.)
;; (CMU CL also had a :pentium feature, which affected the definition
;; of some floating point vops. It was present but not enabled in the
;; CMU CL code that SBCL is derived from, and is present but stale
;; in SBCL as of 0.6.7.)
;;
;; operating system features:
;; :linux = We're intended to run under some version of Linux.
;; :bsd = We're intended to run under some version of BSD Unix. (This
;; is not exclusive with the features which indicate which
;; particular version of BSD we're intended to run under.)
;; :freebsd = We're intended to run under FreeBSD.
;; :openbsd = We're intended to run under FreeBSD.
;; (No others are supported by SBCL as of 0.6.7, but :hpux or
;; :solaris support could be ported from CMU CL if anyone is
;; sufficiently motivated to do so.)
)