[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] [commit 13b5bca] Fix new build to cross from 9.1.
Re: [MIT-Scheme-devel] [commit 13b5bca] Fix new build to cross from 9.1.1.
Wed, 16 Oct 2013 10:24:33 -0700
> 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
> 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
> [...] 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.