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

31–36 of 36 posts

Re: Pushing the limits of RISC-V emulation

#31

Post by pjmlp »

joha4270 wrote: post #26
pjmlp wrote: post #23

Earlier quoted context omitted.

> 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"

Yeah, however in that very specific scenario it isn't about any winning SPEC benchmark suit.

Adding another workaround, shipping the JIT cache metadata alongside the program, and dynamically sharing it across all devices of the same category, as done in Android.

Re: Pushing the limits of RISC-V emulation

#32

Post by MiroslavPokorny »

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…

I do most of my work in java (https://github.com/mP1)... so i am familiar with it. Java is a high level language, and the native optimisations are done by the JVM vendor which basically boils down to Oracle today.

Some people might write some native code that is faster, but that is hardly the norm.

There are many classes of programs that dont work particularly well if written in java, such as video editing or graphics because you know the rest.

Re: Pushing the limits of RISC-V emulation

#33

Post by inkyoto »

pjmlp wrote: post #25
inkyoto wrote: post #20

Earlier quoted context omitted.

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…

Functionally, Bitcode delivers – a .bc file can be compiled into any architecture LLVM supports. I have tested a few supported architecture, and it worked like a charm.

Stability of the Bitcode format across releases is orthogonal to the functionality it provides. Given that OS/400's TIMI has been a long-running success, it is possible to put extra effort into stabilising the Bitcode format as well. Benefits would be numerous and significant, ranging from CI/CD to apps taking advantage of new or enhanced ISA extensions.

Re: Pushing the limits of RISC-V emulation

#34

Post by pjmlp »

inkyoto wrote: post #33
pjmlp wrote: post #25

Earlier quoted context omitted.

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…

Functionally, Bitcode delivers – a .bc file can be compiled into any architecture LLVM supports. I have tested a few supported architecture, and it worked like a charm. Stability of the Bitcode format across releases is orthogonal to the functionality it provides. Given that OS/400's TIMI has been a long-running success, it is possible to put extra effort into stabilising the Bitcode format as well. Benefits would be…

Yeah but that is the thing, for those that care about stability there are better options already.

Starting by the hyped WebAssembly, which I reckonignise it is useful, only not as breakthrough as it gets advertised given how many bytecode formats have existed since 1958.

Re: Pushing the limits of RISC-V emulation

#35

Post by MiroslavPokorny »

pjmlp wrote: post #22
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 To…

How many users does UNCOL or Xerox PARC have today ?

Not many.

The main o/s we all use today such as Linux/MAC/Windows dont and Im asking why not given the advantages such a binary would give.

Re: Pushing the limits of RISC-V emulation

#36

Post by MiroslavPokorny »

pjmlp wrote: post #24
postalrat wrote: post #17

Earlier quoted context omitted.

Would that support self modifying code?

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

Self modifying code is not allowed on some o/s because pages with code are marked as non writable, because bad things can happen when code is writable, eg buffer overflows.
Post reply on HN