- ;; Note: CMU CL didn't set these in genesis, but instead arranged
- ;; for them to be set at cold init time. That resulted in slightly
- ;; kludgy-looking code, but there were at least two things to be
- ;; said for it:
- ;; 1. It put the hash values under the control of the target Lisp's
- ;; RANDOM function, so that CLOS behavior would be nearly
- ;; deterministic (instead of depending on the implementation of
- ;; RANDOM in the cross-compilation host, and the state of its
- ;; RNG when genesis begins).
- ;; 2. It automatically ensured that all hash values in the target Lisp
- ;; were part of the same sequence, so that we didn't have to worry
- ;; about the possibility of the first hash value set in genesis
- ;; being precisely equal to the some hash value set in cold init time
- ;; (because the target Lisp RNG has advanced to precisely the same
- ;; state that the host Lisp RNG was in earlier).
- ;; Point 1 should not be an issue in practice because of the way we do our
- ;; build procedure in two steps, so that the SBCL that we end up with has
- ;; been created by another SBCL (whose RNG is under our control).
- ;; Point 2 is more of an issue. If ANSI had provided a way to feed
- ;; entropy into an RNG, we would have no problem: we'd just feed
- ;; some specialized genesis-time-only pattern into the RNG state
- ;; before using it. However, they didn't, so we have a slight
- ;; problem. We address it by generating the hash values using a
- ;; different algorithm than we use in ordinary operation.
- (dotimes (i sb!kernel:layout-clos-hash-length)
- (let (;; The expression here is pretty arbitrary, we just want
- ;; to make sure that it's not something which is (1)
- ;; evenly distributed and (2) not foreordained to arise in
- ;; the target Lisp's (RANDOM-LAYOUT-CLOS-HASH) sequence
- ;; and show up as the CLOS-HASH value of some other
- ;; LAYOUT.
- ;;
- ;; FIXME: This expression here can generate a zero value,
- ;; and the CMU CL code goes out of its way to generate
- ;; strictly positive values (even though the field is
- ;; declared as an INDEX). Check that it's really OK to
- ;; have zero values in the CLOS-HASH slots.
- (hash-value (mod (logxor (logand (random-layout-clos-hash) 15253)
- (logandc2 (random-layout-clos-hash) 15253)
- 1)
- ;; (The MOD here is defensive programming
- ;; to make sure we never write an
- ;; out-of-range value even if some joker
- ;; sets LAYOUT-CLOS-HASH-MAX to other
- ;; than 2^n-1 at some time in the
- ;; future.)
- (1+ sb!kernel:layout-clos-hash-max))))
- (write-wordindexed result
- (+ i sb!vm:instance-slots-offset 1)
- (make-fixnum-descriptor hash-value))))
-