|
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@bogus.example.com">mailto:address@bogus.example.com
> Sent: Monday, January 17, 2005 12:29 PM
> To: Ralf Hemmecke; address@bogus.example.com; address@bogus.example.com
> 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
------------------------------------------------------------
fixnum optimization in new compiler --Mon, 17 Jan 2005 21:19:24 -0600
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
Integer substitutions --Mon, 17 Jan 2005 21:24:41 -0600
> ...
>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:
>
> primitiveElement(%,%).
>
> The call site takes the form primitiveElement(Integer, i), so we would
> expect that i should have type integer. Looking at the generated lisp
> for integer we see that QSADD1 is not on the property list for any
> function, but it is on the property list for SINT's `inc' function.
>
> Note the definition of QSADD1 in vmlisp.lisp:
>
> (defmacro qsadd1 (x) `(the fixnum (1+ (the fixnum ,x))))
>
> How does the compiler know on the second-iteration build that `i' will
> always be a fixnum? Though probably correct 99% of the time, the
> second-iteration code in this case is incorrect.
I don't understand the mechanism that makes this substitution but
in what sense is it incorrect. Can you give an example that might
apply the other 1% of the time? Do you mean because the magnitude
could exceed fixnum?
more questions --Tue, 18 Jan 2005 23:05:23 -0600
On Tuesday, January 18, 2005 7:28 AM Tim Daly wrote:
> ...
> Suppose VECTOR.spad used something from SINT.spad. When the
> VECTOR.lsp BOOTSTRAP file is compiled by depsys it contains
> (+ ... ...) and generates untyped and unoptimized code.
>
> Later when VECTOR.spad is compiled and SINT.o is available
> then the spad compiler will use the optimization information
> to generate (QSADD1 ... ...)
>
So you are saying that the type information derived from the
object files `A_i' files on which some code X depends can affect
the actual code generated library file X because the compiler
attempts optimizations based on this information. The bootstrap
lisp files do not currently have any type information, therefore
any library file that depends on a bootstrap file (quite a large
number) might not be optimized during the initial build. The
bootstrap files themselves are re-compiled from the spad sources
but of course by then it is too late for any other library file
that has already been compiled.
After the first iteration of fixedPoint all of the library files
have been re-compiled using object files that do have type
information, so now everything is optimized as expected.
Your argument is that the missing optimizations are not that
critical because the "mathematics" is still correct. It is just
that the generated code is less than optimal.
Right?
But on Monday, January 17, 2005 9:38 PM Stephen Wilson wrote
>
> On Mon, Jan 17, 2005 at 09:09:12PM -0500, Page, Bill wrote:
> > I wonder if both are necessary or is it only the change in
> > interpsys?
>
> The bootstrap code does influence the generated code for RECLOS
> and ROIRC (SINT's missing `one?' is showing up here).
>
> We know the bootstrap code is out of sync, so it would probably
> be a good idea to refresh it. Note that when I built a system
> with fresh bootstrap code, even though the generated lisp code
> was the same save for RECLOS and ROIRC, I did notice differences
> in how domains vectors were being instantiated at runtime (the
> vectors had the same layout, just that the runtime lookup of
> certain functions was proceeding differently).
Steve says that the code for `one?' was missing for SINT.lsp
Is this because it was coded as "onep$lisp" in the original
spad sources? I guess the actual symbols occurring in the
bootstrap lisp code would contain "hard coded" domain vector
`;offsets' as part of their names, corresponding to the old
coding of onep$lisp. But after SINT is recompiled from the
new spad code, the previous hardcoded offsets of any function
appearing after `one?' would become incorrect in any bootstrap
function that depends on SINT but was re-compiled before SINT.
Presumably this could lead to subtle (or not so subtle) run-
time errors. In other words, we have to be very careful of the
order in which we re-compile the bootstrap from the spad code.
If there are cyclic dependencies among the bootstrap files
(I think there are) then we are in trouble.
Of have I still got this wrong? My understanding of how
the compiler assigns and uses domain table offsets remains
very unclear to me.
yet another wrinkle --Tue, 18 Jan 2005 23:06:43 -0600
Tim,
I believe I understand the process by which optimized versions of the
bootstrap files are produced. However, I think that many of the
differences in the code we are seeing are not due to this process.
The fixed point build is causing the interpsys image to be
rebuilt. These images are different:
-rwxr-xr-x 1 steve steve 15858720 2005-01-06 05:29 interpsys1
-rwxr-xr-x 1 steve steve 16645152 2005-01-07 21:42 interpsys2
and they generate different code.
Consider the following simple package:
)abbrev package Foo Foo
Foo(): E == I where
E == with
bar: () -> Void
I == add
SI ==> SingleInteger
sint : SI := 2::SI
bar(): Integer ==
for j in 3.. repeat
print(i::OutputForm)
When compiled using both images, with the same $AXIOM environment (so
we know the images are seeing the same algebra) we get these basic
differences:
1) In iteration over the for loop, generic stepping code is replaced
with fixnum arith
2) Trivial coercions to SINT's coerce(Integer):% are being inlined.
In wi1.boot we see an improved version of compCoerce. Likewise in
wi2.boot we see an improved version of compIterator. The improved
version of compIterator makes explicit attempts to decide when fixnum
arith should be generated for stepping code (a higher-level attempt
then the quick hack found in the definition of -REPEAT in
macros.lisp, see a previous email).
My feeling is that somehow the new versions of these functions have
been loaded into the image in the second pass.
ONEP removed globally --Sat, 22 Jan 2005 02:53:21 -0600
The ONEP change is mine. ONEP is a CCL function, not a common lisp function.
The question that needs to be answered in order to implement ONEP in
common lisp is what is the representation of '1' in various domains?
Notice that in a domain 'foo = 1' is a spad way of asking the question.
This used to be the way it was done but NAG changed it in the CCL
implementation (probably for efficiency).
Since I couldn't decide what the exact semantics of ONEP are I took
the safest route.
additional information --Mon, 24 Jan 2005 21:14:01 -0600
===============================================================================================
I have built first-iteration and second-iteration axioms. An identical
fixedPoint.log was produced. I have been examining the domain
vectors, trying to find some clues.
I failed to spot a difference in two domains; BINFILE in files.spad,
and PRIMELT in primelt.spad. Indeed, for PRIMELT note that:
==============================================================================
(1) -> )lisp (setq |$DALYMODE| t)
Value = T
(1) -> (trace |eval|)
Value = (|eval|)
(1) -> PF ==> PrimeField 5
Type: Void
(2) -> VPF ==> Vector PF
Type: Void
(3) -> vec : VPF := [0, 1, 2, 3, 4]
(3) [0,1,2,3,4]
Type: Vector PrimeField 5
(4) -> inv(vec)$INBFF(PF)
1> (|eval| (|InnerNormalBasisFieldFunctions| (|PrimeField| 5)))
<1 (|eval| #<vector 08df6888>)
1> (|eval| #<vector 08df6888>)
<1 (|eval| #<vector 08df6888>)
1> (|eval| (SPADCALL (QUOTE #<vector 08db9428>)
(QUOTE (#<compiled-function |INBFF;inv;2V;1|> . #<vector 08df6888>))))
>> Error detected within library code:
index out of range
protected-symbol-warn called with (NIL)
==============================================================================
This happens in both builds. Im assuming at the moment the domain
vector is being indexed improperly (as opposed to the `vec'
argument). I'll look into this further. I have not tested BINFILE to
see if a similar problem is occurring there is well.
I have attached the notes I have made while examining the domain
vectors. They show what commands I used to get the domain vectors,
followed by a snip of the vectors where I noticed a difference.
I have yet to trace FORTRAN, fortran.spad.
Generally, the domain vectors below are changing w.r.t dependencies on
SingleInteger, or Integer. I feel that looking at the build w.r.t
these two domains would be a good direction for future investigations.
Sorry this message is so terse, but I am in a bit of rush at the
moment. I'll be able to reenter this issue later today.
Sincerely,
Steve
[ notes ]
files.spad, BINFILE identical
primelt.spad, PRIMELT identical
-------------------------------------------------------------------
--- First iteration, pattern.spad, PATTERN
(1) -> (pspadvec (|evalDomain| '(|Pattern| (|PrimeField| 5))))
...
30: (Union 56 (QUOTE failed))
31: (#<compiled-function PATTERN;isPlus;$U;10> . #<vector 09089f50>)
32: (SingleInteger)
33: (newGoGet #<vector 09089f50> 14 . coerce)
34: (#<compiled-function PATTERN;isTimes;$U;11> . #<vector 09089f50>)
35: (#<compiled-function PATTERN;isList;$U;12> . #<vector 09089f50>)
...
-------------------------------------------------------------------
--- Second iteration, pattern.spad, PATTERN
(1) -> (pspadvec (|evalDomain| '(|Pattern| (|PrimeField| 5))))
...
30: (Union 54 (QUOTE failed))
31: (#<compiled-function PATTERN;isPlus;$U;10> . #<vector 08fa201c>)
32: (#<compiled-function PATTERN;isTimes;$U;11> . #<vector 08fa201c>)
33: (#<compiled-function PATTERN;isList;$U;12> . #<vector 08fa201c>)
34: (Record (: val $) (: exponent 26))
35: (Union 34 (QUOTE failed))
...
-------------------------------------------------------------------
--- First iteration, d01agents.spad, D01AGNT
(1) -> (pspadvec (|evalDomain| '(|d01AgentsPackage|)))
...
59: (#<compiled-function LIMITPS;limit;FEEU;24> . #<vector 090337a8>)
60: (#<compiled-function ORDCOMP;finite?;$B;3> . #<vector 08f2d6e4>)
61: (SingleInteger)
62: (newGoGet #<vector 08ec2f88> 117 . coerce)
63: (#<compiled-function SEG;hi;$S;4> . #<vector 08e96c78>)
64: (newGoGet #<vector 08ec2f88> 127 . whatInfinity)
...
-------------------------------------------------------------------
--- Second iteration, d01agents.spad, D01AGNT
(1) -> (pspadvec (|evalDomain| '(|d01AgentsPackage|)))
...
59: (#<compiled-function LIMITPS;limit;FEEU;24> . #<vector 09008e00>)
60: (#<compiled-function ORDCOMP;finite?;$B;3> . #<vector 08efb94c>)
61: (#<compiled-function SEG;hi;$S;4> . #<vector 08ca0c40>)
62: (SingleInteger)
63: (newGoGet #<vector 08b85834> 122 . whatInfinity)
64: (#<compiled-function SEG;lo;$S;2> . #<vector 08ca0c40>)
-------------------------------------------------------------------
--- First Iteration, fortran.spad, FC
(1) -> (pspadvec (|evalDomain| '(|FortranCode|)) 1)
...
7: (Integer)
8: <vector> :
0: (SingleInteger)
1: (#<compiled-function lookupComplete> #<vector 08d60a80> #<vector
08d60b0c>)
...
...
9: (#<compiled-function SINT;coerce;I$;51> . #<vector 08d60a80>)
10: 25000
11: (#<compiled-function FC;setLabelValue;2Si;1> . #<vector 08d5ce38>)
12: (Polynomial 7)
13: (newGoGet #<vector 08d5ce38> 5 . One)
...
-------------------------------------------------------------------
--- Second Iteration, fortran.spad, FC
(1) -> (pspadvec (|evalDomain| '(|FortranCode|)))
...
7: 25000
8: (SingleInteger)
9: (#<compiled-function FC;setLabelValue;2Si;1> . #<vector 08ce9ab8>)
10: (Polynomial 13)
11: (newGoGet #<vector 08ce9ab8> 0 . One)
12: (String)
13: (Integer)
...
-------------------------------------------------------------------
--- First iteration, ffnb.spad, INBFF
(1) -> (pspadvec (|evalDomain| '(|InnerNormalBasisFieldFunctions| (|PrimeField|
5))) 1)
...
16: 1
17: (Integer)
18: <vector> :
0: (SingleInteger)
1: (#<compiled-function lookupComplete> #<vector 08d60a80> #<vector
08d60b0c>)
19: (#<compiled-function SINT;coerce;I$;51> . #<vector 08d60a80>)
20: (0 10 16 20 23 0 28 30 32 0 35)
21: (NIL (4 12 48 160 480 0) (8 72 432 0) (18 216 0) (32 480 0) NIL (72 0) (98
0) (128 0) NIL (200 0))
22: (Vector 6)
...
-------------------------------------------------------------------
--- Second iteration, ffnb.spad, INBFF
(1) -> (pspadvec (|evalDomain| '(|InnerNormalBasisFieldFunctions| (|PrimeField|
5))) 1)
...
16: 1
17: (0 10 16 20 23 0 28 30 32 0 35)
18: (NIL (4 12 48 160 480 0) (8 72 432 0) (18 216 0) (32 480 0) NIL (72 0) (98
0) (128 0) NIL (200 0))
19: (Integer)
20: <vector> :
0: (SingleInteger)
1: (#<compiled-function lookupComplete> #<vector 08ce96ac> #<vector
08ce9c94>)
21: (newGoGet #<vector 08e96b0c> 14 . coerce)
22: (Vector 6)
...
-------------------------------------------------------------------
--- First iteration, omdev.spad, OMENC
(1) -> (pspadvec (|evalDomain| '(|OpenMathEncoding|)))
...
7: (Boolean)
8: (#<compiled-function OMENC;=;2$B;1> . #<vector 08e1a594>)
9: (Integer)
10: (newGoGet #<vector 08e1a594> 0 . coerce)
11: (OutputForm)
12: (#<compiled-function OMENC;coerce;$Of;2> . #<vector 08e1a594>)
...
-------------------------------------------------------------------
--- Second iteration, omdev.spad, OMENC
(1) -> (pspadvec (|evalDomain| '(|OpenMathEncoding|)))
...
7: (Boolean)
8: (#<compiled-function OMENC;=;2$B;1> . #<vector 08e9ca48>)
9: (OutputForm)
10: (#<compiled-function OMENC;coerce;$Of;2> . #<vector 08e9ca48>)
11: (#<compiled-function OMENC;OMencodingUnknown;$;3> . #<vector 08e9ca48>)
12: (#<compiled-function OMENC;OMencodingBinary;$;4> . #<vector 08e9ca48>)
...
-------------------------------------------------------------------
--- First iteration, ffcg.spad, FFCGP
---
--- NOTE: vector element 147
(1) -> (pspadvec (|evalDomain| '(|FiniteFieldCyclicGroupExtensionByPolynomial|
(|PrimeField| 5) ((1 . 0)))))
...
12: 1
13: (#<compiled-function ZMOD;size;Nni;1> . #<vector 08e1a8f8>)
14: 5
15: (PositiveInteger)
16: (#<compiled-function SGROUP-;**;SPiS;1> . #<vector 08e72f34>)
17: NIL
...
...
144: (#<compiled-function FFCGP;/;$GF$;39> . #<vector 08e72fa4>)
145: (#<compiled-function FFCGP;inv;2$;40> . #<vector 08e72fa4>)
146: (#<compiled-function FFCGP;**;$I$;43> . #<vector 08e72fa4>)
147: (#<compiled-function FFCGP;**;$Pi$;41> . #<vector 08e72fa4>)
148: (#<compiled-function FFCGP;**;$Nni$;42> . #<vector 08e72fa4>)
149: (Union 71 (QUOTE failed))
150: (Matrix $)
...
-------------------------------------------------------------------
--- Second iteration, ffcg.spad, FFCGP
---
--- NOTE: vector element 147 above is element 16 here.
(1) -> (pspadvec (|evalDomain| '(|FiniteFieldCyclicGroupExtensionByPolynomial|
(|PrimeField| 5) ((1 . 0)))))
...
12: 1
13: (#<compiled-function ZMOD;size;Nni;1> . #<vector 08e9cdac>)
14: 5
15: (PositiveInteger)
16: (#<compiled-function FFCGP;**;$Pi$;41> . #<vector 08e9c7fc>)
17: (#<compiled-function SGROUP-;**;SPiS;1> . #<vector 08e9c674>)
...
...
144: (newGoGet #<vector 08e9c7fc> 284 . /)
145: (#<compiled-function FFCGP;/;$GF$;39> . #<vector 08e9c7fc>)
146: (#<compiled-function FFCGP;inv;2$;40> . #<vector 08e9c7fc>)
147: (#<compiled-function FFCGP;**;$I$;43> . #<vector 08e9c7fc>)
148: (#<compiled-function FFCGP;**;$Nni$;42> . #<vector 08e9c7fc>)
149: (Union 72 (QUOTE failed))
150: (Matrix $)
...
-------------------------------------------------------------------
--- First iteration, reclos.spad, RECLOS
(1) -> (pspadvec (|evalDomain| '(|RealClosure| (|Fraction| (|Integer|)))))
...
88: (newGoGet #<vector 08e72b44> 184 . *)
89: (newGoGet #<vector 08e72b44> 190 . one?)
90: (Mapping $$ $$)
91: (newGoGet #<vector 08e72b44> 195 . map)
92: (#<compiled-function RECLOS;*;I2$;23> . #<vector 08e72b44>)
93: (newGoGet #<vector 08e72b44> 201 . *)
94: (newGoGet #<vector 08e72b44> 207 . zero?)
95: (newGoGet #<vector 08e72b44> 212 . one?)
...
-------------------------------------------------------------------
--- Second iteration, reclos.spad, RECLOS
(1) -> (pspadvec (|evalDomain| '(|RealClosure| (|Fraction| (|Integer|)))))
...
88: (newGoGet #<vector 08e9c2a0> 184 . *)
89: (Mapping $$ $$)
90: (newGoGet #<vector 08e9c2a0> 190 . map)
91: (#<compiled-function RECLOS;*;I2$;23> . #<vector 08e9c2a0>)
92: (newGoGet #<vector 08e9c2a0> 196 . *)
93: (newGoGet #<vector 08e9c2a0> 202 . zero?)
94: (newGoGet #<vector 08e9c2a0> 207 . one?)
95: (#<compiled-function RECLOS;*;TheField2$;24> . #<vector 08e9c2a0>)
...
-------------------------------------------------------------------
--- First iteration, reclos.spad, ROIRC
(1) -> (pspadvec (|evalDomain| '(|RightOpenIntervalRootCharacterization|
(|PrimeField| 5) (|SparseUnivariatePolynomial| (|PrimeField|
5)))))
...
50: (newGoGet #<vector 08e72770> 140 . boundOfCauchy)
51: (newGoGet #<vector 08e72770> 145 . sturmVariationsOf)
52: (newGoGet #<vector 08e72770> 150 . one?)
53: (List 7)
54: (newGoGet #<vector 08e72770> 155 . sturmSequence)
55: (newGoGet #<vector 08e72770> 160 . unitCanonical)
...
-------------------------------------------------------------------
--- Second iteration, reclos.spad, ROIRC
(1) -> (pspadvec (|evalDomain| '(|RightOpenIntervalRootCharacterization|
(|PrimeField| 5) (|SparseUnivariatePolynomial| (|PrimeField|
5)))))
...
50: (newGoGet #<vector 08e9cfc0> 140 . boundOfCauchy)
51: (newGoGet #<vector 08e9cfc0> 145 . sturmVariationsOf)
52: (List 7)
53: (newGoGet #<vector 08e9cfc0> 150 . sturmSequence)
54: (newGoGet #<vector 08e9cfc0> 155 . unitCanonical)
55: (newGoGet #<vector 08e9cfc0> 160 . numberOfMonomials)
...
additional information --Mon, 24 Jan 2005 21:15:23 -0600
===================================================================================================
No, NONE of the files with changes in the lisp code on the 1st
iteration are on the bootstrap list. Here's the list:
> --- int/algebra/BINFILE.lsp Thu Jan 6 22:22:55 2005
> +++ int/algebra/BINFILE.NRLIB/code.lsp Thu Jan 6 23:09:32 2005
> --- int/algebra/D01AGNT.lsp Thu Jan 6 22:22:57 2005
> +++ int/algebra/D01AGNT.NRLIB/code.lsp Fri Jan 7 00:23:04 2005
> --- int/algebra/FC.lsp Thu Jan 6 22:23:00 2005
> +++ int/algebra/FC.NRLIB/code.lsp Thu Jan 6 23:59:50 2005
> --- int/algebra/FFCGP.lsp Thu Jan 6 22:23:01 2005
> +++ int/algebra/FFCGP.NRLIB/code.lsp Thu Jan 6 23:39:00 2005
> --- int/algebra/FORTRAN.lsp Thu Jan 6 22:23:02 2005
> +++ int/algebra/FORTRAN.NRLIB/code.lsp Fri Jan 7 00:00:23 2005
> --- int/algebra/INBFF.lsp Thu Jan 6 22:23:04 2005
> +++ int/algebra/INBFF.NRLIB/code.lsp Fri Jan 7 00:23:21 2005
> --- int/algebra/OMENC.lsp Thu Jan 6 22:23:10 2005
> +++ int/algebra/OMENC.NRLIB/code.lsp Thu Jan 6 22:49:46 2005
> --- int/algebra/PATTERN.lsp Thu Jan 6 22:23:11 2005
> +++ int/algebra/PATTERN.NRLIB/code.lsp Thu Jan 6 23:45:01 2005
> --- int/algebra/PRIMELT.lsp Thu Jan 6 22:23:13 2005
> +++ int/algebra/PRIMELT.NRLIB/code.lsp Thu Jan 6 23:45:25 2005
> --- int/algebra/RECLOS.lsp Thu Jan 6 22:23:14 2005
> +++ int/algebra/RECLOS.NRLIB/code.lsp Thu Jan 6 23:45:39 2005
> --- int/algebra/ROIRC.lsp Thu Jan 6 22:23:14 2005
> +++ int/algebra/ROIRC.NRLIB/code.lsp Thu Jan 6 23:28:06 2005
>
There are subtle semantic differences (not formatting differences)
in all of the above files.
But yes ALL of the original bootstrap .lsp files from the
pamphlet files *are* outdated in the sense that they appear to
have been produced by a very different version of Axiom (or
maybe even hand-compiled in some cases?). The lisp code produced
by AXIOM from the spad files corresponding to the bootstrap
files (which is done as the last step in the Algebra build) is
formatted very differently than the original bootstrap lisp code.
A diff of the original bootstrap files shows them as entirely
different although a quick inspection shows that the semantic
content is at least VERY SIMILAR to what Axiom produces for
these files.
In my fixedPoint script, I do not bother to show the initial
differences of the bootstrap files after only the first build -
they are all different (different variable names, pretty
printing etc.) Only a hand-analysis could determine how different
they really are. And of course at this first step it is not
possible to compare any of the non-bootstrap files because we
do not have any lisp files other than those for the bootstrap.
What I do show in the fixedPoint.log file is the result AFTER
first replacing the bootstrap lisp files with the newly generated
lisp for ALL of the SPAD files and then running the make a 2nd
time (I called this the 1st iteration). This is where I find
differences in the generated lisp code in the 2nd pass compared
the lisp code from the first pass. None of these differences
are in the original bootstrap files. In this comparison the none
of the original bootstrap code is still present. It had all been
replaced with newly generated code in the previous step and did
not change in the 2nd step. However other files (non-bootstrap
files) did change. This is why I say that the differences in the
original bootstrap files seem to have "propagated along the
dependencies" to some of the files that directly depend on the
bootstrap files. This is what really had me worried.
In spite of the fact that the original bootstrap files are out
of date, I did (more or less) expect from your description of
the process that on the 2nd pass with all newly generated lisp
files, that the next generation of lisp files would not change,
but they do. On the 3rd pass, finally all of the lisp files
match with the lisp files from the 2nd pass. (I called this the
"fixed point" since no further change can take place after that.)
If I were to replace all of the bootstrap lisp code in the
current pamphlet files with the newly generated lisp code then
it seems likely (unless I am missing something rather basic)
that the build should immediately converge to the fixed point
on the first pass. This is, of course what we should do in the
SHORT TERM. But the longer term question for me is: Do changes
in the spad files really propagate like this from one file to
the next in the dependency chain? If the answer is yes, then
this means that every time we make a change in ANY of the
algebra spad files (not just the spad files that have bootstrap
lisp code), then we will have to run the fixedPoint script in
order to make sure that we have new bootstrap lisp code that
is consistent with the spad code (the system of spad and lisp
files must "converge"). We need to do this because the dependencies
are really cyclic - they really do loop back on themselves. So
changes deeper down in the "lattice" (not really a lattice) can
potentially propagate back around to the bootstrap lisp code.
additional information --Mon, 24 Jan 2005 21:16:48 -0600
==============================================================================================
Although technically it probably doesn't matter, but as
far as I can tell from the email archives, the version
of the databases that we have been using on Savannah was
actually supplied by Jergen Weiss after he was the first
to successfully build the full set of Axiom spad files under
GCL in about August 2003.. The problem with compiling some
of the spad files up until that point was apparently that
the database files from the NAG version that you had been
using were somehow incompatible with GCL. I think Jergen
actually obtained the original database files that he used
to bootstrap GCL from some other version of Axiom (based on
a different lisp, CMCL?). He was then able to build a new
set of databases directly using the GCL version of AXIOM.
In about September 2003 on your request I uploaded these
database files to the Savannah CVS. As far as I know, these
are still the same ones we are using today unless you replaced
them again at some point. The minor differences that I saw
between the most recently built database files and the ones
that Jergen built was probably due to one or two addition
spad files that were missing from Jergen's build.
In any case, this does not seem to be the reason for the
"propagation" of changes in the *.lsp files.
Regards,
Bill Page.
> -----Original Message-----
> From: root [address@bogus.example.com">mailto:address@bogus.example.com
> Sent: Friday, January 07, 2005 10:53 AM
> To: address@bogus.example.com; address@bogus.example.com
> Cc: address@bogus.example.com
> Subject: Re: [Axiom-developer] RE: algebra Makefiles with
> explicit dependencies, bootstrap, fixed-points etc.
>
>
> Bill, Steve,
>
> Note that the original databases are the NAG versions and the actual
> algebra code has been improved since that time. Modifying the algebra
> will change the domain vectors. These vectors contain hard-coded
> indexes. So, for instance, PLEQN is new since NAG's version so the
> domains which use it will have different index values. The database
> build is done after the algebra is compiled and should reflect the
> actual algebra whereas the original databases may not.
>
> t
>
axiom of a field --unknown, Thu, 16 Jun 2005 00:45:59 -0500
... --kratt6, Fri, 28 Dec 2007 14:45:39 -0800
Category: Axiom Mathematics => building Axiom from source
... --test1, Tue, 15 Apr 2014 17:06:35 +0000
Status: open => closed
|