X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=base-target-features.lisp-expr;h=b264b00463a5ad68e387351cc7a26a2ed3602b26;hb=b767eae48831153473226b985511c8f7a3ef98c5;hp=da348e5ccaf01b45f8cfc734e23957eaf08d9701;hpb=4a0ab5193096ca70dbbf43bb21418544f6d018b7;p=sbcl.git

diff --git a/base-target-features.lisp-expr b/base-target-features.lisp-expr
index da348e5..b264b00 100644
--- a/base-target-features.lisp-expr
+++ b/base-target-features.lisp-expr
@@ -5,8 +5,10 @@
 ;;;;
 ;;;; 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:
+;;;; tweak customize-target-features.lisp. 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))))
@@ -14,9 +16,12 @@
 ;;;;        (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.
+;;;; 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.
@@ -35,13 +40,17 @@
  ;; 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
+ ;; 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
 
  ;; 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
@@ -97,14 +106,15 @@
 
  ;; 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.
+ ;; trying to diagnose GC problems, or trying to debug assembly
+ ;; code for a port to a new CPU) 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.
+ ;; 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
@@ -128,10 +138,13 @@
  ;; anyone who wants to collect such statistics in the future.
  ; :sb-dyncount
 
- ;; Peter Van Eynde's increase-bulletproofness code
+ ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
  ;;
- ;; This is not maintained or tested in current SBCL, but I haven't
- ;; gone out of my way to remove or break it, either.
+ ;; 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
@@ -160,11 +173,6 @@
  ;; 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
@@ -174,10 +182,6 @@
  ;; 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