axiom-developer
[Top][All Lists]
Advanced

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

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


From: Stephen Wilson
Subject: Re: [Axiom-developer] RE: algebra Makefiles with explicit dependencies, bootstrap, fixed-points etc.
Date: Sun, 16 Jan 2005 16:04:29 -0500
User-agent: Mutt/1.5.6+20040907i

Bill, Tim,

Here are some interesting clues. Based upon my earlier email which
listed the differences in domain vectors w.r.t first- and
second-iteration fixed-point builds, we could see that SINT is somehow
involved. I should probably continue this enquiry to see if the
differences are all of the same `kind' as shown below. But from what I
can tell, the compiler `knows something' during the second iteration
build. The databases left over in the int/algebra directory?


=============
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.
=============

=============
PATTERN

The differences in the lisp code is more involved. Recall the
differences in the domain vectors that I provided earlier:

-------------------------------------------------------------------
--- 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))
...


In the first-iteration code, a call to SINT's coerce: Integer -> $ is
represented in the domain vector in slots 32, 33. The second-iteration
vector does not contain this code.

Noting the above, the differences in the generated lisp for PATTERN
are fairly easy to understand. All calls into the domain vector with
slot indexes > 31 in the second-iteration code appear shifted down by
two in comparison to the first-iteration code. The only difference is
in the calls to SINT's coerce. In the second-iteration, these calls
are not made. The transformation is: 

   (SPADCALL 2 (QREFELT $ 33)) --->  2

At the top of pattern.spad we see a set of macros:
   
  SYM_GENERIC  ==> 1::SI
  SYM_MULTIPLE ==> 2::SI
         ....
  PAT_ONE      ==> 5::SI
  PAT_EXPT     ==> 6::SI

These macros are being expanded `literally' in the first-iteration
code, whereas in the second-iteration the compiler is `inlining' the
call to coerce.
=============


=============
D01AGNT

Similar to PATTERN. Coercions for SINT are being inlined. 
=============


=============
FC

The FortranCode domain contains a local variable:

     labelValue:SingleInteger := 25000::SingleInteger

It is represented explicitly in the domain vectors. (slot 10 in the
first iteration, slot 7 in the second). All the differences in both
first- and second-iteration code are w.r.t a shifted domain
vector, and are effectively equivalent, in all but one respect: In the
instantiation code for the domain:

  - (QSETREFV $ 10 (SPADCALL 25000 (QREFELT $ 9))) 
  + (QSETREFV $ 7 25000)

Here the domain slot representing 25000 is being initialized via a
call to SINT's coerce, where as in the second the coercion is inlined.
==============


Does this help trigger an explanation? Any thoughts?


Cheers,
Steve




reply via email to

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