4 ms·

> We provide a minimal WASI interpreter implementation that is built from C source, and then used to translate the Zig self-hosted compiler source code into C c

> We provide a minimal WASI interpreter implementation that is built from C source, and then used to translate the Zig self-hosted compiler source code into C code. What do you use to compile the Zig source into C code? Wouldn't you need a Zig Compiler? I would have expected this? > We provide a minimal WASI interpreter implementation that is built from C source (i.e. so we don't need a Web Browser), then used to translate Zig Self-Hosted Compiler WASM code into C code. The Zig Self-Hosted Compiler WASM code is committed to the code base each time it changes, so when building a commit you already have the WASM source to a Zig compiler right there. > Of course, in the context of bootstrapping, this Zig Self-Hosted Compiler WASM source needed to be generated the first time at some point. For that first time, we used the C++ compiler to compile the Zig Self-Hosted Compiler from Zig into WASM.

Yujf 4y ago
The Zig compiler gets compiled to WASM. The WASI interpreter runs the WASM binary to compile Zig to C.
- randyrand 4y ago
  > The Zig compiler gets compiled to WASM This is the part I don't understand. In the context of bootstrapping, where does the Zig to WASM compiler come from?
  - Laremere 4y ago
    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.
  - defen 4y ago
    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.
    - noveltyaccount 4y ago
      Excellent tldr
    - richard_todd 4y ago
      Why not compile directly to C in step one, if you’re already presuming the presence of a zig compiler?
      - Arnavion 4y ago
        >Compile the compiler to C code - This is the approach taken by Nim, for example. >In Zig’s case, I explored this possibility, and found the generated C code to not only be target-specific, but also large. Even ignoring the large-ness, the fact that it was target-specific makes it unusable for bootstrapping new targets. The WASM blob is target-independent.
    - pas 4y ago
      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?
      - Arnavion 4y ago
        Read the "Use a prior build of the compiler" section of the article.
      - shp0ngle 4y ago
        You still want people that have no Zig to be able to get Zig compiler that existed in a specific point in time. Instead of committing binaries in all the possible architectures to the repo, you commit just WASM. That is how I understand it.
    - sebk 4y ago
      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?

Yujf 4y ago

The Zig compiler gets compiled to WASM. The WASI interpreter runs the WASM binary to compile Zig to C.

randyrand 4y ago
> The Zig compiler gets compiled to WASM This is the part I don't understand. In the context of bootstrapping, where does the Zig to WASM compiler come from?
- Laremere 4y ago
  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.
- defen 4y ago
  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.
  - noveltyaccount 4y ago
    Excellent tldr
  - richard_todd 4y ago
    Why not compile directly to C in step one, if you’re already presuming the presence of a zig compiler?
    - Arnavion 4y ago
      >Compile the compiler to C code - This is the approach taken by Nim, for example. >In Zig’s case, I explored this possibility, and found the generated C code to not only be target-specific, but also large. Even ignoring the large-ness, the fact that it was target-specific makes it unusable for bootstrapping new targets. The WASM blob is target-independent.
  - pas 4y ago
    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?
    - Arnavion 4y ago
      Read the "Use a prior build of the compiler" section of the article.
    - shp0ngle 4y ago
      You still want people that have no Zig to be able to get Zig compiler that existed in a specific point in time. Instead of committing binaries in all the possible architectures to the repo, you commit just WASM. That is how I understand it.
  - sebk 4y ago
    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?