If the title is true, that would be a huge achievement. Unfortunately, the page says nothing about how it works and nothing about the speed advantage you get.
For my emulator jor1k [1] I tried something similar years ago [2]. However I haven't continued on this topic because of priority shifts. But the potential speed advantages are astonishing. My proof of context reached more than 1 billion emulated machine instructions per second.
> If the title is true, that would be a huge achievement.
Fundamentally it's "just" a JIT that compiles to WASM. It's a ton of effort to build something like that, but I think fundamentally it's not an impossible undertaking.
It is definitely not "just" a JIT compiler. For example, you can't just copy QEMU's JIT solution and hope that it works. So I'm interested in your solution.
For example, do you compile each code block (from jump to jump instruction) into a separate WebAssembly module?
If yes, then I wonder how many millions of small WebAssembly modules a browser can handle, how well the foreign function interface between JavaScript and WebAssembly actually performs and how much of the time the Browser JIT spends in compiling your generated code.
How do you handle machine code manipulation during execution for example? How do you mark already compiled memory pages as dirty.
I will definitely look at your code :-)
> WRT speed advantage: compared to what?
The speed advantage between interpreted and JIT compiled execution.
I'm not entirely sure that the browser runtimes are suited for this since I watched a friend demo-ing V86 and the amount of crashes with modern OSs just seemed to make it a toy (though I might be proven wrong).
One plausible guess I have is that they might be running out of memory since the browser runtimes are expecting the WASM code to be long lived whilst a emulator JIT by nature should be able to adapt to rapidly changing code and blows out of memory before things are cleaned up.
Presumably the crashes are happening because the instruction set implemented by the JIT is on Pentium II level and so encountering modern X86 instructions makes it fail. I am not familiar with the linked project but there is no real reason why you could not emulate a 32bit Intel perfectly in WASM. For 64bit I'm not sure if wasm64 wouldn't be required.
I think there are browser-level crashes too because you're using the WASM JIT-compiler in ways it hasn't been thoroughly tested for.
The Chromium team is pretty receptive to patches though, so for a big project like this it doesn't seem unreasonable to just patch the browser to perform well enough for your use case, and then upstream the patch so everyone has it within a few months when you're ready to launch your product.
> My proof of context reached more than 1 billion emulated machine instructions per second.
Which are the calculations about the billion instructions per second? Emulating instructions, even on a relatively simple system, requires a lot of support: decoding, cpu state, memory access/mapping, buses - and this doesn't even include the instructions themselves.
The calculations is based on the machine instructions, the compiled code by the JIT is able to perform on average. In this case a simple 32-Bit machine with OpenRISC architecture.
For the proof of concept, that was the compiled code in [1]. Just look for code snipplets such as "cycles = cyles - xxxx|0", that does the calculation during runtime.
So, my calculation does not include decoding, but CPU state, memory access/mapping, buses.
For my emulator jor1k [1] I tried something similar years ago [2]. However I haven't continued on this topic because of priority shifts. But the potential speed advantages are astonishing. My proof of context reached more than 1 billion emulated machine instructions per second.
[1] https://github.com/s-macke/jor1k
[2] https://github.com/s-macke/jor1k/wiki/Breaking-the-1-billion...