;;;; types
(deftype stack-pointer ()
- `(integer 0 ,(1- most-positive-fixnum)))
+ `(integer 0 ,(1- sb!vm:*target-most-positive-fixnum*)))
;;; KLUDGE: bare numbers, no documentation, ick.. -- WHN 19990701
-(defconstant max-pc (1- (ash 1 24)))
+(eval-when (:compile-toplevel :load-toplevel :execute)
+ (defconstant max-pc (1- (ash 1 24))))
(deftype pc ()
`(integer 0 ,max-pc))
#+cmu :reader #+cmu #.(gensym) ; (to stop bogus non-STYLE WARNING)
)))
-;;; This warning refers to the flexibility in the ANSI spec with regard to
-;;; run-time distinctions between floating point types. (E.g. the
-;;; cross-compilation host might not even distinguish between SINGLE-FLOAT and
-;;; DOUBLE-FLOAT, so a DOUBLE-FLOAT number would test positive as
-;;; SINGLE-FLOAT.) If the target SBCL does make this distinction, then
-;;; information is lost. It's not too hard to contrive situations where this
-;;; would be a problem. In practice we don't tend to run into them because all
-;;; widely used Common Lisp environments do recognize the distinction between
-;;; SINGLE-FLOAT and DOUBLE-FLOAT, and we don't really need the other
-;;; distinctions (e.g. between SHORT-FLOAT and SINGLE-FLOAT), so we call
-;;; WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS to test at runtime whether
-;;; we need to worry about this at all, and not warn unless we do. If we *do*
-;;; have to worry about this at runtime, my (WHN 19990808) guess is that
-;;; the system will break in multiple places, so this is a real
-;;; WARNING, not just a STYLE-WARNING.
+;;; This warning refers to the flexibility in the ANSI spec with
+;;; regard to run-time distinctions between floating point types.
+;;; (E.g. the cross-compilation host might not even distinguish
+;;; between SINGLE-FLOAT and DOUBLE-FLOAT, so a DOUBLE-FLOAT number
+;;; would test positive as SINGLE-FLOAT.) If the target SBCL does make
+;;; this distinction, then information is lost. It's not too hard to
+;;; contrive situations where this would be a problem. In practice we
+;;; don't tend to run into them because all widely used Common Lisp
+;;; environments do recognize the distinction between SINGLE-FLOAT and
+;;; DOUBLE-FLOAT, and we don't really need the other distinctions
+;;; (e.g. between SHORT-FLOAT and SINGLE-FLOAT), so we call
+;;; WARN-POSSIBLE-CROSS-TYPE-FLOAT-INFO-LOSS to test at runtime
+;;; whether we need to worry about this at all, and not warn unless we
+;;; do. If we *do* have to worry about this at runtime, my (WHN
+;;; 19990808) guess is that the system will break in multiple places,
+;;; so this is a real WARNING, not just a STYLE-WARNING.
;;;
;;; KLUDGE: If we ever try to support LONG-FLOAT or SHORT-FLOAT, this
;;; situation will get a lot more complicated.
(warn "possible floating point information loss in ~S" call)))
(defun sb!xc:type-of (object)
- (labels (;; FIXME: This function is a no-op now that we no longer have a
- ;; distinct package T%CL to translate for-the-target-Lisp CL symbols
- ;; to, and should go away completely.
+ (labels (;; FIXME: This function is a no-op now that we no longer
+ ;; have a distinct package T%CL to translate
+ ;; for-the-target-Lisp CL symbols to, and should go away
+ ;; completely.
(translate (expr) expr))
(let ((raw-result (type-of object)))
(cond ((or (subtypep raw-result 'float)
(in-package "SB!IMPL")
-(defconstant in-buffer-length 512 "the size of a stream in-buffer")
+;;; the size of a stream in-buffer
+;;;
+;;; KLUDGE: The EVAL-WHEN wrapper isn't needed except when using CMU
+;;; CL as a cross-compilation host. cmucl-2.4.19 issues full WARNINGs
+;;; (not just STYLE-WARNINGs!) when processing this file, and when
+;;; processing other files which use LISP-STREAM. -- WHN 2000-12-13
+(eval-when (:compile-toplevel :load-toplevel :execute)
+ (defconstant in-buffer-length 512))
(deftype in-buffer-type ()
`(simple-array (unsigned-byte 8) (,in-buffer-length)))
\f
;;;; utilities
-(defconstant max-hash most-positive-fixnum)
+(eval-when (:compile-toplevel :load-toplevel :execute)
+ (defconstant max-hash most-positive-fixnum))
(deftype hash ()
`(integer 0 ,max-hash))
+;;; FIXME: Does this always make a nonnegative FIXNUM? If so, then
+;;; explain why. If not (or if the reason it always makes a
+;;; nonnegative FIXNUM is only the accident that pointers in supported
+;;; architectures happen to be in the lower half of the address
+;;; space), then fix it.
#!-sb-fluid (declaim (inline pointer-hash))
(defun pointer-hash (key)
(declare (values hash))
(in-package "SB!VM")
-(defconstant lowtag-bits 3
- #!+sb-doc
- "Number of bits at the low end of a pointer used for type information.")
-
-(defconstant lowtag-mask (1- (ash 1 lowtag-bits))
- #!+sb-doc
- "Mask to extract the low tag bits from a pointer.")
-
-(defconstant lowtag-limit (ash 1 lowtag-bits)
- #!+sb-doc
- "Exclusive upper bound on the value of the low tag bits from a pointer.")
-
-(defconstant type-bits 8
- #!+sb-doc
- "Number of bits used in the header word of a data block to store the type.")
+;;; the number of bits at the low end of a pointer used for type
+;;; information
+(defconstant lowtag-bits 3)
+;;; a mask to extract the low tag bits from a pointer
+(defconstant lowtag-mask (1- (ash 1 lowtag-bits)))
+;;; the exclusive upper bound on the value of the low tag bits from a
+;;; pointer
+(defconstant lowtag-limit (ash 1 lowtag-bits))
-(defconstant type-mask (1- (ash 1 type-bits))
- #!+sb-doc
- "Mask to extract the type from a header word.")
+;;; the number of bits used in the header word of a data block to store
+;;; the type
+(defconstant type-bits 8)
+;;; a mask to extract the type from a data block header word
+(defconstant type-mask (1- (ash 1 type-bits)))
-;;; FIXME: Couldn't/shouldn't these be DEFCONSTANT instead of DEFPARAMETER?
+;;; FIXME: Couldn't/shouldn't these be DEFCONSTANT instead of
+;;; DEFPARAMETER? (It might seem even more tempting to make them
+;;; SB!XC:MOST-POSITIVE-FIXNUM and SB!XC:MOST-NEGATIVE-FIXNUM,
+;;; but that's probably not a good idea, since then we'd need
+;;; to worry about the effect of UNCROSS in expressions like
+;;; (DEFTYPE INDX3 () `(INTEGER 3 ,SB!XC:MOST-POSITIVE-FIXNUM)).)
(defparameter *target-most-positive-fixnum* (1- (ash 1 29))
#!+sb-doc
- "most-positive-fixnum in the target architecture.")
+ "most-positive-fixnum in the target architecture")
(defparameter *target-most-negative-fixnum* (ash -1 29)
#!+sb-doc
- "most-negative-fixnum in the target architecture.")
+ "most-negative-fixnum in the target architecture")
;; conditional on #+CMU.)
#+(and sb-xc-host (or sbcl cmu))
(let (#+sbcl (sb-eval::*already-evaled-this* t)
- ;; KLUDGE: I thought this would be the right workaround
- ;; for CMUCL, but at least on cmucl-2.4.19 and
- ;; sbcl-0.6.9.5, it doesn't seem to work, at least
- ;; not for Martin Atzmueller and me. -- WHN 2000-12-12
- ;;#+cmu (common-lisp::*already-evaled-this* t)
- #+cmu (oops still do not know how to make this work))
+ #+cmu (common-lisp::*already-evaled-this* t))
(eval `(eval-when (:compile-toplevel :load-toplevel :execute)
,@body))))
;;; versions, and a string like "0.6.5.12" is used for versions which
;;; aren't released but correspond only to CVS tags or snapshots.
-"0.6.9.6"
+"0.6.9.7"
projects / sbcl.git / commitdiff