<oriansj>fossy: guile can also be used inplace of mes.c (which enables even faster running of MesCC) <fossy>oriansj: but to reduce the seeds mes would be smaller ***ng0_ is now known as ng0
<oriansj>also no need for busybox at all with gash <fossy>oriansj: oh yes, I plan to refractor the early stages with mescc tools seed, mes-m2 and gash once mes-m2 can run mescv <oriansj>That is why mes-m2 is taking so long; it needs work to become a drop in replacement for guile <oriansj>fossy: also if you write your steps in kaem.run format, it can be included in mescc-tools-seed and thus leveraged by all distros that wish to leverage it <fossy>oriansj: whats mescc-tools-seed <fossy>whats the goal of mescc tools seed <fossy>ie, is it meant to be able to bootstrap up to mescc, or all the way to a GCC 9 triplet? <oriansj>fossy: mescc-tools-seed is just a repo that brings together all of the pieces needed to bootstrap gcc from hex0 into a single place <oriansj>It leverages git modules to include exact commits of the source repos to ensure always working bootstraps <fossy>OK, ill work within kaem.run then <fossy>how will the sources for later parts of the bootstrap work, with GCC and the like? <fossy>will that also be git modules <oriansj>So that scripts have relative paths that will always exist in a known good state <fossy>so using savannah.gnu.org I assume <fossy>oriansj: wheres mes-m2 up to, is there a blocker at the moment or something? <oriansj>fossy: the blocker is I still need to figure out a good test for guile modules that is correct. (then I'll hit my next blocker) <oriansj>Full guile compatiblity is something that mes.c didn't have <oriansj>So by forcing myself to do it the correct way, will reduce work in the long term but also requires alot more upfront work *fossy research guile modules <oriansj>which is why I keep saying leverage guile for MesCC; so that when I finally get done, it is a trivial change (replace guile with mes-m2) and boom completely done <oriansj>it not only solves the gcc bootstrap but also the guile bootstrap problem <fossy>is there any reason to leverage mes instead of guile right now, if its only for mescc <fossy>because afaict mes is smaller then guile <oriansj>but right now the guix bootstrap seed will still be cut by 50% when it reduces down to just guile <oriansj>Then the focus becomes making mes-m2 guile compatible and everyone can pull in the same direction at the end <fossy>now on a slightly different topic, how is architecture support going in the early stages (stage0, m2-planet, cc_*, mes-m2)? <oriansj>right now all of the steps up to mes-m2 are done for x86, AMD64 and knight but armv7l still needs the early stages implemented (but mescc-tools, M2-Planet and mes-m2 work out of the box on armv7l right now) <oriansj>dddddd: is currently doing a port of M2-Planet too AArch64, mescc-tools already has a working port to AArch64 and mes-m2 should work without issue when done <fossy>because mes-m2 is architecture independent right <oriansj>as is M2-Planet and mescc-tools; correct <fossy>since mescc-tools-seed is for everything up to GCC why is it called mescc-tools-seed <oriansj>because it is a single "seed" repo needed in bootstrapping; the mescc-tools bit is entirely because it was just for bootstrapping mescc-tools only (originally) <oriansj>to the question of the cc_*; well that bit is 100% host specific and needs to be written from scratch on each new host architecture (fortunately it can be done in just a day of work) <oriansj>stage0 is the end game, bootstrap from hardware (no firmware, microcode or bios) and build a posix and everything else required. <fossy>for things past GCC like Java, is there any compelling reason to write bootstrap scripts in kaem rather than shell, which by that point you have? <oriansj>fossy: nope, as after that point bash and make and the rest are readily available <fossy>we don't have make and the like for GCC 4.7 and GCC 9 <NieDzejkob>or I think there's tcc somewhere in the mix? Can't recall <fossy>tcc should be able to compile it <janneke>make is one of the first programs we build after tcc <fossy>janneke: but you build tcc without make because its simple enough for that? <oriansj>and make only needs a shell like bash (but gash can do that job) <janneke>in fact, make is one of the few tools we do not have a gash/guile implementation of <janneke>fossy: well...it depends on how you look at it <janneke>we must build it without make, because we do not have make yet <oriansj>we do alot of ugly things but we can always clean them up later <janneke>i really want to get rid of gcc-2.95.3 some time, but first things first <oriansj>NieDzejkob: it is the first GCC being built from TCC <fossy>oriansj: about mescc-tools-seed, once mes m2 is guile compatible whats the purpose of kaem past mes m2 if we can use gash <fossy>why don't you skip to GCC 4.7.4 janneke <janneke>fossy: i will, when someone makes that work <oriansj>fossy: all kaem scripts are bash (gash) scripts <fossy>dosent it work at the moment <oriansj>fossy: you can run kaem scripts with bash <janneke>fossy: the real reason is that bootstrapping gcc-2.95 is *much* easier than bootstrapping gcc-4.x <janneke>think glibc, binutils, coreutils requirements, etc. <oriansj>NieDzejkob: Knight architecture predates Lisp machines by over 20 years <janneke>so, for the short term (ahum) we chose the simplest route <fossy>oriansj: so would it be fesible to leverage non kaem features post mes m2 since we have gash <janneke>now that works, we are filling in the gaps and work to create the most maintainable and auditable route <NieDzejkob>I'm kinda considering literate programming as a way to make auditability easy <fossy>then we can do things like have a centralized script post mes m2 rather then a per architecture script <oriansj>fossy: well we can run guix directly from source <oriansj>if we make mes-m2 a guile drop in compatible <fossy>oriansj: of course, im talking like outside guix <fossy>like with mescc tools seed and my current project to script all that up <oriansj>fossy: yep, it certainly would be possible <oriansj>plus we are aiming at expanding MesCC to be able to build GCC, binutils, coreutils, etc directly; but such an effort will be a major task and take a good bit of time. (at which point MesCC becomes a major competitor to Clang and GCC) <NieDzejkob>wait, isn't most of a compiler just optimizations? <NieDzejkob>or does GCC use some C extensions that are *that* hard to implement? <NieDzejkob>I would've thought they'd stay with standard C for comparibility <oriansj>NieDzejkob: all C compilers add extensions to the C language (they are obvious) <oriansj>but yes you are correct in most of the work in most compilers becomes incorporating optimizations and porting <NieDzejkob>are optimizations actually necessary to build GCC (say, because the performance is abysmal otherwise)? <oriansj>NieDzejkob: well; some code only works when you do tail call elimination but I can't say for specific is GCC is one of those programs <oriansj>hmmm, I might need to add support for keywords into mes-m2 before I add proper modules