[Axiom-developer] Sources of the port of Axiom to SBCL/CMUCL/Clisp (was: SBCL and compiler speed)

[Gregory Vanuxem]

Le vendredi 23 février 2007 à 00:41 +0100, Waldek Hebisch a écrit : 
> > 
> > I you want I can upload what I have done (more precisely what is
> > "distributable"), I planned to upload it Sunday but I'm not against this
> > idea (I'm busy). The bad news is that the interpreter is not
> > pamphletised [1], I do not think that the documentation must be done
> > now, it has to be done when merging and when, I think, we have _fixed_
> > the API (a lot of functions rely on CltL1 (GCL ?) (symbol used to
> > extensively for example)). WHat I'm saying does not prevent to document,
> > "conceptually", some part of the "interpreter" such that the database,
> > the compiler(s) etc...
> > 
> > Greg
> > 
> > [1] The build process is buggy too, somes versions of Make (the one in
> > Cygwin for example) does not accept the algebra Makefile and its
> > inclusions.
> > 
> 
> It would be nice to see your version.  I certainly would like to
> know how you solved some specific problems (non-ANSI type declarations,
> BPINAME function etc).  I would like also to time build process.
> 

Here are the sources:

http://perso.orange.fr/parabola/axiom-cl.tar.gz

It is based on the work of Juergen Weiss available here:

http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz

(So you can easily diff these to know who did what)

For the question of BPINAME, I have the same problem than you.
When I read your code I was particularly interested in your
implementation of this function. This function is
implemented but further investigations are needed.

For example the 

((and (consp func) (eq (car func) 'lambda)) (second (third func)))

is probably never used. Furthermore in boot code we can see several
reference to compiled-function-p before using BPINAME, compiled-function-p
is really implementation dependant so... I will work on this when time will 
permit.

Anyway there are numerous "TODO" in the code, if some of you want to work on
this port feel free to improve it :-) (when there are "QUESTION" in the code
this is because further investigation are needed and eventually I'll have to
ask Juergen Weiss why it's implemented this way). 

To compile it 'cd' to src/boot, edit the Makefile.(sbcl|clisp|cmu) and the 
Makefile.inc
to change the variables defined if necessary (you'll have, for sure, to modify 
AXIOMROOT).
Export the AXIOM environment variable so for example with SBCL :

export AXIOM=/usr/local/axiom-cl/mnt/sbcl

and use 'make -f Makdefile.sbcl' to build bootsys with SBCL.

Do the same thing for src/interp and src/algebra.

To use Axiom do not forget to export the environment variable AXIOM
(this is necessary for the moment).

The build process has been done in such a way that you can easily build
Axiom for each CL implementation (and test the three at the same time).

And, a last remark (for fun) 

<Hans Reiser argument>

Original Axiom:
----------------------------------------------------------------------------
time echo ')r zdsolve' | /usr/local/axiom/mnt/linux/bin/AXIOMsys &>/dev/null

real    1m24.392s
user    1m21.025s
sys     0m1.010s
----------------------------------------------------------------------------
Axiom on SBCL:
----------------------------------------------------------------------------
time echo ')r zdsolve' | /usr/local/axiom-cl/mnt/sbcl/bin/interpsys &>/dev/null

real    0m29.127s
user    0m25.860s
sys     0m0.506s
----------------------------------------------------------------------------

</Hans Reiser argument>

And there are a lot of other types of remark...

Greg

PS: If you have fix, amelioration etc... please let me know.

PS2: For the "warriors" who want to use Aldor edit foam_l.lisp since
it's specialised for me (the |SInt| type). A better way is to use an integer
range as type instead of a predefined type such that fixnum. The
other problem is that we don't have the sources so we can not know
what exactly a |Sint| is.)

================================================================================
KNOWN PROBLEMS (not related to Axiom):

If you encounter a "NIL is not of type continuation" with CMUCL try to change
the safety optimise setting, this is apparently a bug in CMUCL.

Some versions of SBCL (mine for example (x86-64)), apparently, loop indefinitely
when computing the gcd with MOST-NEGATIVE-FIXNUM as one of its arguments. 
Solution
fix SBCL :-)

(this one is related to the build process of Axiom)
It will be not possible to build the algebra with some version of Make.
This need to be  fixed. The typical error message is something like
"can not load BASTYPE", this type is not available since the corresponding
.spad file is not compiled). On MinGW-MSYS I have to create the included 
makefiles
with the "standard" version of make and use the "packaged make" to
build the algebra :-(