0.pre7.41:

[sbcl.git] / src / code / bit-bash.lisp

diff --git a/src/code/bit-bash.lisp b/src/code/bit-bash.lisp
index 88c9db0..589968b 100644 (file)
--- a/src/code/bit-bash.lisp
+++ b/src/code/bit-bash.lisp
@@ -186,6 +186,12 @@
 #!-sb-fluid (declaim (inline do-unary-bit-bash))
 (defun do-unary-bit-bash (src src-offset dst dst-offset length
                              dst-ref-fn dst-set-fn src-ref-fn)
+  ;; FIXME: Declaring these bit indices to be of type OFFSET, then
+  ;; using the inline expansion in SPEED 3 SAFETY 0 functions, is not
+  ;; a good thing. At the very least, we should make sure that the
+  ;; type (overflow) checks get done. Better would be to avoid
+  ;; using bit indices, and to use 32-bit unsigneds instead, and/or
+  ;; to call out to things like memmove(3) for big moves.
   (declare (type offset src-offset dst-offset length)
           (type function dst-ref-fn dst-set-fn src-ref-fn))
   (multiple-value-bind (dst-word-offset dst-bit-offset)
@@ -499,11 +505,12 @@
   (declare (type (simple-array (unsigned-byte 8) 1) bv))
   (declare (type sap sap))
   (declare (type fixnum offset))
-  ;; FIXME: Actually it looks as though this, and most other calls
-  ;; to COPY-TO-SYSTEM-AREA, could be written more concisely with BYTE-BLT.
-  ;; Except that the DST-END-DST-START convention for the length is confusing.
-  ;; Perhaps I could rename BYTE-BLT to BYTE-BLIT and replace the
-  ;; DST-END argument with an N-BYTES argument?
+  ;; FIXME: Actually it looks as though this, and most other calls to
+  ;; COPY-TO-SYSTEM-AREA, could be written more concisely with
+  ;; %BYTE-BLT. Except that the DST-END-DST-START convention for the
+  ;; length is confusing. Perhaps I could rename %BYTE-BLT to
+  ;; %BYTE-BLIT (and correspondingly rename the corresponding VOP) and
+  ;; replace the DST-END argument with an N-BYTES argument?
   (copy-to-system-area bv
                       (* sb!vm:vector-data-offset sb!vm:word-bits)
                       sap