From: Fred J. Kaudel
Subject: Franz-lisp from Sun User's Group bug fix
Date:
Message-ID: <465@sce.UUCP>
Hello, Franz-lisp version 38.92 as distributed from the Sun User's Group
distribution tape number 2 has a bug in its handling of fixnum-block and
flonum-block arrays, as was reported by John Powell in comp.lang.lisp in July.
Specifically,
(array xx flonum-block 12)
returns "error: IMPROPER USE OF SETF" in both compiled and interpreted code.
This problem is specific to the 68k and is corrected by making the following
changes to array.l: (old code segment first, then corrected one)
78,91c78,101
< (cond ((or (and (or (eq 'fixnum type)(eq 'fixnum-block type))
< (setq rtype 0))
< (and (or (eq 'flonum type)(eq 'flonum-block type))
< (setq rtype 0.0))
< (and (or (status feature 68k)
< (status feature for-68k))
< (progn (setq rtype nil) t)))
< (do ((i size))
< ((zerop i))
< ;; BZS - wrong wrong
< ;; this doesn't work for >1 dim arrays
< ;; (store (funcall tname (setq i (1- i))) rtype))))
< ;; one more time
< (set (arrayref tname (setq i (1- i))) rtype))))
---
> (cond ((or (and (eq 'fixnum type) (setq rtype 0))
> (and (eq 'flonum type) (setq rtype 0.0))
> (and (or (status feature 68k)
> (status feature for-68k))
> (progn ;return t, kludges for 68k:
> ;rtype set to nil for t and nil types
> ;size set to 0 for *-block types:FJK
> ; since can't set *-block stuff on suns now!
> ; they are normally already inited to 0
> (cond
> ((or (eq 'fixnum-block type)
> (eq 'flonum-block type))
> (setq size 0);cut out do below
> ;should do any custom init here!
> )
> (t (setq rtype nil))));nil it out
> t))
> (do ((i size))
> ((zerop i))
> ;; BZS - wrong wrong
> ;; this doesn't work for >1 dim arrays
> ;; (store (funcall tname (setq i (1- i))) rtype)
> ;; one more time
> (set (arrayref tname (setq i (1- i))) rtype))))
---end of changes---
Applying the above changes and remaking lisp cures the array problems
described above.
-has anyone found a fix for the zerop bug in compiled lisp code on the suns?
More specifically, (zerop 0) and (zerop 0.0) both evaluate to t on the vax,
but evaluate to t and nil, respectively, when compiled on the sun using
Liszt version 8.39a (comes with lisp on the tape). This problem is
quite irritating since it makes code non-portable.
-has anyone fixed the fixit debugger so that (debug |just before loop|) would
work as is indicated in the manual (i.e., print "just before loop" at the
start of the debug interaction)?
Fred
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
····@sce.carleton.ca (For Real mailers)
---------------------------------------------------------
(For mailers which do not yet understand domains)
UUCP: ················@{allegra,decvax,ihnp4}.UUCP
ARPA/CSNET: ·····················@relay.ubc.ca
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: Jeff Dalton
Subject: Re: Franz-lisp from Sun User's Group bug fix
Date:
Message-ID: <582@aiva.ed.ac.uk>
In article <···@sce.UUCP> ····@sce.UUCP (Fred J. Kaudel) writes:
>Hello, Franz-lisp version 38.92 as distributed from the Sun User's Group
>distribution tape number 2 [...]
>-has anyone found a fix for the zerop bug in compiled lisp code on the suns?
> More specifically, (zerop 0) and (zerop 0.0) both evaluate to t on the vax,
> but evaluate to t and nil, respectively, when compiled on the sun using
> Liszt version 8.39a (comes with lisp on the tape). This problem is
> quite irritating since it makes code non-portable.
Well, I've fixed it, and I know someone else has too because I've seen
two different fixes. My fix looks somewhat suspect, I know, but is
not actually worse than similar code elsewhere in Liszt.
The problem is in cm-zerop in liszt/func.l. The comment below will
make sense if you look at (1) the VAX code, (2) the current definition
of cm-zerop, and (3) the code for cm-=& in liszt/fixnum.l.
; [begin jwd] The trick has to be a bit different on the 68k than on the
; VAX because the NULL test doesn't work unless NIL is at address zero.
; However, expanding (zerop x) as (=& 0 x) won't work either, because
; =& will compile this as an address comparison and not all floating
; zeros have the same address (much less the address of fixed 0).
; Therefore, we have to do some explicit dereferencing, just as =&
; does in the general case. Then (zerop x) expands, modulo bignums,
; to (eq (cdr 0) (cdr x)).
#+for-68k
(defun cm-zerop nil
(cond ((atom (cadr v-form))
`(and (eq (cdr 0) (cdr ,(cadr v-form)))
(not (bigp ,(cadr v-form)))))
(t (let ((gnsy (gensym)))
`((lambda (,gnsy)
(and (eq (cdr 0) (cdr ,gnsy))
(not (bigp ,gnsy))))
,(cadr v-form))))))
; [end jwd]
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton