Libriscv: RISC-V Binary Translation

https://fwsgonzo.medium.com/libriscv-risc-v-binary-translation-e080f52ee696

by ingve • 6 years ago

44 12 6 years ago

fwsgonzo.medium.com

rwmj• 6 years ago

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

fwsgonzo2• 6 years ago

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.

amelius• 6 years ago

Seems like the author is looking for LLVM.

kenoph3• 6 years ago

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.

fwsgonzo2• 6 years ago

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

yjftsjthsd-h• 6 years ago

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?

rcgorton2• 6 years ago

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

kenoph3• 6 years ago

Actually I think the biggest problem is predicting correctly all the jump targets.

rcgorton2• 6 years ago

For an overview of static translators: https://www.hpl.hp.com/hpjournal/dtj/vol4num4/toc.htm, article 9 ('Binary Translation')

non-e-moose• 6 years ago

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

Libriscv: RISC-V Binary Translation

Related Stories