Aro: A C compiler written in Zig | Hacker News Reader

Aro: A C compiler written in Zig

github.com

150 pointsfrankjr27 comments

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.

* 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.

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?

Andrew writes [1]:

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.

[1] https://ziglang.org/download/0.8.0/release-notes.html#Rework...

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.

[1] https://github.com/ziglang/zig/pull/10795

[2] https://kristoff.it/blog/zig-new-relationship-llvm/

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)

> Ability to compile C code to targets that LLVM does not support. Zig plans to support a wider target range than LLVM.

Wouldn't it be way more beneficial to extend LLVM instead?

One does not simply add a target to LLVM.

If it was trivial I can assure you the Rust folk would have already been at it.

I dont get it, doesnt the Zig project itself already do this?

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)

It can partially do that already, thanks to CERN and others collaborating on its C++ JIT.

2021 LLVM Developers Meeting “Enabling Interactive C++ with Clang”

https://www.youtube.com/watch?v=33ncbIQoa4c

Currently the best developer experience for hot code reload for C++ is Visual C++ 2022.

It would be fair to say this is mostly due in particular to the work of Vassil Vassilev and Axel Naumann rather than all of CERN.

If you're interested, they have monthly meetups open to the public, with fantastic speakers and presentations:

https://compiler-research.org/meetings/

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.

The dmd D compiler now has an embedded C compiler, written in D. The purpose is so D code can read C declarations. It doesn't use clang.

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]

[0] GitHub mirror: https://github.com/forthy42/gforth/blob/dda77d851ddeb80ca849...

[1] The official host: https://git.savannah.gnu.org/cgit/gforth.git/tree/libcc.fs

[2] https://rosettacode.org/wiki/Call_a_foreign-language_functio...

Does this mean you can directly import C headers in D?

yes

How about static inline functions?

yes

Well well well, I guess it's time to brush off the ol' dmd.

There's a pretty good chance that "A C compiler written in ___" will be well-received here, regardless of ___.

To add to this, I feel like half of the good github projects are doing something just because you can.

Which, to be frank, is a wonderful thing.

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.

Yes, but thank goodness there's no quota.

I believe it calls into Clang/LLVM to do so.

Reply on news.ycombinator.com