[kenoph]

Yep. For a project at my company we are doing pretty much the same as the author's (though for another architecture) and we JIT basic blocks on the fly using LLVM + C helpers.

Slightly OT, but even by JIT'ing + caching it's not always the case that your code run faster than a simple emulator. It sounds obvious written like this, but we were still surprised in some cases we encountered. But in our case it's probably related to the fact that the code we are jitting was not meant to be jitted, so we are doing some ugly things here and there. We also have to support self-modifying code (and that basically means blacklisting the jitter in some address ranges).

TL;DR: even with LLVM, emulation is often faster. QEMU tcg is likely faster than both, but it's GPL'd.

EDIT: wanted to add that LLVM JIT infrastructure is still moving quite a bit.

[fwsgonzo]

That's very interesting. I'll have a look! Do you generate LLVM intermediate assembly? (Is it called IR?)

[kenoph]

Yep. Actually we have a C helper per instruction and generate IR blocks full of CALLs to such helpers. Then the inliner and other optimizations take care of doing their work.

Anyway, if you never used LLVM, be ready to spend some time getting familiar with its IR and its C++ magic (though as a user I never had too much trouble... and I'm not a C++ guy). The documentation is also not very helpful, but the examples are good enough to get you started. The ORCv1 vs ORCv2 thing is kind of confusing sometimes.

[mhh__]

> Is it called IR?

IR = Intermediate Representation, named as such because whereas machine code is extremely carefully designed holistically with the hardware it executes on, an intermediate representation can much less "efficient" in the name of maintaining invariants to ease analysis throughout it's use in the compiler.

[yjftsjthsd-h]

> QEMU tcg is likely faster than both, but it's GPL'd.

What's your usecase that you'd care? I was under the impression that we were talking about internal dev support, where GPL is totally irrelevant, but even if you were distributing it to customers I'd be surprised if qemu's GPL infected your code since they're only ever combined at runtime (and even that's questionable in my mind, but IANAL). That is, if your code could run on the GPL Linux kernel without issue, why would it running on the GPL qemu compatibility layer matter?