IRC channel logs
2021-12-05.log
back to list of logs
<oriansj>stikonas: the binary you checked in for POSIX/riscv32/hex0-seed does not match the sources in POSIX/riscv32/hex0_riscv32.hex0 <oriansj>there is a 2byte difference in the ELF-header <stikonas>oh, that's strange, let me double check which one is correct <stikonas>stange, I've rebuilt hex0 from hex0_riscv32.hex0 and sha256sum matches <oriansj>much better to catch these things before a merge then to explain a difference later when someone else checks <stikonas>I think I've updated binary size in elf header later <stikonas>and double checked riscv64, that one seem ok <stikonas>ok, I'm running test-riscv* and then will merge into stage0-posix <stikonas>so now hex0_riscv32 is the smallest hex0 seed... <stikonas>although, maybe x86 one can be optimized further <ekaitz>but, honestly, I think stage0 is too complex <ekaitz>probably there's a reason for it <ekaitz>but from an uninformed perspective, there are too many steps and there's no explanation of why all those steps are needed <ekaitz>it's just a decision that was taken <stikonas[m]>And number of steps is also larger because stage0-posix builds more <stikonas>another reason for more steps is that we some steps are self-reproducing <stikonas>e.g. we rebuild hex0 with hex0-seed which should be identical <stikonas>and we also build "shells" (kaem-minimal and kaem) <stikonas>without all these extras, there aren't actually that many steps <stikonas>after that most of the steps kind of rebuilds all the same stuff but a bit better (from C sources and easier to debug binaries) <oriansj>ekaitz: perhaps I should be asking you what sorts of an explnation would you be wanting about the various steps? <oriansj>We found C compilers are more portable, compatible, easier to audit and simpler to build then FORTH or LISP interpreters. (The long battle to bootstrap mes.c is plenty of proof of that point) <ekaitz>oriansj: I am not advocating for forth or lisp or any other, it's just that it's hard to find reasons to your decisions (I don't mean they are not reasoned!) <stikonas>I guess plankforth would be somewhat equivalent to M0 written in hex0 <ekaitz>i mean, the decisions are surely correct, but there's no mention to the thought process and that's a little bit of a shame <oriansj>ekaitz: you mean, I haven't documented the decisions and why. That makes perfect sense <ekaitz>i'd love to have the chance to follow that thought process <oriansj>ok and where would you like that information to be placed, so that people looking for that information would be able to quickly find it <ekaitz>oriansj: I'm not sure about that. I paper is ok for me. But I'm not good at communication. <oriansj>ekaitz: How does the talk-notes directory sound to you? <oriansj>which reminds me, I probably need to add my own lightning talk to the list of previous bootstrapping talks <ekaitz>i'm not sure if they show the information i'd like to see <stikonas>might be that something like parts.rst from live-bootstrap would make sense <stikonas>so it could talk e.g. about what simple linkers hex1 adds, then extra features that hex2 has <stikonas>there is a little bit in the comments in kaem files but it's very short <stikonas>hmm, actually we already have that in README.md <ekaitz>yeah there's a high level description of the goals of each of the steps <ekaitz>but there's no reasoning about why was the project split on those steps and no others <stikonas>basically hex0 code is quite tedious to write and edit <ekaitz>anyway, that's just a feeling I have it seems <stikonas>due to the fact that it has no linking and all those jumps have to be calculated manually <stikonas>so if you e.g. insert a line somewhere in the middle <stikonas>you might have to recalculate a lot of them <stikonas>so the first goal is to fix that with as little hex0 code as possible <stikonas>hence it was decided to have a very simple hex1 linker rather than full-featured hex2 <stikonas>there is nothing preventing you from writing M0 in hex0 <stikonas>you might be able to do that in a week or so <stikonas>but the resulting file would be hard to maintain <stikonas>once you have hex1, that .hex1 code is much easier to edit but due to hex1 limitations, you can't write very big programs in it <stikonas>(primarily because hex1 only supports 1 character labels <stikonas>and then assembler (M0), cc_* compiler in assembly and C compiler in C are quite natural steps <stikonas>and after that it's just a bit of dogfooding. We rebuild basically the same tools that we have built before but from C source <stikonas>C tools also have slightly more features that we don't bother implementing in assmebly <stikonas>e.g. useful error messages, ability to read multiple files, etc... <ekaitz>stikonas: it's more or less what I deduced from the project, with effort <ekaitz>but I was more interested on how this project was developed and how were the decisions taken <ekaitz>also, if possible, comparing with other research <ekaitz>kind of a more scientific approach <ekaitz>because this project is great, but its background knowledge is also really interesting and important <ekaitz>the design decisions are interesting, not only the current architecture or implementation <oriansj>ekaitz: Well the design decisions are actually based on the most important metric: What work is someone willing to do *NOW* <oriansj>for example the reason why so much effort was put into making mes.c into something M2-Planet could build instead of building a more powerful C compiler in C capable of building TCC or GCC. Was simply because janneke and I were willing to invest the time to get MesCC working and no one else at the time was willing to put in the effort required to create an alternate. <oriansj>long term if someone is willing to put in the effort into an alternate path that produces more benefits or lower support work, then we will switch to that. <oriansj>but language fanboyism working code does not create. <ekaitz>oriansj: i hope that last sentence is not because of me :) <oriansj>ekaitz: nope, I praise every effort that might help us regardless of the reason for it. <oriansj>So if FORTh developers magically show up and save us a great deal of work, thanks we will take it. If scheme developers rain from the heavens and solve our porting problems, praise the lord. But right now C seems to be winning. <oriansj>and I encourage everyone to work on what interests them <ekaitz>oriansj: Just to clarify, all this discussion is not because of the forth thing I shared. I never coded in forth tbh <ekaitz>so that's not my point with this whole thing <oriansj>ekaitz: actually it is more of a call to people in those communities to do something awesome. <ekaitz>some of those communities are pretty close <ekaitz>i hope i can do some work on the scheme part of mes <oriansj>for example, I'd love to see someone from the scheme community pick up slow-utils (mescc-tools in scheme) and allow Guix to get a scheme only bootstrap <stikonas[m]>Yeah, it would be nice if somebody got gash running on mes too <oriansj>with a little work, guix can be reduced down to only the guile binary as its bootstrapping root <oriansj>and with work mes.c might be extended to be able to run guix or guix might be simplified enough to run on mes.c <oriansj>So countless possiblities for awesome bootstrapping results that I would love to see. <oriansj>In every language, on every platform and in countless amazing ways. <ekaitz>it explains some design considerations that was more or less what I was missing on stage0 <stikonas[m]>It doesn't go down all the way to hex but doesn't need kernel <ekaitz>oriansj: I might try to take a look into slow-utils