;;; the code for a character which terminates a fasl file header
(defconstant +fasl-header-string-stop-char-code+ 255)
-;;; This value should be incremented when the system changes in such
-;;; a way that it will no longer work reliably with old fasl files.
-(defconstant +fasl-file-version+ 18)
+;;; This value should be incremented when the system changes in such a
+;;; way that it will no longer work reliably with old fasl files. In
+;;; practice, I (WHN) fairly often neglect to increment it for CVS
+;;; versions which break binary compatibility. But it certainly should
+;;; be incremented for release versions which break binary
+;;; compatibility.
+(defconstant +fasl-file-version+ 24)
;;; 2 = sbcl-0.6.4 uses COMPILE-OR-LOAD-DEFGENERIC.
;;; 3 = sbcl-0.6.6 uses private symbol, not :EMPTY, for empty HASH-TABLE slot.
;;; 4 = sbcl-0.6.7 uses HAIRY-DATA-VECTOR-REF and HAIRY-DATA-VECTOR-SET
;;; meaning of FOP-FSET, and changed the layouts of various
;;; internal compiler structures (e.g. DEFSTRUCT CLAMBDA)
;;; 18 = sbcl-0.pre7.39 swapped FUNCTION-POINTER-TYPE and
-;;; INSTANCE-POINTER-TYPE low-level type codes to help with
+;;; INSTANCE-POINTER-LOWTAG low-level type codes to help with
;;; the PPC port
+;;; (In 0.pre7.48, the low-level object layout of SYMBOL on the
+;;; non-X86 ports changed. I forgot to bump the fasl version number:
+;;; I only have an X86.. -- WHN)
+;;; 19 = sbcl-0.pre7.50 deleted byte-compiler-related low-level type codes
+;;; 20 = sbcl-0.pre7.51 modified names and layouts of
+;;; physical-environment-related structures in the compiler
+;;; 21 = sbcl-0.pre7.62 finally incremented the version after several
+;;; incompatible changes in earlier versions: many many symbols
+;;; renamed, changes in globaldb representation of constants
+;;; and inline functions, and change in the value of
+;;; INTERNAL-TIME-UNITS-PER-SECOND
+;;; 22 = about a zillion changes between sbcl-0.pre7.62 and
+;;; sbcl-0.pre7.133, during which time it seemed too much
+;;; trouble to increment the counter
+;;; 23 = sbcl-0.7.0.1 deleted no-longer-used EVAL-STACK stuff,
+;;; causing changes in *STATIC-SYMBOLS*.
+;;; 24 = sbcl-0.7.1.19 changed PCL service routines which might be
+;;; called from macroexpanded code
;;; the conventional file extension for our fasl files
(declaim (type simple-string *fasl-file-type*))
;;; Assembler routines are named by full Lisp symbols: they
;;; have packages and that sort of native Lisp stuff associated
;;; with them. We can compare them with EQ.
-;;; Foreign symbols are named by Lisp strings: the Lisp package
+;;; Foreign symbols are named by Lisp STRINGs: the Lisp package
;;; system doesn't extend out to symbols in languages like C.
;;; We want to use EQUAL to compare them.
;;; *STATIC-FOREIGN-SYMBOLS* are static as opposed to "dynamic" (not
-;;; as opposed to "extern"). The table contains symbols known at
+;;; as opposed to C's "extern"). The table contains symbols known at
;;; the time that the program was built, but not symbols defined
;;; in object files which have been loaded dynamically since then.
(declaim (type hash-table *assembler-routines* *static-foreign-symbols*))
\f
;;;; the FOP database
-(declaim (simple-vector *fop-names* *fop-functions*))
+(declaim (simple-vector *fop-names* *fop-funs*))
;;; a vector indexed by a FaslOP that yields the FOP's name
(defvar *fop-names* (make-array 256 :initial-element nil))
;;; a vector indexed by a FaslOP that yields a function of 0 arguments
;;; which will perform the operation
-(defvar *fop-functions*
+(defvar *fop-funs*
(make-array 256
:initial-element (lambda ()
(error "corrupt fasl file: losing FOP"))))
;;; the FASL file we're reading from
(defvar *fasl-input-stream*)
-(declaim (type lisp-stream *fasl-input-stream*))
+(declaim (type ansi-stream *fasl-input-stream*))
(defvar *load-print* nil
#!+sb-doc
projects / sbcl.git / blobdiff