X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=src%2Fcold%2Fansify.lisp;h=25b957c2bf888cc78412e73df0232534f501b638;hb=771b864c8f32af7734bc0550aeaf1539fc4df194;hp=31cf9fbfe5feaca54847036066f401e8c9a48c72;hpb=c7468ce98233e22d968b8a740743b4bac9ea2c5a;p=sbcl.git

diff --git a/src/cold/ansify.lisp b/src/cold/ansify.lisp
index 31cf9fb..25b957c 100644
--- a/src/cold/ansify.lisp
+++ b/src/cold/ansify.lisp
@@ -1,4 +1,4 @@
-;;;; patches to hide some implementation idiosyncrasies in our
+;;;; patches to work around implementation idiosyncrasies in our
 ;;;; cross-compilation host
 
 ;;;; This software is part of the SBCL system. See the README file for
@@ -9,31 +9,36 @@
 ;;;; 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.
+
+;;;; CLISP issues
 
+;;; as explained on #lisp ca. October 2003:
+;;;   <Krystof> chandler: nope, I'm blaming another clisp bug
+;;;   <Krystof> [8]> least-positive-short-float
+;;;   <Krystof> 2.93874s-39
+;;;   <Krystof> [9]> (coerce * 'single-float)
+;;;   <Krystof> 0.0
+;;;   <chandler> aah
+;;;   <mwh> "oops"
+;;;   <Krystof> yep
+;;;   <mwh> tried that on clisp from fink:
+;;;   <mwh> [1]> least-positive-short-float
+;;;   <mwh> 2.93874s-39
+;;;   <mwh> [2]> (coerce * 'single-float)
+;;;   <mwh> *** - floating point underflow
+;;;   <Krystof> yeah
+;;;   <mwh> shall i not try to build sbcl with that?
+;;;   <Krystof> if you turn off underflow traps, then you get 0.0
+;;;   <mwh> well, that makes sense, i guess
+;;;   <Krystof> #+clisp
+;;;   <Krystof> (ext:without-package-lock ("SYSTEM")
+;;;   <Krystof>   (setf system::*inhibit-floating-point-underflow* t))
+;;;   <Krystof> (in src/cold/ansify.lisp)
 #+clisp
-(locally
-
-  (in-package "COMMON-LISP")
-
-  ;; no longer needed in CLISP 1999-01-08, hurrah!
-  #|
-  ;; ANSI specifies that package LISP defines the type BOOLEAN, and the CMU CL
-  ;; compiler uses it a lot. This should be trivial to patch in CLISP, except
-  ;; that CLISP defines FFI:BOOLEAN, which conflicts. Gads.. Here we try to fix
-  ;; it with some package hacking. (Please do not take this as an example of
-  ;; good package hacking, I just messed with it until it seemed to work well
-  ;; enough to bootstrap CMU CL, because I'm highly unmotivated to make elegant
-  ;; fixes for nonstandard behavior. -- WHN)
-  (shadow 'ffi:boolean "FFI")
-  (deftype cl::boolean () '(member t nil))
-  (export 'boolean "LISP")
-  |#
-
-  ;; I gave up on using CLISP-1999-01-08 as a cross-compilation host because of
-  ;; problems that I don't have workarounds for:
-  (error "can't use CLISP -- no MAKE-LOAD-FORM")
-  (error "can't use CLISP -- no (FUNCTION (SETF SYMBOL-FUNCTION))")
-  )
+(ext:without-package-lock ("SYSTEM")
+  (setf system::*inhibit-floating-point-underflow* t))
+
+;;;; CMU CL issues
 
 ;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
 ;;; particular, it refuses to compile :PRINT-OBJECT options to
@@ -63,6 +68,35 @@
   (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
   (pushnew :no-ansi-read-sequence *features*))
 
+;;; This is apparently quite old, according to 
+;;; <http://tunes.org/~nef/logs/lisp/03.10.22>:
+;;;   <dan`b> (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".
+;;;   <dan`b> the warning relates to a random vinary produced from cvs of
+;;;           around feb 2000, the corresponding sources to which I never found
+;;; (But it seems harmless to leave it here forever just in case.)
+#+(and cmu alpha)
+(unless (ignore-errors (read-from-string "1.0l0"))
+  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
+
+#+(and cmu sparc)
+(ext:set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero))
+
+;;;; OpenMCL issues
+
+;;; This issue in OpenMCL led to some SBCL bug reports ca. late 2003.
+#+openmcl 
+(unless (ignore-errors (funcall (constantly t) 1 2 3)) 
+  (error "please find a binary that understands CONSTANTLY to build from"))
+
+;;;; general non-ANSI-ness
+
+(in-package :sb-cold)
+
+(defmacro munging-cl-package (&body body)
+  #-clisp `(progn ,@body)
+  #+clisp `(ext:without-package-lock ("CL")
+	     ,@body))
+
 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
 ;;; to make them conform. (Of course, ANSI says that bashing symbols
 ;;; in the COMMON-LISP package like this is undefined, but then if the
@@ -79,13 +113,16 @@
 	     (declare (ignore value))
 	     (unless (gethash key standard-ht)
 	       (warn "removing non-ANSI export from package CL: ~S" key)
-	       (unexport (intern key cl) cl)))
+	       (munging-cl-package
+		(unexport (intern key cl) cl))))
 	   host-ht)
   (maphash (lambda (key value)
 	     (declare (ignore value))
 	     (unless (gethash key host-ht)
 	       (warn "adding required-by-ANSI export to package CL: ~S" key)
-	       (export (intern key cl) cl))
+	       (munging-cl-package 
+		(export (intern key cl) cl)))
+	     
 	     ;; FIXME: My righteous indignation below was misplaced. ANSI sez
 	     ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
 	     ;; COMMON-LISP things to have their home packages elsewhere.
@@ -121,8 +158,3 @@
 		       cl)
 		 (kernel:%set-symbol-package symbol cl))))
 	   standard-ht))
-
-#+(and cmu alpha)
-(unless (ignore-errors (read-from-string "1.0l0"))
-  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
-