Re: [Axiom-developer] SBCL and Axiom

[Gabriel Dos Reis]

On Mon, 12 Feb 2007, C Y wrote:

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

The New Boot translator has the command  boottran::boottoclc (no the
ending 'c') that includes the definitions being translated as comments
in the CL output.

I have to make a list of reserved words or "library" functions that
both Old Boot and New Boot use.  That should help you quickly focuse
on the "interesting" bits.

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

Agreed.  I believe the Boot "language" shields us from many low-level
details and quickly move to the real issue.  I acknowledge that the
state we are now where it has been neglected is unfortunate.  I'll try
to do as much as I can.

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

Yes.  Note also that the New Boot translator has the framework to
generate machine code (when told where the CL compiler is) from Boot
and load it in the running image at a go.

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

There are still some GCL-isms deeply embedded in Axiom.

-- Gaby