IRC channel logs

2019-12-09.log

back to list of logs

<oriansj>theruran: thank you for spotting that
<oriansj>when built with M2-Planet (+ blood-elf debug info) it is 153,348bytes but gcc -Os it weighs in at 71,128 bytes
<theruran>oh, right on. I didn't try with -Os
<theruran>no smaller
<oriansj>theruran: fortunately not a big concern at this point, especially since we can fit M2-Planet, Mes-m2 and mescc-tools on a floppy disk with alot of room to spare (hopefully enough for a full posix written in M2-Planet)
<theruran>oriansj: true. it's just one metric for comparison. CompCert and musl at least give some assurance that mes-m2 doesn't rely on any undefined behavior
<oriansj>theruran: very true, but you are forgetting about 1 C compiler which is quite different from Clang, Gcc, Tcc and leverages an entirely different libc (M2-Planet)
<theruran>oriansj: I didn't know M2-Planet implements its own libc
<theruran>well, there's functions/ but I figured those just overrided some libc functions
<oriansj>theruran: it is probably the smallest Libc on the planet: https://github.com/oriansj/M2-Planet/blob/master/test/common_amd64/libc-core.M1
<theruran>whoa!
<oriansj>why do you think when it builds itself, it also needs: https://github.com/oriansj/M2-Planet/blob/master/test/common_amd64/functions/exit.c ?
<oriansj>M2-Planet is entirely self-contained
<theruran>hadn't thought about it. I guess I just wanted to test that to see if it worked. I haven't looked at M2-Planet much yet.
<oriansj>and can be built entirely by an assembly version of itself (cc_amd64/cc_x86/etc)
<theruran>so I should try stress-testing it?
<oriansj>if you would like
<oriansj>currently it is in reasonable shape in regards to generally correct behavior: https://github.com/oriansj/mescc-tools-seed
<oriansj>it was fun building a C compiler in assembly. Doing Mes-M2 in assembly would be a nightmare
<theruran>well I'll keep poking at things.
<oriansj>theruran: enjoy yourself ^_^
<oriansj>xentrac: So something of the class of M0, in which case only line macros exist and that is because they make the assembler smaller than manually encoding the supported instructions (Which is what one needs to do for the more advanced macro forms)
<xentrac>why would Mes-M2 be so much more difficult than a C compiler to do in assembly?
<xentrac>oriansj: I'm not sure I understand what you're driving at. you're saying you could do an assembler that supports macros but no macros, labels, or even relative addressing?
<xentrac>or are you saying that M0 is the step after hex0, where hex0 supports no macros, and M0 does support macros, and therefore can do the other things?
<xentrac>btw you might find it more pleasant to read notes/assembler-bootstrapping.html in a built Dercuano rather than markdown/assembler-bootstrapping in the source repo
<xentrac>I'm writing https://gitlab.com/kragen/dercuano/blob/master/markdown/forth-assembling right now
<zig>forth bootstrapping is back?
<zig>This night, I made a strange dream where I was flying a spaceship running my own scheme code.
<xentrac>I'm not convinced that Forth bootstrapping is a good idea
<zig>why? I read forth bootstrapping effort were abandonned, but I don't know why.
<xentrac>I'm exploring it because it's a fun kind of thing to think about. But it just took me an hour to get a 10-line "assembler" (that mostly just converts octal to binary) working in Gforth
<xentrac>a big chunk of that time was because I had a stack-effect bug
<xentrac>I don't have a clear idea of why I have a harder time getting things done in Forth than I do in C or assembly language. In theory it doesn't seem like it should be that way
<xentrac>Maybe it's lack of experience, I don't know
<xentrac>(I just updated the note I linked above with details on that)
<xentrac>in theory, Forth should be purely an improvement over C: less syntactic overhead for factoring into smaller functions, built-in closures, compile-time metaprogramming and whatnot
<xentrac>well. Sort of closuers
<xentrac>but I haven't figured out how to make those theoretical advantages real
<xentrac>by contrast, the lack of type-checking and the danger of stack imbaances seem to cost me a fair bit of time in practice. But I'm still a beginner in Forth after 25 years
<xentrac>I've probably written about two orders of magnitude more C than Forth, but I've written a few thousand lines in different Forths and in different assembly languages
<dddddd>Hello booters
<xentrac>hey
<dddddd>I'd like to explore the forth route too. I'll keep an eye on your progress, xentrac.
<dddddd>Nice dream, zig (:
<zig>dddddd: (:
<xentrac>it does sound like an awesome dream!
<zig>lobste.rs (a news site) is full of web assembly articles, I am wondering what are the challenges or opportunities for the bootstrappable community, given the recent recommendation of wasm by w3c.
<dddddd>relative addressing enters the picture en hex2, AFAIU
<dddddd>*in
<xentrac>dddddd: have you looked at https://github.com/kragen/stoneknifeforth?
<xentrac>wasm is really interesting but I haven't played with it at all
<dddddd>maybe in hex1, if that's a thing still.
<dddddd>No, I haven't, xentrac.
<xentrac>it's a bootstrapping Forth I wrote a while back
<dddddd>What's its license?
<dddddd>bicicleta, cuaderno; do you speak spanish?
<xentrac>public domain (cc0)
<xentrac>yeah, although not as well as I speak English
<xentrac>yesterday I was asking my girlfriend if people really called tablecloths "carpetas"
<vagrantc>xwvvvvwx, janneke: thoughts on how to go about writing up a press release regarding the cross-distro mes bit-for-bit identical builds?
<oriansj>xentrac: are you really asking why would it be harder to write a 3+Kloc scheme interpreter than a 2Kloc C compiler? well let us start with the obvious it is always harder to write an interpreter in assembly than a compiler. Compilers allow for natural isolation and a single token list to be walked (allowing testing starting from function zero). Interpreters tend to be highly interdependent on all functions (thus making them hard to
<oriansj>debug) and tend to be untestable until core functionality is implemented.
<dddddd>xentrac, I don't see the license in the repo, sorry.
<oriansj>xentrac: the point I was driving at was that line macros are much much simpler than regular macros and regular macros require alot for infrastructure in the assembler before they can be implemented. One can do line macros with s/foo/0123/g in sed but proper regular macros require an actual programmable state machine.
<oriansj>xentrac: also M0 doesn't even need to support labels or displacements or addresses; as that functionality is in the hex2_linker; Otherwise M0 would have been much much bigger
<oriansj>zig: it never left but no one seriously wants to do that work. also a scheme spaceship sounds like a blast from the past (lookup JPL lisp)
<xentrac>oriansj: yes, I was really asking that! what's obvious to you isn't always obvious to me :)
<xentrac>dddddd: https://github.com/kragen/stoneknifeforth/blob/master/LICENSE.md
<zig>oriansj: what do you mean by "it never left" I do not understand, sorry.
<oriansj>zig: we never got rid of the FORTH work that we did in stage0, so it is always there; waiting for someone to start working on it
<oriansj>xentrac: if you read https://github.com/oriansj/mescc-tools/blob/master/examples/M0-macro.c you'll understand the minimal basis of assemblers
<oriansj>zig: we can even provide guides for usage/development for those wishing to pursue that line of development
<janneke>vagrantc, civodul: i think for the cross distro mes press release iwbn to have some way to edit several iterations; what about opening a bug in guix or debian or is that too public?
<oriansj>janneke: always could do a git repo
<civodul>janneke: yeah, a Git repo would be nice, or an issue in one of our tracker, or plain email, i guess
<janneke>ah, if guix is going to publish it as a blog post, and others publish it identically, we could maybe work in guix-artwork?
<civodul>sure, that'd work
<oriansj>(encrypted git repos are a thing after all)
<civodul>i guess we first need to check whether/how NixOS and Debian (and Arch?) would publish such things
<janneke>yes!
<vagrantc>janneke: alternately/additionally, i was thinking it would be relevent as a NEWs item for reproducible-builds.org
<janneke>sure!
<civodul>+1
<vagrantc>don't have much experience with such things, but ... i'll poke at it :)
<janneke>where does arch ("jelle" ?) hang out?
<civodul> https://nixos.org/ has a news section
<civodul>janneke: jelle is on #reproducible-builds
<vagrantc>love mes-rb5 ... (throw 'error "mes checksum failure") :)
<civodul>oh and xwvvvvwx is here, hi! :-)
<xentrac>oriansj: thanks! hey, is that a buffer overflow in store_atom? also, won't it loop infinitely if the file ends in the middle of the atom?
<xentrac>and likewise in store_string
<janneke>vagrantc: glad you like it :)
<xentrac>well I guess loop until it crashes because sooner or later storing -1 off the end of the buffer is going to break things
<dddddd>Thanks for the new file, xentrac.
<xentrac>yeah, I didn't realize I'd forgotten to add that --- thanks for the reminder
<dddddd>my pleasure
<dddddd>¡oh! Argentina, ya veo (:
<xentrac>claro :)
<bmwiedemann>Hi, when I wrote https://etherpad.opensuse.org/p/reproduciblebuilds-goal it became really obvious why bootstrappable builds are so related. Not just because it requires reproducibility in some places, but also because the goal is pretty much the same.
<bmwiedemann>(with some extra side-benefits like facilitating bootstrapping a new architecture like RISCV or aarch64)
<bmwiedemann>janneke: oriansj: ^
<civodul>hello bmwiedemann, good to see you here! :-)
<bmwiedemann>had to pay you a visit :-)
<civodul>the way i see it, "reproducible builds" apply when you actually have source code to build, and that's where bootstrapping comes in: it's about building everything from source
<bmwiedemann>btw, when you write your PR about Mes bootstrapping, you can also mention the prior work of https://github.com/bmwiedemann/ddcpoc (that was only partially reproducible cross-distro because it used libc and .h files from the host)
<janneke>bmwiedemann: welcome!
*janneke goes to read the etherpads
<civodul>bmwiedemann: nice!
<bmwiedemann>civodul: yes, that is one of the differences, but the goal is still the same
<janneke>bmwiedemann: ah thanks for that pointer!
<janneke>i think we should really mention that previous effort
<janneke>back then, we could not really *use* the nice result
<janneke>the difference today is that we have actually bootstrapped guix from it (or from a very similar mes, tbh)
<bmwiedemann>got to fetch my Kids from Kindergarten. read you tomorrow.
<janneke>bmwiedemann: have fun, good to see you here!
<hannes>hi
<civodul>howdy hannes!
<civodul>good to see you here :-)
<vagrantc>so far i've got this for soem starter text regarding the cross-distro mes news https://salsa.debian.org/reproducible-builds/reproducible-website/blob/master/_posts/2019-12-XX-reproducible-bootstrap-of-mes-c-compiler.md
<janneke>hi hannes, welcome!
<civodul>vagrantc: neat!
<civodul>BTW janneke, what's the right spelling: "Mes" or "MES"?
<civodul>i think you use the former, but viewing it as an acronym, the latter also makes sense
<vagrantc>yeah
<janneke>hmm, i have been using "Mes" which i like somewhat better, but "MES" could me more correct?
*vagrantc isn't partial either way, but happy to have it decided :)
<janneke>vagrantc: i think you just missed bmwiedemann here, pointing to https://github.com/bmwiedemann/ddcpoc
<janneke>the previous cross-distro dcc of tinycc -- but at the time we lacked the "GNU Guix is bootstrapped from this seed" part of the story -- which is kind of important :-)
<janneke>i think it would be good to mention this previous attempt (and possibly what's different now, although you say that very nicely in your draft/suggestion)
<vagrantc>agreed
***ng0_ is now known as ng0
*janneke just found why the mes-0.19 built mes-0.21-32 (yes it worked!) has the wrong magic number
<janneke>the .s files are identical, the .o files are different -- using the old 0.5.2 mescc tools toolchain
*janneke starts to warm up to `MES'
<dddddd>Talking about RISC-V, I'd like to add support to M2-Planet for it, after cleaning up the AArch64 patches.
<janneke>dddddd: sweet!
<dddddd>I guess I can use the same tricks, to avoid the complexity of the machine instructions.
<vagrantc>there's an aarch64 implementation? :)
<dddddd>yes, all test passing. Not published yet but oriansj has a copy of the drafts, just in case (;
<civodul>woow, neat
<janneke>bah, my mescc-tools 0.5.2 build patch for mes (on wip) is not nice or finished
<vagrantc>why stick with such an old mescc-tools version?
<janneke>vagrantc: civodul had an idea: we might get away with not updating any binary seeds while integrating the scheme-only bootstrap
<janneke>until now, i used/prototyped with mes-0.21 and mescc-tools 0.6.1
<janneke>that works, but it would require updating the binary seeds in guix
<janneke>that's not a pleasant process and we are looking if we can avoid that
<janneke>this is another thing we found, that may add to the sanity of updating the binary seeds after all
<civodul>ah, we lost vagrantc
<civodul>janneke: again, if sticking with the old version turns out to be painful, it's fine to switch
<janneke>civodul: thank you
*janneke may reevaluate their pain level calibrations