>>>>> "dvl" == Didier Verna <[EMAIL PROTECTED]> writes:
dvl> Sure. But what I was wondering was that if I insert my own
dvl> declaration, the macroexpanded code ends up with two different ones
(CMU-CL's
dvl> one isn't removed) which looks weird. I was wondering if it's even
legal.
Could you send the macroexpansion you get for dotimes i? Or tell us
what version of cmucl you are using?
I now have a modified version of the dotimes macro that takes
certain declarations on the loop variable and applies the same
declarations to the dummy loop counter. So
(dotimes (i size)
(declare (fixnum i))
(stuff))
is expanded to
(DO ((#:CTR-2003 0 (1+ #:CTR-2003))
(#:G2004 SIZE))
((>= #:CTR-2003 #:G2004)
(LET ((I #:CTR-2003))
(DECLARE (FIXNUM I))
I
NIL))
(DECLARE (FIXNUM #:CTR-2003))
(LET ((I #:CTR-2003))
(DECLARE (FIXNUM I))
I
(TAGBODY (STUFF))))
This should help code generation.
dvl> Trying this:
dvl> (defun assign (array value)
dvl> (declare (type (simple-array fixnum (* *)) array))
dvl> (declare (type fixnum value))
dvl> (let ((size (the (integer 0 100) (array-dimension array 0))))
dvl> (dotimes (i size)
dvl> (dotimes (j size)
dvl> (setf (aref array i j) value)))))
dvl> leads to the same notes about I (and still no note about J).
While it's pretty obvious that if SIZE has a certain range, and I should
have a similar range, CMUCL is not smart enough to derive that.
Even with this new macro, I get notes about I but not about J. If you
declare I to be a fixnum, the notes go away, and the generated code
looks nice without calls to generic bignum arithmetic.
Perhaps the compiler is able to determine J is a fixnum because of the
aref operation. I'd have to dig deep into the compiler to figure out
what's happening here.
Ray
