[flagged]
Retrofitting JIT Compilers into C Interpreters
11–20 of 29 posts
Re: Retrofitting JIT Compilers into C Interpreters
#12Took me a while to figure out whether it's interpreters for C programs or if there's a particular class of interpreters called "C". Turns out it's about interpreters implemented in C that they use modified LLVM to do the retrofitting, but couldn't it be applicable for other languages with LLVM IR, or other switch-in-a-loop patterns in C?
I've been a low level C and C++ programmer for 30 years. Even with your explanation and having read the webpage twice I have no idea what this technology does or how it works. So it takes normal interpreted code and jits it somehow? But you have to modify the source code of your program in some way?
tracing jits are slightly harder to grasp than usual ones. The technique comes from real CPUs so the mindset of people behind the original idea is very different from the software world.
Metatracing ones are kind of an interesting twist on the original idea.
> So it takes normal interpreted code and jits it somehow?
Anyway, they use a patched LLVM to JIT-compile not just interpreted code but the main loop of the bytecode interpreter. Like, the C implementation itself.
> But you have to modify the source code of your program in some way?
Generally speaking, this is not normally the goal. All JIT-s try to support as much of the target language as possible. Some JIT-s do limit the subset of features supported.
Re: Retrofitting JIT Compilers into C Interpreters
#13Why do they need to change LLVM? Why can't they make this another LLVM IR pass?
Re: Retrofitting JIT Compilers into C Interpreters
#14TL;DR compile with a fork of LLVM that enables runtime IR tracing. Very clever!
That's not what they're doing. They're directly modifying the IR to convert it into a tracing JIT. The final artifact is a binary w/ no IR. The problem is of course not introducing any subtle bugs in the process b/c they'd have to prove the modification they're making do not change actual runtime semantics for the final binary artifact.
Re: Retrofitting JIT Compilers into C Interpreters
#15Those interested in this type of work can also visit https://cfallin.org/blog/2024/08/28/weval/. The difference is that they use this technique to derive an AOT compiler.
Re: Retrofitting JIT Compilers into C Interpreters
#16i tend to think of myself as a computing nerd, but posts like this one make me realize that i don't even rate on the computing nerd scale.
Do you always make things about yourself? Have you written a parser or interpreter? You should, it’s an interesting exercise. The idea is to add meta tracing to the interpreter (the c code) that allows hot paths to be compiled to machine code and be then executed instead of being interpreted.
> Do you always make things about yourself?
That's an abrasive question but i dare say that we all do. It's our only constant point of reference.
> Have you written a parser or interpreter?
i have written many parsers, several parser generators, and a handful of programming languages. This article, however, covers a whole other level, way over my head (or well beyond any of my ambitions, in any case).
Pics or it didn't happen: fossil.wanderinghorse.net/r/cwal
Re: Retrofitting JIT Compilers into C Interpreters
#17Why do they need to change LLVM? Why can't they make this another LLVM IR pass?
Our fork of LLVM does add a pass, amongst other changes, but we also have to do things like change stackmaps in a way that breaks compatibility. Whether stackmaps in their current incarnation are worth retaining compatibility for is above my pay grade! So some of our changes are probably upstreamable, but some might be considered too niche for wider integration.
Re: Retrofitting JIT Compilers into C Interpreters
#18Took me a while to figure out whether it's interpreters for C programs or if there's a particular class of interpreters called "C". Turns out it's about interpreters implemented in C that they use modified LLVM to do the retrofitting, but couldn't it be applicable for other languages with LLVM IR, or other switch-in-a-loop patterns in C?
You're quite right that since we're working with LLVM IR, adapting to other languages is probably not _that_ difficult, though these things always end up taking more time than I expect! Since the majority of real-world problems in this area depend on C interpreters, we put our limited resources to that problem. You're also right that "interpreters" is a pretty vague category, and there are other parts of C (and other) programs that could be yk-ified, though I suspect it would be a fairly specialised subset of programs.
Re: Retrofitting JIT Compilers into C Interpreters
#19I find rather strange the complaint about compatibility across JIT implementations, there is exactly the same problem across any programming language with multiple implementations, interpreters, compilers, JIT, whatever.
Re: Retrofitting JIT Compilers into C Interpreters
#20Took me a while to figure out whether it's interpreters for C programs or if there's a particular class of interpreters called "C". Turns out it's about interpreters implemented in C that they use modified LLVM to do the retrofitting, but couldn't it be applicable for other languages with LLVM IR, or other switch-in-a-loop patterns in C?
There were a couple of C interpreters since the 1990's, including with REPL support, but apparently never took off, most likely a community culture issue, that doesn't seem much value using them, beyond being in a debug session.