0.7.2.10:
[sbcl.git] / src / compiler / generic / genesis.lisp
index b803202..f1d2a01 100644 (file)
 ;;; 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*)
 \f
 ;;;; miscellaneous stuff to read and write the core memory
 
   "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
         (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))
                                                 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)
 (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*))
 
   ;; 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
          (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.
       (: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))
                 (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
                   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)