Re: [Axiom-developer] depsys and SBCL

[Gregory Vanuxem]

Le mardi 27 mars 2007 à 11:05 -0500, Gabriel Dos Reis a écrit : 
> Hello,
> 
>   In my local tree, I was able to eventually twist Axiom to get it
> compilable by SBCL.  During that process, I unconvered various dubious
> practices in the current system (mainly between vmlisp.lisp and
> macro.lisp).  SBCL will accept to compile depsys only if I tell it to
> ignore many redefinitions of Common Lisp symbols (I'll discuss that in
> a separate message).
> 
>   CLISP almost compiles SBCL -- it errors out on def.lisp saying
> that there is an illegal character #\Stx in the source file -- I have
> no idea of what that means.  If I omit def.lisp, the depsys
> compiles fine -- 

Hmm... I forgot to add this issue to my TODO list. I temporary followed
how GCL behaves i.e omit it. I was/am pretty sure this is incorrect but
as far as I know this part of code is not used. I just commented out
this function. ^L is also used at several places.

>I have not tried the resulting translator however.

Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
(foo)) as done by Juergen Weiss ? I based my work on his work and this
version does not contain all the src/interp file that we can find in
Gold. Adding a new file is always difficult because of this issue (that
must be done carefully).

> This is just a head up.  If you know anything about the illegal
> character \#Stx, please let me know.

No idea.

> Ah, one more thing: Currently, there is this dubious definition in
> foam_l.lisp: 
> 
>    #+:AKCL
>    (deftype |DFlo| () t)
>    #-:AKCL
>    (deftype |DFlo| () 'long-float)
> 
> followed by
> 
>    (defconstant |DFloInit| (the |DFlo| 0.0d0))
> 
> which is an error because 0.0d0 is not long-float -- rather a double-float.
> 
> Looking more at this, I think the |DFlo| should not be conditional.

I don't know why the Aldor implementers used the t type to define DFlo
on AKCL and since we do not have access to the Aldor source code it's
difficult to know why. There are other issues in this file, for example
it _seems_ that the SInt type has to be a 32 bits integer (on a 32bit
arch) but they defined it to be a fixnum. This is clearly wrong on CMUCL
and Clisp (and probably other), their fixnums are 29 bits integers if I
remember correctly (and if log2 MOST-POSITIVE-FIXNUM really represents
that). For other issues you can look at the tarball that I uploaded [1].
A quick note here, the last (beta) version of Aldor comes without an
indispensable file, runtime.lsp [2]. I hope they will continue to
support the lisp backend though I rarely use it.

> Furthermore, I think we should use double-float instead of long-float
> -- it fits more in most modern FPU and its underyling representation
> is more widely uniform.
> This is a change for people connecting Axiom to Aldor through FOAM.

I totally agree, this should be done everywhere (in the algebra too:
DFLOAT.spad). From what I know the Lisp double-float type is generally a
hardware float (see for example
http://www.cs.berkeley.edu/~mhoemmen/matlisp/floating-point.html). But
this is not the case for long-float on Clisp (arbitrary precision). We
might add a new type that represent hardware float.


Greg

[1] Do not take into account my definition of the SInt type, I use
    a 32 bit CMUCL in a 64 bit environment (64 bits aldor)
[1] This is, apparently, a generated file (from a as file).