[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] Rework amd64 ABI -- flag day

From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] Rework amd64 ABI -- flag day
Date: Sun, 6 Jan 2019 04:31:00 +0000

> Date: Sat, 5 Jan 2019 17:59:40 -0800
> From: Chris Hanson <address@hidden>
> I'm going to put out a new bug-fix release this weekend, so please not
> until that's finished.


> Otherwise, just choose a day and let us know. And, of course, tell us how
> to do the change since we'll each need to do this.
> It sounds like this will break our rule about being able to build the next
> release from the current one. Is that right? I don't object, but it will
> have to eventually be explained at the time of release. Unless the
> changeover can be scripted so that the rule isn't broken.

I'll see if I can find a convenient way to script this.

What does work is running a new compiler as an application on a new or
old runtime and on a new or old microcode: as a Scheme program, the
compiler (and sf and cref &c.) doesn't rely on any changes to the ABI
implemented in the new microcode -- only the code it generates does.

The trouble is that if you compile the new runtime (and new compiler)
with an old compiler, then the code generated by the old compiler
won't run on the new microcode.

So you just ./configure && make as we have it now with an old Scheme,
you'll get the old Scheme's ABI in compiled code and the new Scheme's
ABI in microcode and they'll explode on contact.

Changes like this branch were part of the motivation for the way I did
a separate toolchain build a few years ago: first compile a new
compiler that runs on the old Scheme, then use the new compiler on the
old Scheme system to compile a new runtime that runs on the new

reply via email to

[Prev in Thread] Current Thread [Next in Thread]