|
|
|
last edited 10 years ago by test1 |
Edit detail for #17 algebra BOOTSTRAP fixed point revision 1 of 3
| 1 2 3 | ||
|
Editor:
Time: 2007/11/17 22:03:34 GMT-8 |
||
| Note: axiom of a field | ||
changed: - 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 From unknown Mon Jan 17 21:19:24 -0600 2005 From: Date: Mon, 17 Jan 2005 21:19:24 -0600 Subject: fixnum optimization in new compiler Message-ID: <20050117211924-0600@page.axiom-developer.org> 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 From unknown Mon Jan 17 21:24:41 -0600 2005 From: Date: Mon, 17 Jan 2005 21:24:41 -0600 Subject: Integer substitutions Message-ID: <20050117212441-0600@page.axiom-developer.org> > ... >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? From unknown Tue Jan 18 23:05:23 -0600 2005 From: Date: Tue, 18 Jan 2005 23:05:23 -0600 Subject: more questions Message-ID: <20050118230523-0600@page.axiom-developer.org> 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. From unknown Tue Jan 18 23:06:43 -0600 2005 From: Date: Tue, 18 Jan 2005 23:06:43 -0600 Subject: yet another wrinkle Message-ID: <20050118230643-0600@page.axiom-developer.org> 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. From unknown Sat Jan 22 02:53:21 -0600 2005 From: Date: Sat, 22 Jan 2005 02:53:21 -0600 Subject: ONEP removed globally Message-ID: <20050122025321-0600@page.axiom-developer.org> 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. From unknown Mon Jan 24 21:14:01 -0600 2005 From: Date: Mon, 24 Jan 2005 21:14:01 -0600 Subject: additional information Message-ID: <20050124211401-0600@page.axiom-developer.org> =============================================================================================== 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) ... From unknown Mon Jan 24 21:15:23 -0600 2005 From: Date: Mon, 24 Jan 2005 21:15:23 -0600 Subject: additional information Message-ID: <20050124211523-0600@page.axiom-developer.org> =================================================================================================== 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. From unknown Mon Jan 24 21:16:48 -0600 2005 From: Date: Mon, 24 Jan 2005 21:16:48 -0600 Subject: additional information Message-ID: <20050124211648-0600@page.axiom-developer.org> ============================================================================================== 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 > From unknown Thu Jun 16 00:45:59 -0500 2005 From: unknown Date: Thu, 16 Jun 2005 00:45:59 -0500 Subject: axiom of a field Message-ID: <20050616004559-0500@page.axiom-developer.org>
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