0.pre7.14.flaky4.5:
[sbcl.git] / base-target-features.lisp-expr
index 8ac06a0..5f22ccb 100644 (file)
@@ -3,9 +3,20 @@
 ;;;; 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.
+;;;; 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. 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))
+;;;; That way, because customize-target-features.lisp is in
+;;;; .cvsignore, your local changes will remain local even if you use
+;;;; "cvs diff" to submit patches to SBCL.
 
 ;;;; This software is part of the SBCL system. See the README file for
 ;;;; more information.
@@ -29,7 +40,7 @@
  :sbcl
 
  ;; Douglas Thomas Crosher's conservative generational GC (the only one
- ;; we currently support)
+ ;; we currently support for X86)
  :gencgc
 
  ;; We're running under a UNIX. This is sort of redundant, and it was also
  ;; you are a developer.
  :sb-test
 
- ;; Setting this makes more debugging information available.
- ;; If you aren't hacking or troubleshooting SBCL itself, you
- ;; probably don't want this set.
+ ;; :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
+
+ ;; 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:
  ;; readtable configured so that the system sources can be read.
  ; :sb-show
 
+ ;; Build SBCL with the old CMU CL low level debugger, "ldb". If 
+ ;; are aren't messing with CMU CL at a very low level (e.g. 
+ ;; trying to diagnose GC problems) you shouldn't need this.
+ ; :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 if
+ ;; you're messing around with low-level internals of the system,
+ ;; 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.)
  ; :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.
+ ;; 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.
+ ;; This is probably true for some processor types, but not X86. It
+ ;; affects a lot of floating point code.
  ; :negative-zero-is-not-zero
 
- ;; This is mentioned in cmu-user.tex, which says that it enables
- ;; the compiler to reason about integer arithmetic. It also seems to
- ;; control other fancy numeric reasoning, e.g. knowing the result type of
- ;; a remainder calculation given the type of its inputs.
- ;;
- ;; CROSS-FLOAT-INFINITY-KLUDGE: The :PROPAGATE-FLOAT-TYPE and 
- ;; :PROPAGATE-FUN-TYPE features are problematic when building 
- ;; the cross-compiler itself. Their implementation depends on 
- ;; floating point infinities, which might not be supported in the
- ;; cross-compilation host. In order to avoid this problem, while
- ;; still supporting these features in the target Lisp compiler,
- ;; we use the :WILL-PROPAGATE-FLOAT-TYPE feature when building
- ;; the cross-compiler, and munge it into :PROPAGATE-FLOAT-TYPE
- ;; only when building the target compiler; and similarly for
- ;; :WILL-PROPAGATE-FUN-TYPE. 
- ;:will-propagate-float-type ; (becomes :PROPAGATE-FLOAT-TYPE)
-
- ;; According to cmu-user.tex, this enables the compiler to infer result
- ;; types for mathematical functions like SQRT, EXPT, and LOG, allowing
- ;; it to e.g. eliminate the possibility that a complex result will be
- ;; generated. This applies only to the target compiler, not the 
- ;; cross-compiler: see CROSS-FLOAT-INFINITY-KLUDGE.
- ;:will-propagate-fun-type ; (becomes :PROPAGATE-FUN-TYPE)
-
- ;; It's unclear to me what this does (but it was enabled in the code that I
- ;; picked up from Peter Van Eynde). -- WHN 19990224
- :constrain-float-type
+ ;; 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
  ;; phase of cross-compilation bootstrapping, when the cross-compiler is
  ;; being used to create the first target Lisp.
 
- ;; notes on the :PROPAGATE-FLOAT-TYPE and :PROPAGATE-FUN-TYPE
- ;; features: See the comments on CROSS-FLOAT-INFINITY-KLUDGE.
-
  ;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
  ;; this file):
  ;;
  ;; 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.)
+ ;;   :x86
+ ;;      any Intel 386 or better, or compatibles like the AMD K6 or K7
+ ;;   :alpha
+ ;;      DEC/Compaq Alpha CPU
+ ;; (No other CPUs are supported by SBCL as of 0.6.12.15, but SPARC or
+ ;; PowerPC support could be ported from CMU CL if anyone is
+ ;; sufficiently motivated to do so, or if you're *really* motivated,
+ ;; you could write a port from scratch for a new CPU architecture.)
+ ;; (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 is
+ ;; present but stale in SBCL as of 0.6.12.)
  ;;
  ;; operating system features:
  ;;   :linux   = We're intended to run under some version of Linux.
  ;;   :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.)
+ ;; sufficiently motivated to do so, and it'd even be possible,
+ ;; though harder, to port the system to Microsoft Windows.)
  )