X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcompiler%2Fgeneric%2Fobjdef.lisp;h=f945ad3674440fb429e7f365db388058ffba8519;hb=e049902f5e7c30501d2dbb7a41d058a0c717fc1f;hp=5156cad470b5dd0eb87e97aa25c2c676f5483661;hpb=e8b69b1dd5564a4237b1bdc1060820c3b820cde2;p=sbcl.git

diff --git a/src/compiler/generic/objdef.lisp b/src/compiler/generic/objdef.lisp
index 5156cad..f945ad3 100644
--- a/src/compiler/generic/objdef.lisp
+++ b/src/compiler/generic/objdef.lisp
@@ -10,6 +10,31 @@
 ;;;; files for more information.
 
 (in-package "SB!VM")
+
+;;;; KLUDGE: The primitive objects here may look like self-contained
+;;;; definitions, but in general they're not. In particular, if you
+;;;; try to add a slot to them, beware of the following:
+;;;;   * (mysterious crashes which occur after changing the length
+;;;;     of SIMPLE-FUN, just adding a new slot not even doing anything
+;;;;     with it, still dunno why)
+;;;;   * The GC scavenging code (and for all I know other GC code too)
+;;;;     is not automatically generated from these layouts, but instead
+;;;;     was hand-written to correspond to them. The offsets are
+;;;;     automatically propagated into the GC scavenging code, but the
+;;;;     existence of slots, and whether they should be scavenged, is
+;;;;     not automatically propagated. Thus e.g. if you add a
+;;;;     SIMPLE-FUN-DEBUG-INFO slot holding a tagged object which needs
+;;;;     to be GCed, you need to tweak scav_code_header() and
+;;;;     verify_space() in gencgc.c, and the corresponding code in gc.c.
+;;;;   * The src/runtime/print.c code (used by LDB) is implemented
+;;;;     using hand-written lists of slot names, which aren't automatically
+;;;;     generated from the code in this file.
+;;;;   * Various code (e.g. STATIC-FSET in genesis.lisp) is hard-wired
+;;;;     to know the name of the last slot of the object the code works
+;;;;     with, and implicitly to know that the last slot is special (being
+;;;;     the beginning of an arbitrary-length sequence of bytes following
+;;;;     the fixed-layout slots).
+;;;; -- WHN 2001-12-29
 
 ;;;; the primitive objects themselves
 
@@ -168,7 +193,8 @@
 	:ref-trans %simple-fun-name
 	:set-known (unsafe)
 	:set-trans (setf %simple-fun-name))
-  (arglist :ref-known (flushable)
+  (arglist :type list
+           :ref-known (flushable)
 	   :ref-trans %simple-fun-arglist
 	   :set-known (unsafe)
 	   :set-trans (setf %simple-fun-arglist))
@@ -284,15 +310,26 @@
 ;;;; symbols
 
 #!+x86
-(defknown symbol-hash (symbol) (integer 0 #.*target-most-positive-fixnum*)
+(defknown symbol-hash (symbol) (integer 0 #.sb!xc:most-positive-fixnum)
   (flushable movable))
 
 (define-primitive-object (symbol :lowtag other-pointer-lowtag
 				 :widetag symbol-header-widetag
 				 #!-x86 :alloc-trans #!-x86 make-symbol)
+
+  ;; Beware when changing this definition.  NIL-the-symbol is defined
+  ;; using this layout, and NIL-the-end-of-list-marker is the cons 
+  ;; ( NIL . NIL ), living in the first two slots of NIL-the-symbol
+  ;; (conses have no header).  Careful selection of lowtags ensures
+  ;; that the same pointer can be used for both purposes:
+  ;; OTHER-POINTER-LOWTAG is 7, LIST-POINTER-LOWTAG is 3, so if you
+  ;; subtract 3 from (sb-kernel:get-lisp-obj-address 'NIL) you get the
+  ;; first data slot, and if you subtract 7 you get a symbol header.
+
   (value :set-trans %set-symbol-value
-	 :init :unbound)
-  #!+x86 (hash)
+	 :init :unbound)		;also the CAR of NIL-as-end-of-list
+  (hash)				;the CDR of NIL-as-end-of-list
+
   (plist :ref-trans symbol-plist
 	 :set-trans %set-symbol-plist
 	 :init :null)