Custom Query (1030 matches)

I am using the trunk (1.6-dev-r14297M) on an Intel mac running 10.6.4.

After updating from SVN, I rebuild the IDE in two steps:

• Rebuild CCL with (rebuild-ccl ...)

• Build the IDE by running ccl -n and saying (require :cocoa-application).

The image dumped by the first of these steps never has ASDF in it (which is fine). The image dumped by the second of these steps *sometimes* has ASDF in it, which is at least annoying. Whether or not it contains ASDF depends on how much it needs to recompile, I think.

To replicate this: from the CCL root directory (whatever (translate-logical-pathname "ccl") gets), do this:

$ find cocoa-ide examples -name '*.dx64fsl' -exec rm {} \;

After this, the first time the IDE is build it will not include ASDF. The next time it will.

The problem is obviously related to how much needs to be compiled, but I've not been able to work out what exactly.

I've discovered a problem with LOGIOR/LOGXOR/LOGAND on the ARM platform when I tried to run quicklisp under CCL on my Nokia N900. The following code based on minichipz from quicklisp causes the compiler to fail due to incorrect number of arguments passed to a vinsn:

(defstruct crc32
  (crc #xffffffff :type (unsigned-byte 32)))

(defun produce-crc32 (state)
  (logxor #xffffffff (crc32-crc state)))

I've managed to fix this problem, but then ran into another problem:

Nokia-N900:/home/user# ./armcl
Welcome to Clozure Common Lisp Version 1.6-dev  (LinuxARM32)!
? (defun zzz (x y)
  (declare (type (unsigned-byte 32) x))
  (declare (type (unsigned-byte 32) y))
  (logand x y))
ZZZ
? (zzz #xffffffff #xaa)
0
? (disassemble 'zzz)
;;; (defun zzz (x y) (declare (type (unsigned-byte 32) x)) (declare (type (unsigned-byte 32) y)) (logand
  (cmp nargs (:$ 8))
  (uuo-error-wrong-nargs (:? ne))
  (mov imm0 (:$ 19))
  (stmdb (:! sp) (imm0 vsp fn lr))
  (mov fn temp2)
  (stmdb (:! vsp) (arg_z arg_y))

;;; (logand x y)
  (tst arg_z (:$ #x80000003))
  (mov imm1 (:lsr arg_z (:$ 2)))
  (beq L104)
  (and imm0 arg_z (:$ 3))
  (cmp imm0 (:$ 2))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
  (ldr imm1 (:@ arg_z (:$ -6)))
  (movw imm0 (:$ #x107))
  (cmp imm1 imm0)
  (bne L80)
  (ldr imm1 (:@ arg_z (:$ -2)))
  (tst imm1 (:$ #x80000000))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
  (b L104)
L80
  (add imm0 imm0 (:$ #x100))
  (cmp imm1 imm0)
  (ldreq imm0 (:@ arg_z (:$ 2)))
  (cmpeq imm0 (:$ 0))
  (ldreq imm1 (:@ arg_z (:$ -2)))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
L104
  (mov arg_z arg_y)
  (tst arg_z (:$ #x80000003))
  (mov imm0 (:lsr arg_z (:$ 2)))
  (beq L188)
  (and imm1 arg_z (:$ 3))
  (cmp imm1 (:$ 2))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
  (ldr imm0 (:@ arg_z (:$ -6)))
  (movw imm1 (:$ #x107))
  (cmp imm0 imm1)
  (bne L164)
  (ldr imm0 (:@ arg_z (:$ -2)))
  (tst imm0 (:$ #x80000000))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
  (b L188)
L164
  (add imm1 imm1 (:$ #x100))
  (cmp imm0 imm1)
  (ldreq imm1 (:@ arg_z (:$ 2)))
  (cmpeq imm1 (:$ 0))
  (ldreq imm0 (:@ arg_z (:$ -2)))
  (uuo-error-reg-not-xtype (:? ne) arg_z (:$ 20))
L188
  (and imm0 imm0 imm1)
  (bla .SPmakeu32)
  (ldmia (:! sp) (imm0 vsp fn pc))

;;; #<no source text>
NIL

Here we see that the second argument is unboxed into imm1 which is reused as a temporary register when unboxing the first argument. The problem is due to the fact that when functions like ARM2-TWO-TARGETED-REG-FORMS see one of their arguments as 'const' (see e.g. aconst there) they assume that processing these arguments may not affect any registers besides directly specified. Vinsns like UNBOX-U32 though that can be generated even for such 'const' arguments may use temp registers for which 'target' registers are reused and thus become corrupted. As a workaround I've forced all *const vars in arm2-*-(un)targeted-reg-form(s) to be NIL which does solve the problem but may cause some slowdowns. Perhaps a better solution is necessary.

If an attempt is made to encode a string to octets using an encoding that does not support some of the characters in the string, the result should be an error, but is in fact a bogus byte vector, e.g.:

? (encode-string-to-octets "(λ (μ) μ)" :EXTERNAL-format :ascii)
#(40 26 32 40 26 41 32 26 41)