Re: bootstrap integration strategies

[ludo@gnu.org (Ludovic Courtès)]

Hello!

Jan Nieuwenhuizen <janneke@gnu.org> skribis:

> 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.

OK, I see.  Thanks for explaining.

> 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?

I think we should try and use what we have now in ‘wip-bootstrap’, and
keeps things unchanged for ARM and GNU/Hurd.  Ricardo?

>>>> 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.

No no, in my view we’d use Mes simply as the guile-for-build in the
early derivations (the interpreter that runs the build phases from (guix
build build-system)).

It’s a job where we don’t need much performance, but we need the POSIX
layer—‘system*’, (ice-9 ftw), and so on.

>>>>   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.

OK.

> 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.

Sure, understood.

My hesitation comes from the fact that this will increase maintenance
cost on the Guix side.  At the same time, this is clearly the direction
we want to take, and I such I think we have to get our act together and
go forth.


What’s the exact status of ‘wip-bootstrap’ on non Intel arches?  Is it
still like ‘master’?  If it is, that’s fine.

Does it use the Mes/MesCC/tcc path for i686 only, or is it i686 +
x86_64?  (I would expect the latter.)

If there are no regressions, I’d be willing to simply merge it in
core-updates.  I’d like some of us to take another look at it—Ricardo,
Mark, and anyone with an interest in this.  And then I guess we could
go.

How does that sound?

Thank you for your patience!
v
Ludo’.