[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] RE: algebra Makefiles with explicit dependencies,

From: Stephen Wilson
Subject: Re: [Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.
Date: Mon, 17 Jan 2005 19:37:33 -0500
User-agent: Mutt/1.5.6+20040907i

Tim, Bill,

I am no longer baffled. The explanation for the generic arith
vs. fixnum arith is in macros.lisp. In the following code from
-REPEAT, X is bound to a form such as '((STEP |i| 3 1)):

                  (|member| (CADDAR X) '(2 1 0 (|One|) (|Zero|)))
                  (|member| (CADR (CDDAR X)) '(1 (|One|))))
             (SETQ X (CONS (CONS 'ISTEP (CDAR X)) (CDR X))) ))
                        ; A hack to increase the likelihood of small integers

So, one `rule' is, if you iterate with a sequence with lower bound
0,1, or 2, with an increment of 1, you get fixnum arith. Otherwise you
get generic arithmetic.

However, this is not a hard and fast rule, since the compiler can say
'(ISTEP |i| 5 23) [say] during code generation and force fixnum arith. 

This leads to a question. Tim, in interp/wi2.boot we have a
redefinition of compIterator (default implementation is in
iterator.boot). This new definition makes an attempt at deciding when
fixnum stepping code should be generated. Do you have an explanation
as to why is this not the default definition? The original version of
the code in iterator.boot is what gets called.

I'm wondering if it is possible that during the fixedPoint build if
some of the new definitions (particularly those in wi2.boot,
xruncomp.boot) are being autoloaded during compilation. The changes
which I have already noted in the generated lisp seem to support this
(fixnum arith vs. generic arith, inlining of trivial coercions,
etc). All the changes make sense if they are the result of calling one
of the `improved' functions which these files redefine. 


On Mon, Jan 17, 2005 at 01:39:45PM -0500, Stephen Wilson wrote:
> Tim, 
> I compleatly fine with the fixnum declaration. We just need to make
> sure it is a rule programmers can rely on. Consider:
> )abbrev package ITER Iter
> Iter(): E == I where
>   E == with
>     iter: () -> Void
>   I == add
>     iter(): Void == 
>       for i in 2.. repeat
>          print(i::OutputForm)
> The relavent lisp decalres we are using fixnums:
>       (LETT |i| (QSADD1 |i|) |ITER;iter;V;1|)
> Now compile the above with a lower bound of 3:
>       for i in 3.. repeat
>          print(i::OutputForm)
> We get generic arithmetic:
>       (LETT |i| (+ |i| 1) |ITER;iter;V;1|)
> Baffled,
> Steve
> On Mon, Jan 17, 2005 at 12:23:36PM -0500, root wrote:
> > Steve,
> > 
> > I don't know if there is an actual statement to the effect that
> > the upper bound on a loop would be a register-sized number (32
> > or 64 bits) but at 6Mhz it seemed impossible that one could 
> > run a loop of any consequence for greater than 2^32 or 2^64
> > iterations. If you wanted to do that you'd have to do the
> > looping using some other construct. In general it is safe to
> > assume that the upper bound of the register size cannot be
> > exceeded. There is a practical performance difference to
> > be gained by using (declare (fixnum  as the compiler can,
> > in the best case, assign a register to the loop variable.
> > 
> > t

reply via email to

[Prev in Thread] Current Thread [Next in Thread]