Re: [Axiom-developer] SBCL and Axiom

[C Y]

--- Gabriel Dos Reis <address@hidden> wrote:

> C Y <address@hidden> writes:
> 
> [...]
> 
> | Gaby has proceeded much deeper into the BOOT world than I was ever
> | able to and the presence of old and new BOOT (shoe?) adds a rather
> | unexpected twist.  The prospect of fixing BOTH variations to output
> | correct code is not a particularly enjoyable one.
> 
> It is wrong to have both variations around.  Old Boot should go away.
> That is non negotiable.

Agreed.
 
> | Gaby, did SHOE ever reach a point where it could convert all of the
> | Axiom BOOT code to lisp?
> 
> We are almost there.  I've found that the new Boot is much simpler,
> and more comfortable to work with.  

Excellent news.  Is there anything I/we can do to help that process
along?  When we have that, I would like to take another run at getting
the complete bootstrap process working on sbcl.  Roughly, I think it
will work something like:

1.  Get boottocl working and compare the generated output to the
current output, and identify any differences.  Once we can generate the
same output, in theory Boot/Shoe should be functional.  I don't
anticipate any tremendous difficulty here based on my earlier
experiences.

2.  Once it is working, start tracking down gotchas that prevent the
generated lisp code from working in SBCL, and start tweaking BOOT to
generate correct results.  In one sense I would prefer to work directly
with the lisp code but I think that is too large a project to start
with - fixing BOOT to generate legal ANSI code should (hopefully) be a
relatively straightforward change.

3.  Once we can load the generated files from BOOT successfully, see if
the SPAD compiler also needs fixing.  If the translation is
SPAD->Boot->Lisp we should be OK, but I'm guessing it's SPAD->Lisp and
so more tweaking will be needed.  Hopefully the changes to BOOT will
map fairly readily to SPAD as well.

The completion of that process should leave us with a functional Axiom
on sbcl using the existing process and no hand tweaked lisp files other
than the ones that are lisp now, which I think is where we want to
start when merging portability changes back into the main tree given
the current build situation.  Hand tweaked lisp files that are supposed
to be autogenerated will work in specific cases but will be hard to
maintain, so I think we need to bite the bullet and go back to the
source.  Once we are running in sbcl using the existing bootstrap
process we can try many things (like asdf) without being forced to step
carefully around the build issues, which I think will help speed things
up.

Cheers,
CY


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php