[Axiom-developer] [#17 algebra BOOTSTRAP fixed point] (new)

[anonymous]

William, Ralf, Tim;

Keep in mind here that what Steve and I are talking about are
changes in the lisp coding generated by the )compile command
for the *same* spad code between the initial build of Axiom and
a repeat build of the same algebra spad code.

When you run something like:

> (21) -> for i in 10^32 .. 10^32+5 repeat print i

if this loop called PRIMELT (or some other code affected by
the boostrap) then the first version of the lisp code is being
run because you are using only the initial build of Axiom. But
if you recompile PRIMELT and then run your test again, then the
second version of the lisp code is being run.

The fact that the compiled lisp code (which is compiled by
GCL to an object file) is not consistent from the first compile
to the next is the reason why we are concerned about this. We
want to know the reason why this happens.

One reasonable theory is that some algebra code, say A contains
some implicit dependencies on other algebra code B and that
when the code for B changes it causes changes in the code
generated for A. In other words A has to be recompiled because
B changed. This is not too much of a problem in general provided
that we either rebuild all of the algebra each time for any
change or if we have a complete set of dependencies which shows
what depends on what. But the fact that these dependencies form
loops means that some spad code files have to be singled out
as "bootstrap" files. For these one must supply initial lisp
code in order to get the initial `.o' files so that the rest
of the algebra files can be compiled. In the current Axiom
build the bootstrap lisp files are subtly different than the
lisp actually generated by the compiler for the corresponding
spad file. It would appear that the initial differences in
the bootstrap lisp files can be passed on to other files that
depend on them. In the current build, the algebra files must
be compiled twice before no further changes in the generated
lisp code occurs.

>PRIMELT 
> 
> The differences in the generated lisp are w.r.t QSADD1, in compiler
> generated code implementing a for loop. The differences look like:
> 
>     - (LETT |i| (+ |i| 1)
>     + (LETT |i| (QSADD1 |i|)
> 
> In primitiveElement, we use a for loop on `i in 10..'. i is passed to
> symmetricRemainder, defined in IntegerNumberSystem with signature:
> 

> -----Original Message-----
> From: William Sit address@hidden">mailto:address@hidden
> Sent: Monday, January 17, 2005 12:29 PM
> To: Ralf Hemmecke; address@hidden; address@hidden
> Subject: Re: [Axiom-developer] RE: algebra Makefiles
> withexplicitdependencies, bootstrap, fixed-points etc.
> 
> 
> (21) -> for i in 10^32 .. 10^32+5 repeat print i
>    100000000000000000000000000000000
>    100000000000000000000000000000001
>    100000000000000000000000000000002
>    100000000000000000000000000000003
>    100000000000000000000000000000004
>    100000000000000000000000000000005
>                                         Type: Void
> 
> William Sit wrote:
> > 
> > Let's not forget that 2^32 is over 4 billion.
> > 
> > William
> > --
> > 
> > Ralf Hemmecke wrote:
> > >
> > > This sounds like forbidding
> > >
> > > for i in 10^32 .. repeat ....
> > >
> > > or do I misunderstand something?
> > >
> > > Ralf
> > >
> > > 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.
> > > >
> 
> -- 
> William Sit
--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden