RE: bootstrap integration strategies

["Orians, Jeremiah (DTMB)" <OriansJ@michigan.gov>]

> Sounds nice.  I wonder if Jan was referring to something else then?
Probably alternate operating systems like Hurd is my guess but I'm probably wrong.

> There’s still the question of GNU/Hurd, though, which requires a vastly different libc.
Fortunately Janneke has done a good job making that selectable

> So far the initial ports of Guix to non-x86 were done through
> cross-compilation (info "(guix) Porting").  So in a way, the binary
> seeds for these platforms were built from source; we just “cut” the
> source-to-binary connection by making those binaries the root of the
> dependency graph on these platforms.
Thank you for clarifying

> Maybe that’s something we’ll have to live with on new architectures.
Unless you want to make qemu a root dependency

> So, problem solved?  Or am I missing something? :-)
Mescc-tools can build valid binaries for all instruction sets with sane immediate representations (RISC-V is the only exception here; hopefully they fix that)
But Definition files need to be written and tests generated

> I think the ‘wip-bootstrap’ branch does not use M1 at this point, does it?
M1 and Hex2 are core pieces of mescc-tools and are required for MesCC to produce binaries.
As MesCC outputs M1-macro files (the .S files)

> I wonder what it would take to fix that.  After all, compiling libguile
> must not be much harder than compiling tcc, no?
Janneke know far better than me on this one

> One thing at a time.  :-)
But this is lots of fun :D

> 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
Ok, how does this sound:
We walk the bootstrap binaries towards MesCC (This will add more bootstrap binaries in the short term)
Then we eliminate them one at a time until guile and mescc-tools are the only binaries that remain
Mescc is a scheme program which is interpreted by either guile or mes.c and thus could leverage guile until mes.c is in a state that it can replace guile for : guix, mescc and GASH
Thus the making of the bootstrap binaries can follow 2 possible paths:
1) Fast via standard C compilers: just build mes.c and mescc-tools and be done
2) Platform specific Stage0, which starts with hex0 (`200B) -> hex1 (~500B) -> hex2 (`1KB) -> M0 (~2KB)  -> [Everything here on is platform neutral] ->M2-Planet (~16KB) -> mes.c + mescc-tools (M1 and Hex2)

The best part is all of the binary seeds of all of the platforms will be able to build the binary seeds for all of the other platforms with bit for bit identical results (Which eliminates hardware based Trusting Trust attacks avoiding detection)

Jeremiah Orians
Cell phone: (517) 896-2948