0.6.12.4:
[sbcl.git] / src / code / fop.lisp
index 9522737..f78317b 100644 (file)
@@ -2,9 +2,6 @@
 
 (in-package "SB!IMPL")
 
-(file-comment
-  "$Header$")
-
 ;;; Define NAME as a fasl operation, with op-code FOP-CODE. PUSHP
 ;;; describes what the body does to the fop stack:
 ;;;   :NOPE
 ;;; know both the 1-byte-arg and the 4-byte-arg fop names. -- WHN 19990902
 (defmacro define-cloned-fops ((name code &optional (pushp t))
                              (small-name small-code) &rest forms)
-  (check-type pushp (member nil t :nope))
+  (aver (member pushp '(nil t :nope)))
   `(progn
      (macrolet ((clone-arg () '(read-arg 4)))
        (define-fop (,name ,code ,pushp) ,@forms))
      (macrolet ((clone-arg () '(read-arg 1)))
        (define-fop (,small-name ,small-code ,pushp) ,@forms))))
 
-;;; a helper function for reading string values from FASL files: sort of like
-;;; READ-SEQUENCE specialized for files of (UNSIGNED-BYTE 8), with an automatic
-;;; conversion from (UNSIGNED-BYTE 8) into CHARACTER for each element read
+;;; a helper function for reading string values from FASL files: sort
+;;; of like READ-SEQUENCE specialized for files of (UNSIGNED-BYTE 8),
+;;; with an automatic conversion from (UNSIGNED-BYTE 8) into CHARACTER
+;;; for each element read
 (declaim (ftype (function (stream simple-string &optional index) (values)) read-string-as-bytes))
 (defun read-string-as-bytes (stream string &optional (length (length string)))
   (dotimes (i length)
 
 ;;; Setting this variable causes execution of a FOP-NOP4 to produce
 ;;; output to *DEBUG-IO*. This can be handy when trying to follow the
-;;; progress of FASLOAD.
+;;; progress of FASL loading.
 #!+sb-show
 (defvar *show-fop-nop4-p* nil)
 
-;;; CMU CL had a single no-op fop, FOP-NOP, with fop code 0. Since 0 occurs
-;;; disproportionately often in fasl files for other reasons, FOP-NOP is less
-;;; than ideal for writing human-readable patterns into fasl files for
-;;; debugging purposes. There's no shortage of unused fop codes, so we add this
-;;; second NOP, which reads 4 arbitrary bytes and discards them.
+;;; CMU CL had a single no-op fop, FOP-NOP, with fop code 0. Since 0
+;;; occurs disproportionately often in fasl files for other reasons,
+;;; FOP-NOP is less than ideal for writing human-readable patterns
+;;; into fasl files for debugging purposes. There's no shortage of
+;;; unused fop codes, so we add this second NOP, which reads 4
+;;; arbitrary bytes and discards them.
 (define-fop (fop-nop4 137 :nope)
   (let ((arg (read-arg 4)))
     (declare (ignorable arg))
 ;;;   (1) *LOAD-SYMBOL-BUFFER-SIZE* is redundant, should just be
 ;;;       (LENGTH *LOAD-SYMBOL-BUFFER*).
 ;;;   (2) *LOAD-SYMBOL-BUFFER* should not have a global value, but should
-;;;       be bound on entry to FASLOAD, and it should be renamed to
-;;;       *FASLOAD-SYMBOL-BUFFER*.
+;;;       be bound on entry to FASL loading, and it should be renamed to
+;;;       *FASL-SYMBOL-BUFFER*.
 
 (macrolet (;; FIXME: Should all this code really be duplicated inside
           ;; each fop? Perhaps it would be better for this shared
                                                 ,n-size
                                                 ,n-package)))))))))
 
-  ;; Note: CMU CL had FOP-SYMBOL-SAVE and FOP-SMALL-SYMBOL-SAVE, but since they
-  ;; made the behavior of the fasloader depend on the *PACKAGE* variable, not
-  ;; only were they a pain to support (because they required various hacks to
-  ;; handle *PACKAGE*-manipulation forms) they were basically broken by design,
-  ;; because ANSI gives the user so much flexibility in manipulating *PACKAGE*
-  ;; at load-time that no reasonable hacks could possibly make things work
-  ;; right. The ones used in CMU CL certainly didn't, as shown by e.g.
+  ;; Note: CMU CL had FOP-SYMBOL-SAVE and FOP-SMALL-SYMBOL-SAVE, but
+  ;; since they made the behavior of the fasloader depend on the
+  ;; *PACKAGE* variable, not only were they a pain to support (because
+  ;; they required various hacks to handle *PACKAGE*-manipulation
+  ;; forms) they were basically broken by design, because ANSI gives
+  ;; the user so much flexibility in manipulating *PACKAGE* at
+  ;; load-time that no reasonable hacks could possibly make things
+  ;; work right. The ones used in CMU CL certainly didn't, as shown by
+  ;; e.g.
   ;;   (IN-PACKAGE :CL-USER)
   ;;     (DEFVAR CL::*FOO* 'FOO-VALUE)
   ;;     (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
                             sb!vm:byte-bits))
       res)))
 
-;;; FOP-SIGNED-INT-VECTOR
-;;;
-;;; Same as FOP-INT-VECTOR, except this is for signed simple-arrays.
-;;; It appears that entry 50 and 51 are clear.
+;;; This is the same as FOP-INT-VECTOR, except this is for signed
+;;; SIMPLE-ARRAYs.
 (define-fop (fop-signed-int-vector 50)
   (prepare-for-fast-read-byte *fasl-file*
     (let* ((len (fast-read-u-integer 4))
     ;;     (load-fresh-line)
     ;;     (prin1 result)
     ;;     (terpri))
-    ;; Unfortunately, this dependence on the *LOAD-PRINT* global variable is
-    ;; non-ANSI, so for now we've just punted printing in fasload.
+    ;; Unfortunately, this dependence on the *LOAD-PRINT* global
+    ;; variable is non-ANSI, so for now we've just punted printing in
+    ;; fasl loading.
     result))
 
 (define-fop (fop-eval-for-effect 54 nil)
     (sb!vm:sanctify-for-execution component)
     component))
 
-;;; This a no-op except in cold load. (In ordinary warm load, everything
-;;; involved with function definition can be handled nicely by ordinary
-;;; toplevel code.)
+;;; This a no-op except in cold load. (In ordinary warm load,
+;;; everything involved with function definition can be handled nicely
+;;; by ordinary toplevel code.)
 (define-fop (fop-fset 74 nil)
   (pop-stack)
   (pop-stack))