IRC channel logs
2026-05-09.log
back to list of logs
<siraben>I'm finally writing the C compiler in Blynn-dialect Haskell thanks to Codex <siraben>I got a blynn-dialect compiler working to bootstrap TCC! <siraben>the tcc self-hosts. compiling gcc 4.6 now to see if it works, then lots of cleanup <matrix_bridge><wildwestrom> siraben That's cool you can bootstrap TCC, but what bootstraps blynn? <matrix_bridge><wildwestrom> Ah I see, so it could potentially replace mes and mescc. Just trying to understand where it fits. <siraben>ok great, I got it to compile gcc4.6. Going to do up to gcc15 in the background <siraben>I'm going to work on simplifying it and auditing the source <janus>siraben: is there a Blynn-dialect Haskell compiler in C too? <roconnor>I was planning to start a project that does exactly that. :) <roconnor>Okay I need to go through Orians' and siraben's bootstrap. siraben is it available? <stikonas>roconnor: do we need that old bootstrap anymore? <stikonas>it was added before we had a path from M2-Planet to mescc <stikonas>I think at some point siraben wanted to use it as intermediate stage M2-Planet -> blynn-compiler -> some future scheme interpreter in haskell -> mes <stikonas>so you can just start with more powerfull C compiler <stikonas>M2-Planet -> blynn-compiler -> some future scheme interpreter in haskell -> mes also run very slowly <roconnor><siraben> I got a blynn-dialect compiler working to bootstrap TCC! <roconnor>AFAIU it is now possible to go from M2-Planet -> blynn-compiler -> TCC. <roconnor>My personal motivations are a little different from #bootstrappable. I'm imagining a bootstrapped toolchain of formally verified code, and IMHO this is best done by getting into FP via combinator programmings as early as possible in the bootstrap. <roconnor>Which is why I'm so excitted to learn about this. <roconnor>Whether #bootstrappable cares is another story. Depends on how much you hate MES I guess. :) <roconnor>I kinda want to move it earlier and start from M0 -> blynn-compiler, so that could be something fun to try out. <matrix_bridge><Jeremiah Orians> The first couple steps of blynn bootstrapping requires a C compiler but it definitely is possible to change blynn to output M0 for those steps but it would take a bit of work <roconnor>Yeah. I need to figure out how the current system works first before tinkering with it. <siraben>some parts had to be written in C, like the preprocessor, but this was mostly for debugging purposes because m2-planet is quite slow <siraben>roconnor: also I just rejoined IRC (properly with a bouncer now) for the first time in years and started this project like last week, so I have just as much context as you :P <janus>roconnor: what is the advantage of bootstrapping with Ben Lynn instead of the MicroHS compiled with the Hugs-fork ? is it that Ben Lynn is more pedagogical? <janus>i think that Ben Lynn's compiler supports less extensions than MicroHS, so it seems like each approach has unique advantages? <roconnor>Part of my attempt to drive C out of the entire software ecosystem. My proposal is inadequate by itself, but it is a start. <roconnor>I think Ben's compiler could be bootstrapped from assembly. <janus>roconnor: do you know the differences between Ben Lynn's supported haskell subset, and the subset supported by the Hugs-fork that we know compiles the old MicroHS? <janus>roconnor: i wonder whether i should spend time on setting up a CI suite to keep Lennart honest about his promises about bootstrappability using Hugs. Because I am 90% he is not guarnateeing that it keeps working <janus>roconnor: do you think that would be valuable? <roconnor>Yeah, I think so. I should maybe see if I can build Hugs with TCC to build MicroHS. <janus>this is fairly recent (nov 2025) <janus>i just get so discouraged reading this... what's the point when Lennart is just going to break it later... <roconnor>I think Lennart is reasonably committed to maintaining the Hugs bootstrap. And also we have the opportunity too keep the recorded history of MicroHS, so we can, presulably, always bootstrap newer versions of MicroHS from older ones. <aggi>"drive C out of the entire software ecosystem" <aggi>i guess alot of firmware is written in C anyway, even when that's hidden inside firmware blobs outside reach of bootstrappable.org <aggi>covering platform initialization of coreboot/seabios with bootstrappable seems not feasible <aggi>another aspect, since transfer of sources and hex seeds onto bootable medium was considered problematic too <aggi>the largest SPI flash rom chip i've got here is 8MiB (64mbit) <aggi>current live-bootstrap source size is way beyond orders of magnitude to ship that is coreboot payload flashed into some ROM <roconnor>I need to build the blynn-compiler first. <siraben>- `precisely_up` is built from the Blynn bootstrap chain, including a stage0/M2-Planet path. <siraben>- `hcc` is split into `hcpp`, `hcc1`, and `hcc-m1`. `hcpp` preprocesses C, `hcc1` lowers preprocessed C to M1 IR, and `hcc-m1` writes M1 assembly for the stage0 `M1`/`hex2` tools. <siraben>- `tinycc.m2.precisely.m2` builds TinyCC through the stage0-built `precisely_up` and HCC path. <siraben>- `gcc46.m2.precisely.m2` has built successfully from the HCC-built TinyCC. <siraben>janus: is the microhs project bootstrapped correctly? don't they rely on a blob (the combinator blob) <roconnor>siraben: what prompted this work of yours? <siraben>I contribute a lot to Nixpkgs and have been using coding agents more extensively, so it seems like a natural fit for long-horizon tasks <siraben>Package maintenance is full of boring but easily verifiable work that no one wants to do <siraben>like measuring various configure flags in the minimal-bootstrap to see what combination is fastest <janus>that answers your question "is the microhs project bootstrapped correctly"