IRC channel logs
2022-12-09.log
back to list of logs
<stikonas[m]>And again people post stuff without fact checking... "and every modern distro relies on some bootstrap binary for C compilers anyway" <oriansj>"which attempts to bootstrap from just a very small hex interpreter" shakes fist at <.< <oriansj>3) we freaking bootstrapped GCC from that very small hex assember <oriansj>scratch 4 as this is probably needlessly rude <xd1le>yeah HN comments about bootstrappability is painful to read <alethkit>Greetings. With the new changes to Zig, what would an external dev need to do in order to restore O(1) bootstrapping? I'm trying to figure out if it's possible to purge C from the bootstrap chain <alethkit>I know camlboot and a 4K VM for gambit scheme exist, but not much else <alethkit>(For my purposes, bootstrapping from x86-64 UEFI is enough, since everything else is probably being cross-compiled for now, anyway) <alethkit>(For the sake of clarity, I'm not counting M!_ <oriansj>alethkit: well if you wanted O(1) bootstrapping for zig and didn't want to use any C family code (which would mean not using the existing c++ code base); then you'll effectively have to implement the Zig language in a higher level language such as haskell, ocaml, scheme, common lisp or something of that sort <alethkit>Given that camlboot and scheme exist, those would be my two main options <alethkit>particularly OCaml, seeing as 5.0 is the first mainstream language that's pure without monads <oriansj>it'll be a chunk of work but you'll only have to implement the subset of the features that they actually use (and depend upon) in their compiler <alethkit>where would it fit in with your stages? stage2? <drakonis>with it being self hosted, odds are that it uses a large amount of language features <oriansj>drakonis: but we don't know the percentage until someone actually checks <oriansj>alethkit: odds are the zig bootstrap would probably fit right after the guix bootstrap <oriansj>which would give you a great deal of tooling, libraries and anything else that helps to speed up your work. <drakonis>and zig can be used to compile any c/c++ code <drakonis>last i checked, it could compile erlang and pass all tests <oriansj>drakonis: but no C compiler can compile any c/c++ code; the inline assembly bits alone would invalidate that statement <oriansj>which is a subset of *ANY* C and mostly overlaps with GCC <alethkit>Out of curiosity, what are the issues with using that for a bootstrap? <drakonis>i'm not sure if the new compiler without llvm underneath it still has access to the c/c++ compiler built into it <drakonis>it probably still has it given that the patch notes didnt mention anything removing it <alethkit>Franciman: I was also thinking of using Scheme (In particular, the 4K VM from Gambit Scheme), but OCaml 5.0 might also be an alternative <alethkit>It has a release candidate, and camlboot exists <alethkit>and more importantly, it has algebraic effects <alethkit>which allow for a lot more concision in code <alethkit>As a bonus bonus point, I think there's someone working on making an interactive theorem prover with 5.0, so you could (in theory) get a proof certified bootstrap chain <alethkit>I guess we need to actually find out what to implement <alethkit>drakonis: Do you know if zig supports tail call optimisation? <alethkit>I assume converting all control flow to that would make our lives easier <drakonis>a cursory look into the documentation mentions tail call optimizations and the ability to prevent them <drakonis>lets you control whether it is a tail call or not <alethkit>Oh, we can just declare it a compile error <alethkit>If one is allowed to "cheat" by commiting a WASM blob to source, one is also allowed to "cheat" by declaring anything they don't like to be a compiler error <drakonis>the wasm blob will only go away once there's a reasonable replacement for it <drakonis>i'm looking forward to seeing zig's spec and what comes out of it <drakonis>got removed since there's no support for it yet <alethkit>drakonis: I mean, for now, it's only an experiment <alethkit>Having an alternate implementation for bootstrapping might also be directly helpful <alethkit>And more importantly, the specification allows for tail call failures to be declared compiler errors <stikonas>camlboot only targets specific version of ocaml, doesn't it? <stikonas>and moving to new versions of ocaml might require building from unreleased git snapshots <alethkit>andrewrk: The logs will probably clear up what I meant <alethkit>drakonis: I just checked, and it turns out Zig is only able to compile C/C++ code when Clang is present <alethkit>However, if you can get away with rewriting the bootstrap in zig... <Irvise_>alethkit: yup, it is a very cool Scheme! Sadly, it seems that it needs a binary blob to compile itself :( <Irvise_>However it is ver cool that i can compile itself in its own "OS" :D <alethkit>Irvise_: Considering that it's a Scheme, it might be possible to just write raw assembly to compile it? <Irvise_>It is a fairly advance Scheme... It is a compiler too and it can write drivers/low level binaries... <Irvise_>Theoretically everything can be, but... <alethkit>and hopefully one can jump to a custom version of camlboot <alethkit>but you definitely need to do some trickery <stikonas>alethkit: you can't use SectorLISP for bootstrapping <theruran>alethkit: I am also interested in cutting C out of the bootstrap path, toward a Scheme most likely