Hacker News Reader

Comment by jchw | Hacker News Reader

Basically, instead of manually writing assembly fragments, they want to reuse annotated interpreter code, thus ensuring both correctness and safety for JIT-generated code, while reducing the redundancy. The rustc compiler is used to generate assembly fragments for the JIT, directly out of the interpreter code. It seems like a worthwhile endeavor.

View on HN

Your explanation is much better than what I can read in the blog post.

doesnt rustc rely on LLVM to generate its assembly. i watch the webrender repo and there have been several issues about poor codegen that LLVM could not properly handle. some were also related to absent optimizations at the MIR level.

also would that mean that the asm snippets could change as llvm changes and possibly cause security bugs if not carefully hand-audited/tweaked anyhow?

The blog post doesn't explain it very well, but I believe the tool code-generates the assembly at runtime, and not at compile time, so LLVM is not involved in code generation for the JIT.

Since it sounds very similar to RPython it probably does both: it generates a regular (native) interpreter, and generates and merges a JIT inside that interpreter (with all that implies of e.g. tracing and runtime code generation).

Rustc does, but it doesn't appear to me that holyjit does, that is https://github.com/nbp/holyjit/blob/master/lib/src/compile.r... and https://github.com/nbp/holyjit/blob/master/lib/src/lib.rs#L1...

Basically, it seems (and I haven't fully digested the code yet) that it uses https://crates.io/crates/dynasmrt for codegen.

Looks like dynasmrt was written for use in holyjit.

Quite possibly! It's the first I'm hearing of it. It's very interesting...

Thank you, jchw! Impressively concise and helpful summary!

Reply on news.ycombinator.com