X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcompiler%2Fgeneric%2Fgenesis.lisp;h=f1d2a01dd51a40dc53afacb38adb068969a4cdc3;hb=2963d6858d147b23c33f38e051e61264b479c9fc;hp=b803202fb01538c183ed6763977602cb8036c12a;hpb=b05ccdd91520249de6b465e226d3708089e541dc;p=sbcl.git diff --git a/src/compiler/generic/genesis.lisp b/src/compiler/generic/genesis.lisp index b803202..f1d2a01 100644 --- a/src/compiler/generic/genesis.lisp +++ b/src/compiler/generic/genesis.lisp @@ -344,32 +344,6 @@ ;;; pathname), or NIL if we're not currently cold loading any object file (defvar *cold-load-filename* nil) (declaim (type (or string null) *cold-load-filename*)) - -;;; This is vestigial support for the CMU CL byte-swapping code. CMU -;;; CL code tested for whether it needed to swap bytes in GENESIS by -;;; comparing the byte order of *BACKEND* to the byte order of -;;; *NATIVE-BACKEND*, a concept which doesn't exist in SBCL. Instead, -;;; in SBCL byte order swapping would need to be explicitly requested -;;; with a &KEY argument to GENESIS. -;;; -;;; I'm not sure whether this is a problem or not, and I don't have a -;;; machine with different byte order to test to find out for sure. -;;; The version of the system which is fed to the cross-compiler is -;;; now written in a subset of Common Lisp which doesn't require -;;; dumping a lot of things in such a way that machine byte order -;;; matters. (Mostly this is a matter of not using any specialized -;;; array type unless there's portable, high-level code to dump it.) -;;; If it *is* a problem, and you're trying to resurrect this code, -;;; please test particularly carefully, since I haven't had a chance -;;; to test the byte-swapping code at all. -- WHN 19990816 -;;; -;;; When this variable is non-NIL, byte-swapping is enabled wherever -;;; classic GENESIS would have done it. I.e. the value of this variable -;;; is the logical complement of -;;; (EQ (SB!C:BACKEND-BYTE-ORDER SB!C:*NATIVE-BACKEND*) -;;; (SB!C:BACKEND-BYTE-ORDER SB!C:*BACKEND*)) -;;; from CMU CL. -(defvar *genesis-byte-order-swap-p*) ;;;; miscellaneous stuff to read and write the core memory @@ -379,26 +353,6 @@ "Push THING onto the given cold-load LIST." `(setq ,list (cold-cons ,thing ,list))) -(defun maybe-byte-swap (word) - (declare (type (unsigned-byte 32) word)) - (aver (= sb!vm:n-word-bits 32)) - (aver (= sb!vm:n-byte-bits 8)) - (if (not *genesis-byte-order-swap-p*) - word - (logior (ash (ldb (byte 8 0) word) 24) - (ash (ldb (byte 8 8) word) 16) - (ash (ldb (byte 8 16) word) 8) - (ldb (byte 8 24) word)))) - -(defun maybe-byte-swap-short (short) - (declare (type (unsigned-byte 16) short)) - (aver (= sb!vm:n-word-bits 32)) - (aver (= sb!vm:n-byte-bits 8)) - (if (not *genesis-byte-order-swap-p*) - short - (logior (ash (ldb (byte 8 0) short) 8) - (ldb (byte 8 8) short)))) - ;;; BYTE-VECTOR-REF-32 and friends. These are like SAP-REF-n, except ;;; that instead of a SAP we use a byte vector (macrolet ((make-byte-vector-ref-n @@ -449,11 +403,7 @@ (bytes (gspace-bytes gspace)) (byte-index (ash (+ index (descriptor-word-offset address)) sb!vm:word-shift)) - ;; KLUDGE: Do we really need to do byte swap here? It seems - ;; as though we shouldn't.. (This attempts to be a literal - ;; translation of CMU CL code, and I don't have a big-endian - ;; machine to test it.) -- WHN 19990817 - (value (maybe-byte-swap (byte-vector-ref-32 bytes byte-index)))) + (value (byte-vector-ref-32 bytes byte-index))) (make-random-descriptor value))) (declaim (ftype (function (descriptor) descriptor) read-memory)) @@ -493,15 +443,11 @@ sb!vm:lowtag-mask) (ash index sb!vm:word-shift)) value) - ;; Note: There's a MAYBE-BYTE-SWAP in here in CMU CL, which I - ;; think is unnecessary now that we're doing the write - ;; byte-by-byte at high level. (I can't test this, though..) -- - ;; WHN 19990817 (let* ((bytes (gspace-bytes (descriptor-intuit-gspace address))) (byte-index (ash (+ index (descriptor-word-offset address)) sb!vm:word-shift))) (setf (byte-vector-ref-32 bytes byte-index) - (maybe-byte-swap (descriptor-bits value)))))) + (descriptor-bits value))))) (declaim (ftype (function (descriptor descriptor)) write-memory)) (defun write-memory (address value) @@ -1008,8 +954,8 @@ (defvar *cold-package-symbols*) (declaim (type list *cold-package-symbols*)) -;;; a map from descriptors to symbols, so that we can back up. The key is the -;;; address in the target core. +;;; a map from descriptors to symbols, so that we can back up. The key +;;; is the address in the target core. (defvar *cold-symbols*) (declaim (type hash-table *cold-symbols*)) @@ -1035,7 +981,12 @@ ;; need is SB!KERNEL:%BYTE-BLT. (let ((package-name (package-name package))) (cond ((find package-name '("COMMON-LISP" "KEYWORD") :test #'string=) - ;; That's OK then. + ;; Cold interning things in these standard packages is OK. + ;; (Cold interning things in the other standard package, + ;; CL-USER, isn't OK. We just use CL-USER to expose symbols + ;; whose homes are in other packages. Thus, trying to cold + ;; intern a symbol whose home package is CL-USER probably + ;; means that a coding error has been made somewhere.) (values)) ((string= package-name "SB!" :end1 3 :end2 3) ;; That looks OK, too. (All the target-code packages @@ -1044,9 +995,10 @@ (t ;; looks bad: maybe COMMON-LISP-USER? maybe an extension ;; package in the xc host? something we can't think of - ;; a valid reason to dump, anyway... - (bug "internal error: PACKAGE-NAME=~S looks too much like a typo." - package-name)))) + ;; a valid reason to cold intern, anyway... + (error ; not #'BUG, because #'BUG isn't defined yet + "internal error: PACKAGE-NAME=~S looks too much like a typo." + package-name)))) (let (;; Information about each cold-interned symbol is stored ;; in COLD-INTERN-INFO. @@ -1612,11 +1564,7 @@ (:alpha (ecase kind (:jmp-hint - (assert (zerop (ldb (byte 2 0) value))) - #+nil ;; was commented out in cmucl source too. Don't know what - ;; it does -dan 2001.05.03 - (setf (sap-ref-16 sap 0) - (logior (sap-ref-16 sap 0) (ldb (byte 14 0) (ash value -2))))) + (assert (zerop (ldb (byte 2 0) value)))) (:bits-63-48 (let* ((value (if (logbitp 15 value) (+ value (ash 1 16)) value)) (value (if (logbitp 31 value) (+ value (ash 1 32)) value)) @@ -1643,6 +1591,20 @@ (ldb (byte 8 0) value) (byte-vector-ref-8 gspace-bytes (1+ gspace-byte-offset)) (ldb (byte 8 8) value))))) + (:ppc + (ecase kind + (:ba + (setf (byte-vector-ref-32 gspace-bytes gspace-byte-offset) + (dpb (ash value -2) (byte 24 2) + (byte-vector-ref-32 gspace-bytes gspace-byte-offset)))) + (:ha + (let* ((h (ldb (byte 16 16) value)) + (l (ldb (byte 16 0) value))) + (setf (byte-vector-ref-16 gspace-bytes (+ gspace-byte-offset 2)) + (if (logbitp 15 l) (ldb (byte 16 0) (1+ h)) h)))) + (:l + (setf (byte-vector-ref-16 gspace-bytes (+ gspace-byte-offset 2)) + (ldb (byte 16 0) value))))) (:sparc (ecase kind (:call @@ -2654,6 +2616,18 @@ i))))) (terpri) + ;; FIXME: The SPARC has a PSEUDO-ATOMIC-TRAP that differs between + ;; platforms. If we export this from the SB!VM package, it gets + ;; written out as #define trap_PseudoAtomic, which is confusing as + ;; the runtime treats trap_ as the prefix for illegal instruction + ;; type things. We therefore don't export it, but instead do + (when (boundp 'sb!vm::pseudo-atomic-trap) + (format t "#define PSEUDO_ATOMIC_TRAP ~D /* 0x~:*~X */~%" sb!vm::pseudo-atomic-trap) + (terpri)) + ;; possibly this is another candidate for a rename (to + ;; pseudo-atomic-trap-number or pseudo-atomic-magic-constant + ;; [possibly applicable to other platforms]) + ;; writing primitive object layouts (let ((structs (sort (copy-list sb!vm:*primitive-objects*) #'string< :key (lambda (obj) @@ -2923,16 +2897,6 @@ initially undefined function references:~2%") ;;; the executable which will load the core. ;;; MAP-FILE-NAME gets (?) a map file. (dunno about this -- WHN 19990815) ;;; -;;; other arguments: -;;; BYTE-ORDER-SWAP-P controls whether GENESIS tries to swap bytes -;;; in some places in the output. It's only appropriate when -;;; cross-compiling from a machine with one byte order to a -;;; machine with the opposite byte order, which is irrelevant in -;;; current (19990816) SBCL, since only the X86 architecture is -;;; supported. If you're trying to add support for more -;;; architectures, see the comments on DEFVAR -;;; *GENESIS-BYTE-ORDER-SWAP-P* for more information. -;;; ;;; FIXME: GENESIS doesn't belong in SB!VM. Perhaps in %KERNEL for now, ;;; perhaps eventually in SB-LD or SB-BOOT. (defun sb!vm:genesis (&key @@ -2940,8 +2904,7 @@ initially undefined function references:~2%") symbol-table-file-name core-file-name map-file-name - c-header-file-name - byte-order-swap-p) + c-header-file-name) (when (and core-file-name (not symbol-table-file-name)) @@ -2983,7 +2946,6 @@ initially undefined function references:~2%") (let* ((*foreign-symbol-placeholder-value* (if core-file-name nil 0)) (*load-time-value-counter* 0) - (*genesis-byte-order-swap-p* byte-order-swap-p) (*cold-fdefn-objects* (make-hash-table :test 'equal)) (*cold-symbols* (make-hash-table :test 'equal)) (*cold-package-symbols* nil)