;;; 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+ 17)
+(defconstant +fasl-file-version+ 21)
;;; 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
;;; interpreter, changed %DEFUN and DEFSTRUCT, changed the
;;; 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-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
;;; the conventional file extension for our fasl files
(declaim (type simple-string *fasl-file-type*))
(defvar *fasl-file-type* "fasl")
-
-;;; This is a sort of pun that we inherited from CMU CL. For ordinary,
-;;; non-byte-coded fasl files, the "implementation" is basically the
-;;; CPU. For byte-coded fasl files, the "implementation" is whether
-;;; the data are stored big-endianly or little-endianly.
-(defun backend-byte-fasl-file-implementation ()
- *backend-byte-order*)
\f
;;; information about below-Lisp-level linkage
;;;