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.)
)
|