Oh wow I had no idea this was just casually sitting on HN front page while I was streaming live coding of adding this to the Zig compiler! Here's the recording: https://vimeo.com/673819867
I see WalterBright down there in the comments. Hi! His talk at Handmade Seattle about adding a C compiler to D was amusing and informative: https://media.handmade-seattle.com/importc/
Some interesting differences between the two approaches:
* D ImportC relies on an external preprocessor, while Aro does preprocessing.
It's been really exciting watching Vexu and ehaas (and other contributors) working on Aro.
Looks like there's some confusion as to why this exists when Zig already uses libclang to compile C code. The main reasons are:
* Improved `@cImport`/translate-c functionality, especially with regards to translation of macros. Vexu and ehaas are the main contributors of Zig's C translation implementation.
* Ability to bootstrap a lean Zig binary that does not depend on LLVM, and yet is still able to compile C code and use the `@cImport` language feature to translate C code.
* Ability to more tightly integrate with Zig's linker, bringing some incremental compilation abilities to C. Due to language limitations it can never be as good as Zig but it can still be improved over other C compilers.
* Ability to compile C code to targets that LLVM does not support. Zig plans to support a wider target range than LLVM.
Hey! Nice to see you posting here. I've been keeping an eye on Zig for a while now because everything around it just looks pretty amazing!
2 questions:
- What are some books or resources you would recommend to get into (practical) low level programming with the goal of writing better Zig code? I know my basic self defense in C, and from a gut feeling I'd say C resources carry over the most but I'd be interested in how you see things and which resources you like or see a decent carryover in.
- I personally enjoy reading the Zig source code to learn the language. But what is something you'd like to see arise to improve the teaching of Zig in the future and once things get closer to 1.0?
I have been reading Richard Fabian's book, Data-Oriented Design, and finally things started to "click" for me. I've had these ideas swirling around in my head for years, but only recently do I feel like I have an intuitive grasp on how modern CPUs work, especially with regards to L1 cache, and the relative latencies of uncached memory loads vs computations.
There is a recent draft PR [1] to merge this into the zig compiler itself.
LLVM is being placed as a an optional component in the future [2]. Using arocc to fill this gap would mean that seamless C compilation could still be done, without LLVM being involved.
Andrew Kelley literally did a twitch vid this morning covering something inline with the goals of this project... The zig community seems pretty good so I'm sure everyone's efforts will be celebrated (as all community work should)
The Zig project is able to compile C because it embeds LLVM. This is different and has different use cases, imo. Example: this may be a good alternative frontend for C compilation in Zig under specific scenarios.
I think incremental compilation and hotswapping are some of those use cases, but I could be wrong about that (I'm not entirely sure if/why LLVM can't do it)
Sure, I also didn't meant it was all of CERN. Back in my days, ROOT wasn't getting much love on my department, we were focused more in Python bindings.
For contrast, gforth (a prominent Forth interpreter, by Forth standards) generates+compiles+links binding code in C, at runtime, using the ordinary C toolchain. [0][1][2]
A bit 'out there' you may say, but on the plus side this approach enables handling header files and tidily expressing bindings without the need to implement their own C parser. [2]
In this case, though, it seems like embeddable C compilers as means to support integration of C code into other languages in better ways is becoming a trend.
> Future plans for the project include making it the C backend of Zig's translate-c feature and making it an optional C frontend for the self-hosted Zig compiler.
I see WalterBright down there in the comments. Hi! His talk at Handmade Seattle about adding a C compiler to D was amusing and informative: https://media.handmade-seattle.com/importc/
Some interesting differences between the two approaches:
* D ImportC relies on an external preprocessor, while Aro does preprocessing.
* D ImportC lowers to D AST, while Aro lowers Zig AIR. This tweet has an infographic to help you get an idea of where AIR is in the Zig compiler pipeline: https://twitter.com/andy_kelley/status/1457800302946492418
* D ImportC is shipped, while Aro as a C frontend in Zig is an [unfinished branch](https://github.com/ziglang/zig/pull/10795)
It's been really exciting watching Vexu and ehaas (and other contributors) working on Aro.
Looks like there's some confusion as to why this exists when Zig already uses libclang to compile C code. The main reasons are:
* Improved `@cImport`/translate-c functionality, especially with regards to translation of macros. Vexu and ehaas are the main contributors of Zig's C translation implementation.
* Ability to bootstrap a lean Zig binary that does not depend on LLVM, and yet is still able to compile C code and use the `@cImport` language feature to translate C code.
* Ability to more tightly integrate with Zig's linker, bringing some incremental compilation abilities to C. Due to language limitations it can never be as good as Zig but it can still be improved over other C compilers.
* Ability to compile C code to targets that LLVM does not support. Zig plans to support a wider target range than LLVM.