Custom Query (1030 matches)

Welcome to Clozure Common Lisp Version 1.9-dev-r15475M-trunk  (LinuxARM32)!

SIP-HASH> (defun barbar (x) (declare (type (unsigned-byte 64) x)) (+ x 1))
BARBAR
SIP-HASH> (typep 1084818905618843912 '(unsigned-byte 64))
T
SIP-HASH> (barbar 1084818905618843912)
; Evaluation aborted on #<TYPE-ERROR #x54D5B08E>.

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.

When a SIGFPE (or equivalent) is received, we need to try harder to determine the operation/operands to fully initialize the resulting ARITHMETIC-ERROR condition.

On x86, CCL::DECODE-ARITHMETIC-ERROR doesn't try very hard. On ARM, nothing tries at all (though we don't actually get a SIGFPE.)

The PPC ports disassembled the instruction that caused the exception; the other ports need to do the same thing.