Emulating Aarch64 in Software Using Jit Compilation and Rust
Key topics
The debate rages on: is it still "hacker spirit" if you're gluing together libraries rather than building everything from scratch? Some commenters argue that leveraging existing tools, like Cranelift for JIT compilation, is perfectly fine, while others jokingly lament the lack of raw, from-scratch innovation. The discussion is sparked by a blog post about emulating aarch64 using JIT compilation and Rust, with some pointing out that similar "glue-code" projects are common in various programming communities. As one commenter quips, "it's about taking some unrelated bits and hacking them back together" – a sentiment that seems to resonate with many.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
4d
Peak period
12
96-108h
Avg / period
7
Based on 14 loaded comments
Key moments
- 01Story posted
Aug 26, 2025 at 3:58 AM EDT
5 months ago
Step 01 - 02First comment
Aug 30, 2025 at 3:22 AM EDT
4d after posting
Step 02 - 03Peak activity
12 comments in 96-108h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 30, 2025 at 12:56 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Instead the author uses Cranelift[1] and binja to solve the two interesting problems here.
While cool, I'm not sure if that's interesting enough to read through in its entirety. I use libraries all day every day, but is it the hacker spirit to make your entire project glue-code for libraries that do the thing you claim to do?
It's maybe more philosophical than anything.
1: https://cranelift.dev/
I had this philosophical / existential crisis question lately about my project, and I think I'm at peace with it.
Yes. Gluing together stuff (AKA building on other giants' shoulders) can be done in a neglecting, "just hack it all up until starts to work" way, and it can also be done in a reproducible, "unit tested", documented way that enables you to eventually put even more "hacks" on top of it to deliver value.
Anything is "hacker spirit", as long as you make something _functional_ out of pieces that haven't functioning in a way you wanted before. Let it be witty, hackish, or beautiful, maintainable, as long as it holds up your business or gives you simply joy.
It all boils down to getting your hands dirty, instead of passively consuming the products of others.
ps. I'm not saying this project has the same potential as Dropbox or otherwise.
[1] https://news.ycombinator.com/item?id=9224
The disassembler is my next step, since it's the easiest to tackle. Swapping binja for a custom solution on the existing code would be relatively straightforward.
The JIT is a completely different beast, it's essentially the IR -> codegen steps of a compiler (meaning without parsing, syntax/lexical analysis, object generation). Seeing as I wanted to target both x86_64 and aarch64 hosts, using an existing solution would get me started faster before I eventually write my own.
My plan is to split the JIT backends and keep cranelift for x86_64 support, but have my own aarch64 JIT also.
You have to pick your battles and assign priorities, you cannot re-invent everything at once.
(Author here)
Literally in the name to hack things apart and hack them back together. It's about taking some unrelated bits and making something from it.
I am curious if you get to DMA before or after QEMU, and if before what your API will look like.