Re: [MIT-Scheme-devel] [commit 13b5bca] Fix new build to cross from 9.1.1.

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Tue, 15 Oct 2013 20:44:36 +0000
> 
> [...]
> 
> The toolchain necessary to build the system (macro expander, sf, cref,
> compiler) should be able to run in a wide variety of host systems,
> including many versions of Scheme [...]

A cool branch.  It would be nice to more easily reason about who
expanded what, but it is not so difficult in 99% of the cases.  It
would be weird (and wonderful) to boot on another Schemeish, but at
what cost?  The entire compiler must be written in R3RS?  No
#!optional arguments or *parser or nutt'n?

> [...]  The build should furthermore have clear semantics so that we
> can get reproducible results in all those different environments.

The semantics that RELEASE is our host and NEW-RELEASE our target is
clear.  That runtime/ is syntaxed with RELEASE's *parser (unless it
makes other arrangements) I thought was plain enough.  Tough cookies
for those who want to use a new *parser operator before it appears in
RELEASE, but they can make their arrangements.

>    I cannot build master on 9.1.1 (again).  Is that no longer a priority?
> 
> That is still a priority.  It looks like the scaffolding to transition
> from a world with SEQUENCE_2 and SEQUENCE_3 to a world with only
> SEQUENCE_2 has been dropped, though, which makes this more laborious
> than I was hoping it would be...

There were more hacks like type-aliases and returns-aliases?

>    All these errors look familiar, but you did not like my solution,
>    so... I await enlightenment.
> 
> The anomalous microcode error arises because [ scode/sequence-
> immediate-first ] did not exist in the host 9.1.1 runtime.
> 
> If you replace (scode/sequence-immediate-first ...) by (car
> (scode/sequence-actions ...)) [...] it gets further still.

Further toward what?  And what have you done to the compiler source?
That's our "native" compiler too.  For our native compiler source to
function as a cross compiler, the host has to implement the native
language.  If the host is RELEASE, a little training will do it.  If
the host is Whatnot, you'll have to start by re-implementing READ to
accept "#!optional" and re-defining basic syntax like DEFINE and
LAMBDA...

> But I think that the resulting make.com, dumped by 9.1.1, still has
> SEQUENCE_3 objects embedded in it, which confuses the microcode from
> HEAD.  However, at that point I ran out of time to look into the
> problem further last night.

Ya, been there, with a broken debugger.

> It may be that using my portable fasdumper with the cross-compiler
> will suffice to get this working, because it is guaranteed not to dump
> SEQUENCE_3 objects even in a host that uses them in memory.

The cross (I can't say portickle) fasdumper would be interesting if it
dumped wildly different heap formats: low tags, constants at the start
of a compiled code block, supposedly portickle stuff, etc.

> It may be that we could persuade the sf and compiler in-tree to use
> their own MAKE-SEQUENCE  [...]

If the cross compiler were linked to a cross runtime (just bits of
runtime/), it would have the correct make-sequence.  In the well-
trained cross runtime, the cross compiler would also get an emulated
scode/sequence-immediate-first.

> [...] this might be less work than working out any issues that may
> arise with a portable fasdumper.

A cross fasdumper would trump all issues of heap format.  We got lucky
again using type-aliases.  That only worked because SEQUENCE and
SEQUENCE-2 are the same in host and target heaps.  We are stuck for
word-size and all as long as the cross compiler is dumping host
binaries that the target is expected to fasload.

> However, I am inclined to say that maybe we ought to cut 9.2 from
> commit 96ffae5, from before I made a hash of the top-level makefile;
> cherry-pick whatever important changes we've made since then; and
> then fix up the build (and perhaps get cross-compilation working as
> a first-class citizen!) in HEAD for 9.3.  What do you think?

Your "hash" finally got the sequence-3's out of the native
distribution's .bcis.  It turned my 15 minute builds into 45 minute
builds, but that's what it takes to compile a cross-compiler,
cross-compile a boot-compiler, and compile everything natively.

Please keep the hash.  I was afraid 9.2 might appear with crap .bcis.
If you just revert aab92f7 you can release a VERY nice 9.2 forthwith.

I think I'd rather be Schemeing in 3D.