QEMU's TCG already does all this. It's how qemu is able to run single binaries and whole operating systems from one architecture on any other. https://wiki.qemu.org/Documentation/TCG
Yes, I would not dream of being able to compete with these juggernauts. Also, my use-case is for low overhead, low latency work - so I want to be able to have a VM ready to go in the time it usually takes linux to modify page tables!
So, it's a bit of a weird project in that way. Not your usual emulator. Ultimately it's a hobby project, though.
I actually tried to implement the tiniest KVM machine I could, and it wouldn't start in less than 1ms, which is an eternity for me. I also seem to remember that you need 2 file descriptors at minimum: 1 for the vCPU and the other for the VM itself.
Out of curiosity, what is the use case?
RISC-V is new enough that it is unlikely to be needed for 'dusty-deck' (source code long lost) that was needed for the VAX --> Alpha binary translators, or for Univac (ones complement!) to X86_64.
Why require a JIT? For static binary translators (based upon experience) the biggest difficulty is a combination of variable-length instruction decode and/or self-modifying code (requires an interpreter) and/or re-entrant-into-the-middle-of-an-instruction (easiest to handle with an interpreter).
Kenoph: is your company looking for people with experience in binary translation/compilers? My URL: http://gorton-machine.org/rick/index.html and resume hangs off of that.
Regards,
Richard
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.
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.
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.
> 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?
