Retrofitting JIT Compilers into C Interpreters

Post by i_don_t_know » Thu, Apr 16, 2026, 10:03 AM UTC

pjmlp wrote: post #20

fuhsnn wrote: post #4

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

Post by moardiggin » Thu, Apr 16, 2026, 2:34 PM UTC

fuhsnn wrote: post #8

itriednfaild wrote: post #6

Earlier quoted context omitted.

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?

I don't fully grasp it either, the most appropriate analogy I can think of is like how OpenMP turns #pragma annotated loops into multi-threading, this work turns bytecode interpreting loops into JIT VM.

    while (true) {
      __yk_tracebasicblock(0);
      Instruction i = code[pc];
      switch (GET_OPCODE(i)) {
        case OP_LOOKUP:
          __yk_tracebasicblock(1);
          push(lookup(GET_OPVAL()));
          pc++; break;

    case OP_INT: push(yk_promote(constant_pool[GET_OPVAL(i)])); pc++; break;

Post by moardiggin » Thu, Apr 16, 2026, 2:52 PM UTC

ltratt wrote: post #25

moardiggin wrote: post #24

Earlier quoted context omitted.

It's a promising technology, but it's still in the research domain. It's not an automated procedure. You need to use the yk fork of LLVM to compile and link your code, and you have to manually annotate and alter a fair amount of your interpreter loop with yk macros in non-trivial ways: while (true) { __yk_tracebasicblock(0); Instruction i = code[pc]; switch (GET_OPCODE(i)) { case OP_LOOKUP: __yk_tracebasicblock(1); p…

> If this project would be able to detect the interpreter hotspots itself and completely automate the procedure, it would be great. I don't think that's realistic; or, at least, not if you want good performance. You need to use quite a bit of knowledge about your context to know when best to add optimisation hints. That said, it's not impossible to imagine an LLM working this out, if not today, then perhaps in the no…

Post by fluorinerocket » Fri, Apr 17, 2026, 1:02 AM UTC

i_don_t_know wrote: post #22

pjmlp wrote: post #20

Earlier quoted context omitted.

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.

I used to work on LabWindows/CVI an integrated C development environment. It included an "Interactive Execution Window" where you could build programs piecemeal. You added pieces of code, ran them, then appended more code, ran the new pieces, etc. It was as text window so you had more freedom than in a simple REPL. It integrated with "Function panels". Function panels were our attempt at documenting our library funct…