Custom Query (1030 matches)

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.

The attached code was extracted from cl-yacc which stopped working after commit 14305 (noticed it when trying to compile plexippus xpath). cl-yacc itself was tested for this problem only on ARM at the moment but the test code was also tried on x86_64 with similar results. The strict type checks for structure slots accessor break cl-yacc code because defstruct stores invalid type info for accessors for inherited slots if the inheriting structure uses the same :conc-name as the :include'd one. I guess cl-yacc may not be the only victim of the problem. Sorry, no patch this time as perhaps DEFSTRUCT stuff needs to be reworked and you know better how it should look after that.

Another related problem I noticed is that REMOVE-STRUCTURE-DEFS function invoked by DEFSTRUCT expansion removes inherited accessors too and seems like after that they don't always get redefined.

I've discovered multiple problems in ARM FFI while trying to run CFFI test suite.

1. There was a stray apostrophe in lib/ffi-linuxarm.lisp in arm-linux::generate-callback-bindings which caused problems with compilation. Fixed in the patch.

2. There was an error in s8->fixnum vinsn (val / result confusion, shift in the wrong direction). Attached charfail.lisp demonstrates the problem. Fixed in the patch.

3. There was a problem in mem-set-c-single-float / mem-set-single-float, val/src confusion that didn't seem to affect anything most of the time by pure accident plus bad index reference in mem-set-single-float. This is demonstrated by the second assert in attached floatfail.lisp. Fixed in the patch.

4. There is still a problem with mem-set-c-double-float, mem-set-double-float, get-double, get-double? and maybe other functions. Besides ignoring val and using src instead in mem-set(-c)-double-float, there's a more serious problem that I was unable to fix.

Namely, these functions use explicit register specifications for their temps that are used for strd/ldrd instructions that need consective registers. This seems to break register handling somehow, as the following can be observed at the end of disassembly of my-mem-set-double-float in attached floatfail.lisp:

  (ldrd imm0 (:@ arg_z (:$ 2)))
  (fmdrr d0 imm0 imm1)
  (add nargs imm0 imm1)
  (fmrrd imm0 imm1 d0)
  (strd imm0 (:@ nargs (:$ 0)))
  (ldmia (:! sp) (imm0 vsp fn pc))

Here we see imm0 and imm1 getting destroyed by get-double vinsn and later being used to construct address for the following strd as if nothing happened. This leads to memory fault.

The possible workaround is not using strd/ldrd at all but perhaps it's also possible to fix temp handling, but I don't have time to do it myself right now.