From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bootstrap integration strategies Date: Fri, 13 Jul 2018 14:20:05 +0200 Message-ID: <87lgafgwei.fsf@gnu.org> References: <874lh4toq8.fsf@gnu.org> <87a7qwjqsp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdx3Z-0006gk-9S for guix-devel@gnu.org; Fri, 13 Jul 2018 08:20:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdx3X-0005BV-Ui for guix-devel@gnu.org; Fri, 13 Jul 2018 08:20:17 -0400 In-Reply-To: <87a7qwjqsp.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Thu, 12 Jul 2018 19:40:38 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jan Nieuwenhuizen Cc: "guix-devel@gnu.org" , "Orians, Jeremiah (DTMB)" Hello! Jan Nieuwenhuizen skribis: > Ludovic Court=C3=A8s 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 everythi= ng >>>> else on the other hand. >>> >>> Well, due to the design of mescc-tools; the bootstrap paths only have t= o 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 =E2=80=98wip-bootstrap=E2= =80=99, 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=E2=80=99d 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=E2=80=99s a job where we don=E2=80=99t need much performance, but we nee= d the POSIX layer=E2=80=94=E2=80=98system*=E2=80=99, (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=E2=80=99s the exact status of =E2=80=98wip-bootstrap=E2=80=99 on non I= ntel arches? Is it still like =E2=80=98master=E2=80=99? If it is, that=E2=80=99s 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=E2=80=99d be willing to simply merge it in core-updates. I=E2=80=99d like some of us to take another look at it=E2=80= =94Ricardo, 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=E2=80=99.