From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Nieuwenhuizen Subject: Re: bootstrap integration strategies Date: Thu, 12 Jul 2018 19:40:38 +0200 Message-ID: <87a7qwjqsp.fsf@gnu.org> References: <874lh4toq8.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]:50239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fdfaL-0007vF-Cq for guix-devel@gnu.org; Thu, 12 Jul 2018 13:40:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fdfaJ-0008Kp-T3 for guix-devel@gnu.org; Thu, 12 Jul 2018 13:40:57 -0400 In-Reply-To: <874lh4toq8.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 12 Jul 2018 18:15:11 +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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: "guix-devel@gnu.org" , "Orians, Jeremiah (DTMB)" 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 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=E2=80=99s 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 =E2=80=98wip-bootstrap=E2=80=99 branch does not use M1 at thi= s 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=E2= =80=99s > 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 --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com