Re: bootstrap integration strategies

[Jan Nieuwenhuizen <janneke@gnu.org>]

Ludovic Courtès writes:

>>> I think that's the main difficulty.  I think we'd rather not have
>>> separate bootstrap paths for Intel GNU/Linux on one hand, and everything
>>> else on the other hand.
>>
>> Well, due to the design of mescc-tools; the bootstrap paths only have to be divergent up to the M1-macro level.
>> After that, we could simply use flags make the source work on different platforms
>
> Sounds nice.  I wonder if Jan was referring to something else then?

I was looking at a narrower, or more short-term perspective.  M1 is
solving *a lot* of problems for us.  The only platform-dependency that
Mes then has, is:

    lib/x86-mes/x86.M1: About 200 M1 macros such as

        DEFINE add____$i32,%eax 05
        DEFINE add____$i32,%ecx 81c1

So, technically it's solved.  In practice, MesCC doesn't do proper
register mapping.  So, we could hard-wire a mapping for AArch64 but we'd
probably want to introduce abstraction.  That's a significant effort.
Also, we'll have to solve all tiny details/bugs that we encounter in
MesCC.  There's no real limitation, just some hard choices and work.

Then there is some assembly in Mes lib/linux-*.c as well, much less of a
problem, could still take weeks of work.

Then we have TCC; i'm not sure at their support for AArch64, and of
course we currently use gcc-2.95 which also doesn't do AArch64.  GCC 3
depends on a richer C library.  Of course we can make that (and this is
one of the things we will most probably do anyway) but still: work.

So what I was saying is probably: we have x86 NOW, can we use it and do
we want that somehow?  OR do we plan some of the work above, and go that
route?

> There’s still the question of GNU/Hurd, though, which requires a vastly
> different libc.

Yes.  I "almost" have a hello world there.  TBH, after spending about
half a week on it, I think x86/Hurd may be the easiest second
architecture...maybe amd64.

> So, problem solved?  Or am I missing something? :-)
>
> I think the ‘wip-bootstrap’ branch does not use M1 at this point, does
> it?

Sure, wip-bootstrap uses M1.  Currently the %mes-seed consists of
mes.M1; M1 is then used to produce a binary.  We are working to remove
this seed by translating mes.c into mes.M2.

Also, MesCC produces M1 output; so tcc is compiled to M1, and then to
binary.

>>> there's also another option you didn't mention: ditching the 2.0
>>> bootstrap Guile in favor of Mes.  That can be done in several steps:
>>
>>>  1. Replace the guile-2.0.*.xz binary tarballs with Mes, and add a step
>>>      that builds Guile 2.x using our big bootstrap GCC binary.
>> Slow but possible

Yes, performance is really the thing here.  Currently, mes is about 30x
slower than Guile.  It will definately not work if mes has to interpret
all of gnu/packages/*.scm, it may work if we can do something smart.

Also, Mes resembles Guile just enough to run Nyacc, but it's not on par
with Guile by far.

>>>   2. Same, but build Guile 2.x, libgc, etc. using MesCC.
>> MesCC can't directly build Guile yet but I do enjoy that ambition ;-)
>
> I wonder what it would take to fix that.  After all, compiling libguile
> must not be much harder than compiling tcc, no?

tcc is ~20,000LOC (1.5h to build), libguile is ~100,000LOC, libgc is
~30,000LOC.  Unless we find a way to compile a fraction of libguile #if
!BOOTSTRAP ..., compilation could take a day.  The good news is that
MesCC also runs on Guile, so development would suffer less from this.

I *really* like taking the early Mes route, or early Guile route (1 or
2).  I don't see how it these would work out--it just feels right.

> IMO what matters most at this point is to come up with a plan that allow
> us to incrementally reduce the size of our binary seeds.  A port of
> M1/stage0 to Z80 can wait.  ;-)  So we really need a list of actionable
> items in the short term to start taking advantage of all the work that’s
> been done on Mes, MesCC, M1, stage0, Gash, etc.

Hmm, yes!

My idea was to remove gcc, glibc and binutils from the x86 bootstrap
binaries (possibly one at a time) and replace them by M1+Mes+Tcc-built
ones.  Possibly by adding an alternative %bootstrap-binaries package
without them.  Then build the x86 system on top of that.  Then, or
meanwhile, start thinking about x86_64 or AArch64.

I'm not saying this because I think it's better than an early Guile
route, but it's only because I think I know this can be done.

Greetings,
janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com