Pushing the limits of RISC-V emulation
shuklaayu.sh
Pushing the limits of RISC-V emulation
1–10 of 36 posts
Re: Pushing the limits of RISC-V emulation
#2At the end it is not emulation but static recompilation (which is, arguably, cooler)
Re: Pushing the limits of RISC-V emulation
#3At the end it is not emulation but static recompilation (which is, arguably, cooler)
How do you differentiate the two? What is the benefit of such a distinction? Why not use eg threaded emulation vs recompiled emulation?
Re: Pushing the limits of RISC-V emulation
#4At the end it is not emulation but static recompilation (which is, arguably, cooler)
How do you differentiate the two? What is the benefit of such a distinction? Why not use eg threaded emulation vs recompiled emulation?
Emulation visits instructions as they are executed. Static recompilation will (at translation time) visit instructions that can be discovered, even if they never run.
eg:
if (rand64() == 0x123456789abcdef0ull)
baz = bar;
Re: Pushing the limits of RISC-V emulation
#5Earlier quoted context omitted.
How do you differentiate the two? What is the benefit of such a distinction? Why not use eg threaded emulation vs recompiled emulation?
Emulation visits instructions as they are executed. Static recompilation will (at translation time) visit instructions that can be discovered, even if they never run. eg: if (rand64() == 0x123456789abcdef0ull) baz = bar; an emulator will likely never visit that assignment. A static recompiler will translate it.
Hm. What is the utility of this distinction?
Anyway, qemu certainly seems like it would fall under your definition of "emulator" despite obviously dynamically recompiling.
Re: Pushing the limits of RISC-V emulation
#6At the end it is not emulation but static recompilation (which is, arguably, cooler)
How do you differentiate the two? What is the benefit of such a distinction? Why not use eg threaded emulation vs recompiled emulation?
In my limited understanding, static recompiling is like JIT transpilation from one arch to another where emulation runs each instruction calling behaviour depending on the instruction. As for tradeoffs my knowledge is not wide enough to declare anything certain.
Re: Pushing the limits of RISC-V emulation
#7Earlier quoted context omitted.
Emulation visits instructions as they are executed. Static recompilation will (at translation time) visit instructions that can be discovered, even if they never run. eg: if (rand64() == 0x123456789abcdef0ull) baz = bar; an emulator will likely never visit that assignment. A static recompiler will translate it.
Hm. What is the utility of this distinction? Anyway, qemu certainly seems like it would fall under your definition of "emulator" despite obviously dynamically recompiling.
which is why i said "static recompiler" and not just "recompiler"
distinction is that an emulator is much simpler, while a static recompiler is a lot more work and thus ~30% more cool
Re: Pushing the limits of RISC-V emulation
#8Earlier quoted context omitted.
How do you differentiate the two? What is the benefit of such a distinction? Why not use eg threaded emulation vs recompiled emulation?
In my limited understanding, static recompiling is like JIT transpilation from one arch to another where emulation runs each instruction calling behaviour depending on the instruction. As for tradeoffs my knowledge is not wide enough to declare anything certain.
What is the distinction in your mind? Can recompiling not call each instruction? Can threaded interpretation not perform optimization?
Re: Pushing the limits of RISC-V emulation
#9Earlier quoted context omitted.
Hm. What is the utility of this distinction? Anyway, qemu certainly seems like it would fall under your definition of "emulator" despite obviously dynamically recompiling.
which is why i said "static recompiler" and not just "recompiler" distinction is that an emulator is much simpler, while a static recompiler is a lot more work and thus ~30% more cool
Ah. I admit I've only ever made dynamic recompilers
Re: Pushing the limits of RISC-V emulation
#10The coolest interpreter technique I saw was one that put instruction bodies in static functions which the "compiler" main loop would memcpy the body of the function out to straight-line code that would be executed from memory - a poor man's jit. All instruction functions had the same args and gcc would emit position independent code with the same predictable register calling convention. Brittle as hell, sure, but great compilation speed with low run-time overhead. It was able to run interpreted code at 1/5th of compiled code speed, compared to 1/10th speed for typical highly optimized computed goto loop interpreters.
I can't find a link, but if anyone recalls or wrote such an jit interpreter, please post.