File: base-target-features.lisp-expr

package info (click to toggle)
sbcl 2%3A1.2.4-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 28,576 kB
  • ctags: 20,896
  • sloc: lisp: 375,698; ansic: 28,659; sh: 3,651; asm: 3,103; makefile: 317
file content (468 lines) | stat: -rw-r--r-- 21,115 bytes parent folder | download
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
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
;;;; -*- Lisp -*-

;;;; 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 recommended way to customize the features of a
;;;; local build of SBCL is not to edit this file, but instead to
;;;; tweak customize-target-features.lisp. (You must create this file
;;;; first; it is not in the SBCL distribution, and is in fact
;;;; explicitly excluded from the distribution in places like
;;;; .cvsignore.) If you define a function in
;;;; customize-target-features.lisp, it will be used to transform the
;;;; target features list after it's read and before it's used. E.g.,
;;;; you can use code like this:
;;;;    (lambda (list)
;;;;      (flet ((enable (x) (pushnew x list))
;;;;             (disable (x) (setf list (remove x list))))
;;;;        #+nil (enable :sb-show)
;;;;        (enable :sb-after-xc-core)
;;;;        #+nil (disable :sb-doc)
;;;;        list))
;;;; By thus editing a local file (one which is not in the source
;;;; distribution, and which is in .cvsignore) your customizations
;;;; will remain local even if you do things like "cvs update",
;;;; will not show up if you try to submit a patch with "cvs diff",
;;;; and might even stay out of the way if you use other non-CVS-based
;;;; methods to upgrade the files or store your configuration.

;;;; 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?
 ;; No. CLHS says ":x3j13 [...] A conforming implementation might or
 ;; might not contain such a feature." -- CSR, 2002-02-21

 ;; our dialect
 :sbcl

 ;; Douglas Thomas Crosher's conservative generational GC (the only one
 ;; we currently support for X86).
 ;; :gencgc used to be here; CSR moved it into
 ;; local-target-features.lisp-expr via make-config.sh, as alpha,
 ;; sparc and ppc ports don't currently support it. -- CSR, 2002-02-21

 ;;
 ;; 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

 ;; 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.
 ;; This test does not affect the target system (in much the same way
 ;; as :sb-after-xc-core, below).
 :sb-test

 ;; Make more debugging information available (for debugging SBCL
 ;; itself). 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

 ;; Build SBCL with the old CMU CL low level debugger, "ldb". In the
 ;; ideal world you would not need this unless you are messing with
 ;; SBCL at a very low level (e.g., trying to diagnose GC problems, or
 ;; trying to debug assembly code for a port to a new CPU). However,
 ;; experience shows that sooner or later everyone lose()'s, in which
 ;; case SB-LDB can at least provide an informative backtrace.
 :sb-ldb

 ;; This isn't really a target Lisp feature at all, but controls
 ;; whether the build process produces an after-xc.core file. This
 ;; can be useful for shortening the edit/compile/debug cycle when
 ;; you modify SBCL's own source code, as in slam.sh. Otherwise
 ;; you don't need it.
 ; :sb-after-xc-core

 ;; 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

 ;; Compile the C runtime with support for low-level debugging output
 ;; through FSHOW and FSHOW_SIGNAL.  If enabled, this feature allows
 ;; users to turn on such debugging output using environment variables at
 ;; run-time.
 ; :sb-qshow

 ;; 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

 ;; Enable code for detecting concurrent accesses to the same hash-table
 ;; in multiple threads. Note that this implementation is currently
 ;; (2007-09-11) somewhat too eager: even though in the current implementation
 ;; multiple readers are thread safe as long as there are no writers, this
 ;; code will also trap multiple readers.
 ; :sb-hash-table-debug

 ;; Enabled automatically by make-config.sh for platforms which implement
 ;; short vector SIMD intrinsics.
 ;;
 ; :sb-simd-pack

 ;; Enabled automatically by make-config.sh for platforms which implement
 ;; the %READ-CYCLE-COUNTER VOP. Can be disabled manually: affects TIME.
 ;;
 ;; FIXME: Should this be :SB-CYCLE-COUNTER instead? If so, then the same goes
 ;; for :COMPARE-AND-SWAP-VOPS as well, and a bunch of others. Perhaps
 ;; built-time convenience features like this should all live in eg. SB!INT
 ;; instead?
 ;;
 ; :cycle-counter

 ;; Enabled automatically for platforms which implement complex arithmetic
 ;; VOPs. Such platforms should implement real-complex, complex-real and
 ;; complex-complex addition and subtractions (for complex-single-float
 ;; and complex-double-float). They should also also implement complex-real
 ;; and real-complex multiplication, complex-real division, and
 ;; sb!vm::swap-complex, which swaps the real and imaginary parts.
 ;; Finally, they should implement conjugate and complex-real, real-complex
 ;; and complex-complex CL:= (complex-complex EQL would usually be a good
 ;; idea).
 ;;
 ; :complex-float-vops

 ;; Enabled automatically for platforms which implement VOPs for EQL
 ;; of single and double floats.
 ;;
 ; :float-eql-vops

 ;; Enabled automatically for platform that can implement inline constants.
 ;;
 ;; Such platform must implement 5 functions, in SB!VM:
 ;; * canonicalize-inline-constant: converts a constant descriptor (list) into
 ;;    a canonical description, to be used as a key in an EQUAL hash table
 ;;    and to guide the generation of the constant itself.
 ;; * inline-constant-value: given a canonical constant descriptor, computes
 ;;    two values:
 ;;     1. A label that will be used to emit the constant (usually a
 ;;         sb!assem:label)
 ;;     2. A value that will be returned to code generators referring to
 ;;         the constant (on x86oids, an EA object)
 ;; * sort-inline-constants: Receives a vector of unique constants;
 ;;    the car of each entry is the constant descriptor, and the cdr the
 ;;    corresponding label. Destructively returns a vector of constants
 ;;    sorted in emission order. It could actually perform arbitrary
 ;;    modifications to the vector, e.g. to fuse constants of different
 ;;    size.
 ;; * emit-constant-segment-header: receives the vector of sorted constants
 ;;    and a flag (true iff speed > space). Expected to emit padding
 ;;    of some sort between the ELSEWHERE segment and the constants, or some
 ;;    metadata.
 ;; * emit-inline-constant: receives a constant descriptor and its associated
 ;;    label. Emits the constant.
 ;;
 ;; Implementing this features lets VOP generators use sb!c:register-inline-constant
 ;; to get handles (as returned by sb!vm:inline-constant-value) from constant
 ;; descriptors.
 ;;
 ; :inline-constants

 ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
 ;;
 ;; Some of the code which was #+high-security before the fork has now
 ;; been either made unconditional, deleted, or rewritten into
 ;; unrecognizability, but some remains. What remains is not maintained
 ;; or tested in current SBCL, but I haven't gone out of my way to
 ;; break it, either.
 ;;
 ; :high-security
 ; :high-security-support

 ;; low-level thread primitives support
 ;;
 ;; As of SBCL 1.0.33.26, threads are part of the default build on
 ;; x86oid Linux. Other platforms that support them include
 ;; x86oid Darwin, FreeBSD, and Solaris.
 ; :sb-thread

 ;; futex support
 ;;
 ;; While on linux we are able to use futexes for our locking
 ;; primitive, on other platforms we don't have this luxury.
 ;;
 ; :sb-futex

 ;; On some operating systems the FS segment register (used for SBCL's
 ;; thread local storage) is not reliably preserved in signal
 ;; handlers, so we need to restore its value from the pthread thread
 ;; local storage.
 ; :restore-fs-segment-register-from-tls

 ;; On some x86oid operating systems (darwin) SIGTRAP is not reliably
 ;; delivered for the INT3 instruction, so we use the UD2 instruction
 ;; which generates SIGILL instead.
 ; :ud2-breakpoints

 ;; Support for detection of unportable code (when applied to the
 ;; COMMON-LISP package, or SBCL-internal pacakges) or bad-neighbourly
 ;; code (when applied to user-level packages), relating to material
 ;; alteration to packages or to bindings in symbols in packages.
 :sb-package-locks

 ;; Support for the entirety of the 21-bit character space defined by
 ;; the Unicode consortium, rather than the classical 8-bit ISO-8859-1
 ;; character set.
 :sb-unicode

 ;; Support for a full evaluator that can execute all the CL special
 ;; forms, as opposed to the traditional SBCL evaluator which called
 ;; COMPILE for everything complicated.
 :sb-eval

 ;; Record source location information for variables, classes, conditions,
 ;; packages, etc. Gives much better information on M-. in Slime, but
 ;; increases core size by about 100kB.
 :sb-source-locations

 ;; Record xref data for SBCL internals. This can be rather useful for
 ;; people who want to develop on SBCL itself because it'll make M-?
 ;; (slime-edit-uses) work which lists call/expansion/etc. sites.
 ;; It'll increase the core size by major 5-6mB, though.
 ; :sb-xref-for-internals

 ;; We support package local nicknames. No :sb-prefix here as we vainly
 ;; believe our API is worth copying to other implementations as well.
 ;; This doesn't affect the build at all, merely declares how things are.
 :package-local-nicknames

 ;; 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 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

 ;; 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

 ;; Some platforms don't use a 32-bit off_t by default, and thus can't
 ;; handle files larger than 2GB. This feature will control whether
 ;; we'll try to use platform-specific compilation options to enable a
 ;; 64-bit off_t. The intent is for this feature to be automatically
 ;; enabled by make-config.sh on platforms where it's needed and known
 ;; to work, you shouldn't be enabling it manually. You might however
 ;; want to disable it, if you need to pass file descriptors to
 ;; foreign code that uses a 32-bit off_t.
 ; :largefile

 ;; Enabled automatically on platforms that have VOPs to compute the
 ;; high half of a full word-by-word multiplication.  When disabled,
 ;; SB-KERNEL:%MULTIPLY-HIGH is implemented in terms of
 ;; SB-BIGNUM:%MULTIPLY.
 ; :multiply-high-vops

 ;; SBCL has optional support for zlib-based compressed core files.  Enable
 ;; this feature to compile it in.  Obviously, doing so adds a dependency
 ;; on zlib.
 ; :sb-core-compression

 ;; On certain thread-enabled platforms, synchronization between threads
 ;; for the purpose of stopping and starting the world around GC can be
 ;; performed using safepoints instead of signals.  Enable this feature
 ;; to compile with safepoints and to use them for GC.
 ;; (Replaces use of SIG_STOP_FOR_GC.)
 ; :sb-safepoint

 ;; When compiling with safepoints, the INTERRUPT-THREAD mechanism can
 ;; also use safepoints to roll the target thread to a point at which it
 ;; can be interrupted safely, instead of using a signal for this
 ;; purpose.  Enable this feature in addition to :SB-SAFEPOINT to enable
 ;; such behaviour.
 ;; (Replaces use of SIGPIPE, except to wake up syscalls.)
 ; :sb-thruption

 ;; When compiling with safepoints and thruptions, the TIMER facility
 ;; can replace its use of setitimer with a background thread.
 ;; (Replaces use of SIGALRM.)
 ; :sb-wtimer

 ;; This platform implements VOPs for %ash/right, variable-width shift right
 ; :ash-right-vops

 ;;
 ;; miscellaneous notes on other things which could have special significance
 ;; in the *FEATURES* list
 ;;

 ;; Any target feature which affects binary compatibility of fasl files
 ;; needs to be recorded in *FEATURES-POTENTIALLY-AFFECTING-FASL-FORMAT*
 ;; (elsewhere).

 ;; 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
 ;;   :x86-64
 ;;      any x86-64 CPU running in 64-bit mode
 ;;   :alpha
 ;;      DEC/Compaq Alpha CPU
 ;;   :sparc
 ;;      any Sun UltraSPARC (possibly also non-Ultras -- currently untested)
 ;;   :ppc
 ;;      any PowerPC CPU
 ;;   :hppa
 ;;      any PA-RISC CPU
 ;;   :mips
 ;;      any MIPS CPU (in little-endian mode with :little-endian)
 ;;   :arm
 ;;      an ARM CPU (details yet to be determined)
 ;;
 ;; (CMU CL also had a :pentium feature, which affected the definition
 ;; of some floating point vops. It was present but not enabled or
 ;; documented in the CMU CL code that SBCL is derived from, and has
 ;; now been moved to the backend-subfeatures mechanism.)
 ;;
 ;; properties derived from the machine architecture
 ;;   :control-stack-grows-downward-not-upward
 ;;     On the X86, the Lisp control stack grows downward. On the
 ;;     other supported CPU architectures as of sbcl-0.7.1.40, the
 ;;     system stack grows upward.
 ;;   Note that there are other stack-related differences between the
 ;;   X86 port and the other ports. E.g. on the X86, the Lisp control
 ;;   stack coincides with the C stack, meaning that on the X86 there's
 ;;   stuff on the control stack that the Lisp-level debugger doesn't
 ;;   understand very well. As of sbcl-0.7.1.40 things like that are
 ;;   just parameterized by #!+X86, but it'd probably be better to
 ;;   use new flags like :CONTROL-STACK-CONTAINS-C-STACK.
 ;;
 ;;   :stack-allocatable-closures
 ;;     The compiler can allocate dynamic-extent closures on stack.
 ;;
 ;;   :alien-callbacks
 ;;     Alien callbacks have been implemented for this platform.
 ;;
 ;;   :compare-and-swap-vops
 ;;     The backend implements compare-and-swap VOPs.
 ;;
 ;;   :memory-barrier-vops
 ;;     Memory barriers (for multi-threaded synchronization) have been
 ;;     implemented for this platform.
 ;;
 ;; operating system features:
 ;;   :unix       = We're intended to run under some Unix-like OS. (This is not
 ;;                 exclusive with the features which indicate which particular
 ;;                 Unix-like OS we're intended to run under.)
 ;;   :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 OpenBSD.
 ;;   :netbsd     = We're intended to run under NetBSD.
 ;;   :dragonfly  = We're intended to run under DragonFly BSD.
 ;;   :darwin     = We're intended to run under Darwin (including MacOS X).
 ;;   :sunos      = We're intended to run under Solaris user environment
 ;;                 with the SunOS kernel.
 ;;   :hpux       = We're intended to run under HP-UX 11.11 or later
 ;;   :osf1       = We're intended to run under Tru64 (aka Digital Unix
 ;;                 aka OSF/1).
 ;;   :win32      = We're intended to under some version of Microsoft Windows.
 ;; (No others are supported by SBCL as of 1.0.8, but :hpux or :irix
 ;; support could be ported from CMU CL if anyone is sufficiently
 ;; motivated to do so.)
 )