The bootstrapping story is a little hard to follow here. I think the normal zig compiler has a C backend which was run on itself, the source cleaned up by hand then checked in. Bootstrap then means compiling that generated-then-edited C, with an ongoing obligation to update that C implementation when the language changes.
Does anyone know what the language runtime status is for zig? I think there's a libc involved somewhere. There's a standard library which is probably written in zig, did that also get compiled to C and checked in to support the generated bootstrap compiler?
This post talks about a checked in binary that was compiled from something and will periodically need to be updated. It's unclear whether that allows deletion of the C bootstrap code.
Oh, and there was a C++ implementation as well, which is no more. That does sound like a win.
Interesting. Last I recall from working with Zig the plan was to run the self-hosted compiler against itself to produce a C file that would, itself, be the bootstrap compiler. Now it looks like there's an extra step involving a WASM blob and a WASI implementation, and the only explanation I could find is in a 50 minute video with no transcript.
I'm both surprised and, at least as regards my current understanding of the situation, disappointed.
Also, one of my toy Zig projects depends on async[0] functionality not currently available in the self-hosted compiler, so I hope the add that before ditching the current stage1.
[0] I used the suspend/resume primitives to build coroutines, which are significantly simpler and easier to follow than the state machines they replaced in that code.
PS: I did some more digging in the Zig Discord channels and discovered that this is a temporary plan, and that all this WASM/WASI nonsense should ultimately be replaced by a C implementation. Still finding the reasoning for it a bit dubious though.
IDK, if you want a rock solid wasi implementation it makes a lot of sense to use it in a somewhat, but not really, critical part of the bootstrap process.
Compiling to wasi which is then translated to C (as it is more efficient than a wasm interpreter apparently) does seem like an extra, unnecessary, step but what do I know about bootstrapping a compiler.
6 comments
[ 2.8 ms ] story [ 28.2 ms ] threadDoes anyone know what the language runtime status is for zig? I think there's a libc involved somewhere. There's a standard library which is probably written in zig, did that also get compiled to C and checked in to support the generated bootstrap compiler?
This post talks about a checked in binary that was compiled from something and will periodically need to be updated. It's unclear whether that allows deletion of the C bootstrap code.
Oh, and there was a C++ implementation as well, which is no more. That does sound like a win.
This didn’t ever happen, but may happen in the future. The usage of the WASI blob is a temporary alternative.
AFAIK there will be a forthcoming blog post that’ll clear things up.
I'm both surprised and, at least as regards my current understanding of the situation, disappointed.
Also, one of my toy Zig projects depends on async[0] functionality not currently available in the self-hosted compiler, so I hope the add that before ditching the current stage1.
[0] I used the suspend/resume primitives to build coroutines, which are significantly simpler and easier to follow than the state machines they replaced in that code.
PS: I did some more digging in the Zig Discord channels and discovered that this is a temporary plan, and that all this WASM/WASI nonsense should ultimately be replaced by a C implementation. Still finding the reasoning for it a bit dubious though.
Compiling to wasi which is then translated to C (as it is more efficient than a wasm interpreter apparently) does seem like an extra, unnecessary, step but what do I know about bootstrapping a compiler.