From: Christophe R. <cs...@ca...> - 2003-02-03 10:49:23
|
Christophe Rhodes <cs...@ca...> writes: > * it's still buggy. It doesn't report the error of accessing an array > of this type well to the user; instead, the debugger gets confused > while trying to print the condition; Buggy isn't the half of it. Quite apart from the fact that my previous patch didn't actually include any garbage collection information, so that the first GC would cause death of the environment, it's consistently miscompiling references to arrays. (defun foo (x) (sb-kernel:data-vector-ref (the (simple-array nil (*)) x) 0)) compiles alright, using the new VOP: ; 09101D33: MOV EAX, EDX ; no-arg-parsing entry point ; 35: AND AL, 7 ; 37: CMP AL, 7 ; 39: JNE L0 ; 3B: MOV AL, [EDX-7] ; 3E: CMP AL, 54 ; 40: JNE L0 ; 42: MOV EAX, 0 ; 47: BREAK 10 ; error trap ; 49: BYTE #X02 ; 4A: BYTE #X3D ; NIL-ARRAY-ACCESSED-ERROR ; 4B: BYTE #X8E ; EDX [ 33-40 is type-checking stuff, to verify that X actually is a SIMPLE-ARRAY-NIL; 42 moves the 0 index, and 47 onwards is the (unconditional) error that the aray access has compiled to ]. (defun foo (x) (sb-kernel:hairy-data-vector-ref (the (simple-array nil (*)) x) 0)) doesn't compile alright at all; it compiles to ; 090E1C13: NOP ; no-arg-parsing entry point ; 4: NOP ; 5: NOP ; 6: NOP ; 7: NOP ; 8: BREAK 10 ; error trap ; A: BYTE #X02 ; B: BYTE #X17 ; INVALID-ARG-COUNT-ERROR ; C: BYTE #X4D ; ECX I wonder if the problem is that there's an assumption that DATA-VECTOR-REF should never signal an error, or something, or the fact that it's going to derive that the return type is NIL (from EXTRACT-UPGRADED-ELEMENT-TYPE, or something). Hmm. Tricky. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Alexey D. <ade...@co...> - 2003-02-03 13:07:06
|
Christophe Rhodes <cs...@ca...> writes: > I wonder if the problem is that there's an assumption that > DATA-VECTOR-REF should never signal an error, or something, or the > fact that it's going to derive that the return type is NIL (from > EXTRACT-UPGRADED-ELEMENT-TYPE, or something). Functions reliably signalling errors should not be flushable. -- Regards, Alexey Dejneka |