This is a method of ensuring that future builds do not depend on the existence of a Zig compiler; it's not a way to go from 0 to Zig without a Zig compiler ever having existed. Technically this already existed in the form of a Zig compiler written in C++; the point of this exercise was to stop using C++.
So:
Presume the existence of a compiler that can compile Zig. Use that compiler to compile the written-in-Zig Zig compiler to WASM. Now you have a big chunk of WASM, so you also need a WASI interpreter. Write that in 4,000 lines of highly portable C. Then use that WASI interpreter to run your big chunk of WASM code and give it your written-in-Zig Zig compiler, and tell it to output C. Then compile that C code with your system compiler, and then use that native executable to recompile the written-in-Zig Zig compiler. At this point you should be at a fixed point and further recompilations of the Zig compiler will yield the same binary.
Thank you for the summary. It's very helpful for people like me whose only experience with compilers is a class in college.
I'm slightly confused by these two statements together: This is a method of ensuring that future builds do not depend on the existence of a Zig compiler and Presume the existence of a compiler that can compile Zig. Does that mean that future builds do not depend on having a Zig compiler at hand, rather than the existence of it?
I'm having trouble not visualizing this as basically a subcategory of the second solution explored in the solution space section, "Use a prior build of the compiler". Isn't that, effectively, what this ends up being? except with an added VM abstraction encapsulating the platform-specific portions of the compiler. I don't quite get why the same thing can't abstracted in a library; if there's no existing compiler for riscv64 (like in the example), you'd write another implementation of that library, or you'd update your wasm2c / WASI interpreter to support riscv64.
is there value in additional stages where the output zig3 compiler is used to compile the written-in-Zig Zig compiler to WASM again (since previously it was obtained in binary form from the repo), and follow the steps again? Presumably you'd end up with a zig binary that is equivalent bit-for-bit with zig3, correct? But does it help strengthen the chain of trust in the commited wasm binary?
> Presume the existence of a compiler that can compile Zig.
I just mean that the original WASM blob needed a working Zig compiler to produce it. But you can just assume it fell from the heavens. Now that it exists, you no longer need a Zig compiler binary in order to build a Zig compiler.
One way to think of it is that this allows the automatic creation of "stage 1" compilers from Zig compiler source. "Stage 1" was Zig's term for the original written-in-C++ Zig compiler, but I'm just using it to mean "A Zig compiler that does not need Zig".
To give a concrete example - say you want to add a new keyword gofast that makes all your loops go twice as fast. The first step would be to implement that in the written-in-Zig Zig compiler, without using the gofast keyword in your source. Once that's done, you compile your compiler. Then you update your compiler source code to use the new gofast keyword and recompile it again. But now you have a problem - how is someone going to build the new compiler from source if their build of the Zig compiler doesn't already support gofast? They would have to check out the commit (that their existing compiler supports) which adds gofast support but doesn't use it. Build that, then update and build again.
So, the alternative to that is that you update the "stage1" compiler which does not depend on Zig. But no one wants to update a crusty old C++ codebase. So instead, someone who has a gofast-enabled compiler compiles that source code down to WASI, and then anyone can bootstrap from there following the procedure we already discussed.
> Then you update your compiler source code to use the new gofast keyword and recompile it again. But now you have a problem - how is someone going to build the new compiler from source if their build of the Zig compiler doesn't already support gofast?
Thank you, this is what made me understand the core issue at hand here. I was confused as to why they needed to keep updating the "old" compiler once they had written the self-hosted one.
what's the practical benefit? if there's already a self-hosted Zig to binary compiler, why not delete the C++ code and call it a day? if suddenly some to bootstrap Zig checkout the old commit, and done.
I assume the Zig to WASM compiler and WASI were already a thing anyway, right? So instead of safekeeping the old commit now they can opt to keep this generated WASM code?
WASM is platform agnostic, so it is one of the things you start with, along with the compiler source code. It is built on a different computer before the bootstrapping process begins.
