[Top][All Lists]

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

Re: Removing compilers that cannot be bootstrapped

From: Jookia
Subject: Re: Removing compilers that cannot be bootstrapped
Date: Tue, 22 Mar 2016 20:56:28 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Mar 21, 2016 at 11:48:40PM +0100, Ludovic Courtès wrote:
> Often, in their implementation history, compilers are boostrapped from
> something else initially, and only later to they become self-hosted and
> unbootstrappable.
> So in theory, it’d be possible to find, say, an old-enough GHC that only
> requires a C compiler (?), and use that to build the next version and so
> on, until we reach the latest version.  I suspect the same applies to
> many compilers.

I'm not sure about this. Bootstrapping older compilers means there's often less
support for the platform you're on, which means we'll end up in a situation
where we're bootstrapping from machines and cross-compiling, and I forsee the
problem being that we'll have to rely on nonfree code or machines as our huge
backhaul in a decade where we're on some cool free hardware RISC architecture.

For instance, to run GHC on ARM you can only use a recent GHC, all the old
versions didn't support it. Sure you could go from C to get an old GHC on ARM,
but it wouldn't have support for outputting ARM assembly.

> This is technically possible.  The main difficulty is to find what exact
> chain of compiler versions will work, and then to make sure that the
> super-old compilers can build.  The risk, as Andreas suggests, is that
> maintaining those old versions will require dragging a whole graph of
> old dependencies, recursively.

Guix could be well suited to this with its ability to create environments with
bitrotted tools.

> But really, we won’t know until we’ve actually tried ;-), and it’ll
> be different for each compiler.
> I would suggest that people pick a compiler they’re more or less
> familiar with, and give it a try.  MIT/GNU Scheme might be a good start,
> since we should be able to talk with the folks behind it and reach
> mutual understanding.  ;-)
> For GCC, an idea discussed at
> <> would
> be to build GCC 4.7 (the last version written in plain C) with something
> more auditable like TinyCC, and then use this g++ 4.7 to build whatever
> GCC version we want.  Again, sounds like it should work, but we need to
> actually try.

Sounds interesting, and even better if we could compile the rest of the
bootstrap with just TinyCC.

> Thoughts?

Many! :)

> BTW, the “good news” is that more and more compilers build upon LLVM,
> and for those there’s no bootstrapping problem if we take the C++
> compiler for granted.

Is this true? I know a lot of compilers *use* LLVM as a backend, but not sure
about their frontends.

That said, LLVM's a bit of a problem in itself, to the point GHC has decided to
fix a lot of their issues with the ARM platform by bundling a LLVM version to be
consistent across distros. I think there's also been talk of taking advantage of
this to remove useless phases or add Haskell-specific ones to LLVM, so we'd end
up LLVM just being another part of the toolchain. This is a bit off topic though
since it doesn't relate to bootstrapping but to bundling. ;)

> Ludo’.


reply via email to

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