Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pushing the limits of RISC-V emulation

shuklaayu.sh

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Pushing the limits of RISC-V emulation

#21

Post by scheme271 »

ack_complete wrote: post #12
scheme271 wrote: post #11

Earlier quoted context omitted.

Sounds like a copy and patch JIT ( https://en.wikipedia.org/wiki/Copy-and-patch ). The python interpreter was experimenting with this and it provides a decent speedup.

Odd that the Wikipedia article gives 2021 as the first description of this technique when it is far, far older than that. I worked with a software rasterizer JIT that used it in ~2003 and I thought similar techniques were used in the classic MacOS m68k emulator on PowerPC.

Yeah, I think it was in use before. The wiki article is probably incorrect in the 2021 date.

Re: Pushing the limits of RISC-V emulation

#22

Post by pjmlp »

MiroslavPokorny wrote: post #14

CPU architectures evolve and often get replaces, eg Mac has moved from 68k -> Power -> x86 -> ARM or even Windows PC have also jumped from 32 to 64 bits and the same is also true of SIMD. Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ? This would solve so many problems including the need for emulators, because all binaries would work on all CPUS, and the…

They do, this idea is as old as UNCOL in 1958.

Regarding OSes still being sold today that use this idea, IBM i with Timi, Unisys ClearCase (started as Burroughs B5000 in 1961), Android, Java and .NET on embedded devices.

Then we have the ones from past times, Xerox PARC workstations with programmable microcode, Modula-2 M-Code on Lilith, Oberon slim binaries, Inferno with Limbo, Pascal UCSD P-Code, Andrew Compiler Toolkit...

Ah, and the WebAssembly folks pretending they are the very first with this idea.

Re: Pushing the limits of RISC-V emulation

#23

Post by pjmlp »

joha4270 wrote: post #18
MiroslavPokorny wrote: post #14

CPU architectures evolve and often get replaces, eg Mac has moved from 68k -> Power -> x86 -> ARM or even Windows PC have also jumped from 32 to 64 bits and the same is also true of SIMD. Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ? This would solve so many problems including the need for emulators, because all binaries would work on all CPUS, and the…

This does exist, we call it Java (or C# or probably a dozen other implementations) The big tradeoff you're making is that you have significantly less time to run your optimizer, since not everybody has a beefy machine or the patience to wait a day for their browser to start first time. You could try doing optimization ahead of time, but I think (I could be wrong here) you would inevitably end up adding in some CPU as…

> significantly less time to run your optimizer,

Not necessarily, you work around this with JIT caches, which allow the optimiser not to start always from zero.

Additionally your can also AOT compile, with or without PGO data.

All modern bytecode implementations, at least for Java and .NET, use a mix of JIT with caching/AOT/PGO.

Re: Pushing the limits of RISC-V emulation

#24

Post by pjmlp »

postalrat wrote: post #17
MiroslavPokorny wrote: post #14

CPU architectures evolve and often get replaces, eg Mac has moved from 68k -> Power -> x86 -> ARM or even Windows PC have also jumped from 32 to 64 bits and the same is also true of SIMD. Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ? This would solve so many problems including the need for emulators, because all binaries would work on all CPUS, and the…

Would that support self modifying code?

Self modifying code is frowned upon on modern platforms, due to its security implications.

Re: Pushing the limits of RISC-V emulation

#25

Post by pjmlp »

inkyoto wrote: post #20
MiroslavPokorny wrote: post #14

CPU architectures evolve and often get replaces, eg Mac has moved from 68k -> Power -> x86 -> ARM or even Windows PC have also jumped from 32 to 64 bits and the same is also true of SIMD. Why dont O/S support executables with something like LLVM binaries and generate the native code at load time ? This would solve so many problems including the need for emulators, because all binaries would work on all CPUS, and the…

It does exist in LLVM and is called Bitcode, a binary format for the LLVM IR - https://llvm.org/docs/BitCodeFormat.html Apple used to require apps submitted to its iOS App Store to be in the Bitcode format, and they would «recompile» the Bitcode into the exact user's iPhone CPU architecture at the download time – pretty much what OS/400 does. For reasons unknown, they have discontinued Bitcode.

The reasons are quite clear.

Contrary to other bytecode formats, LLVM bitcode is not stable, even across minor releases.

So anyone using it as bytecode format, like Apple, has to keep their own branch, and eventually it becomes too much work.

Microsoft did the same for DirectX DXIL, as did Khronos with the original SPIR definition, thus SPIR-V came to be as replacement, and recently Microsoft also decided to replace DXIL with SPIR-V.

Re: Pushing the limits of RISC-V emulation

#26

Post by joha4270 »

pjmlp wrote: post #23
joha4270 wrote: post #18

Earlier quoted context omitted.

This does exist, we call it Java (or C# or probably a dozen other implementations) The big tradeoff you're making is that you have significantly less time to run your optimizer, since not everybody has a beefy machine or the patience to wait a day for their browser to start first time. You could try doing optimization ahead of time, but I think (I could be wrong here) you would inevitably end up adding in some CPU as…

> significantly less time to run your optimizer, Not necessarily, you work around this with JIT caches, which allow the optimiser not to start always from zero. Additionally your can also AOT compile, with or without PGO data. All modern bytecode implementations, at least for Java and .NET, use a mix of JIT with caching/AOT/PGO.

You can work around this in various ways yes (I'll add dynamic recompilation to your list of workarounds), but you're always going to have the problem of "Somebody downloaded a program and want to run it now"

Re: Pushing the limits of RISC-V emulation

#27

Post by shuklaayush »

oso2k wrote: post #13

I was not impressed by author’s surprise that original emulation ran at 1/10th speed. For the past 50 years, that’s usually the target for calling (“unaccelerated”) emulation good enough. Especially for architectures that are current or in development or otherwise require some sort of instruction translation. The last 30 years we’ve seen innovations like dynamic recompilation, fat binaries, JIT VMs, and profile guide…

Hey, author here. That's fair, I didn't have the background. I knew interpreters would be slow, I just didn't expect it to still be ~10x after all the optimizations. After reading about it more though, that does seem to be the norm

Re: Pushing the limits of RISC-V emulation

#28

Post by shuklaayush »

dmitrygr wrote: post #2

At the end it is not emulation but static recompilation (which is, arguably, cooler)

Yeah, I went back and forth on the title. It's definitely not an interpreter. I still think of emulation as the umbrella term though, running code for one architecture on another, with interpretation and dynamic/static recompilation being different ways to get there

Re: Pushing the limits of RISC-V emulation

#29

Post by shuklaayush »

beholdo wrote: post #10

The 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 gre…

Neat, I guess this gets you the same output as a per-instruction translator without having to run an assembler and linker over the whole program. I should try this and add it to the post for completeness

Re: Pushing the limits of RISC-V emulation

#30

Post by shuklaayush »

Author here, thanks for all the comments, didn't expect this to get picked up.

I've been working on speeding up RISC-V emulation for work and wrote this up as I went. Still learning this space, so I'd be keen to hear from people who've worked on emulators or binary translation, especially where you think this approach falls short

Post reply on HN