The absolutely easiest way to write a JIT is to use Javascript and eval() (or "new Function()", which is just eval in a Java-shaped tuxedo). You can quite easily speed up little matching functions, especially arithmetic heavy ones, by just filling in some templates at runtime!

Here's an example used in PuzzleScript: https://github.com/increpare/PuzzleScript/blob/dc1e0fc979365...

I've always really enjoyed Andrew Kelley's article about trying to statically recompile NES code from 2013 [1]. Basically he makes a ton of progress but gets hung up not just on the realities of the handwritten assembler of the era just not being all that great at mapping to higher level LLVM IR. In the conclusion he specifically calls out a JIT-type methodology as probably being the way to go, where you live-recompile the hot paths when you have the runtime data required to actually understand them, and don't worry about the parts you can't.

Very cool to see something like that in action.

[1]: https://andrewkelley.me/post/jamulator.html

> Dolphin isn’t on iOS, because you can’t do JIT compilation on iOS....Well, Apple has one exception to its JIT restrictions: web browsers. JavaScriptCore, WebKit’s JS engine, uses JIT compilation for its higher-performance tiers. So, if a JS function is called enough times, eventually it’ll be optimised and compiled into native machine code. The same is true for WebAssembly.

I was wondering about the why of the headline, and this is a really interesting answer. Such a beautiful way to get around restrictions. I wonder how applicable it is to other projects.

This is an incredible project for an undergraduate. Very impressive. Interesting to note that Firefox is 25% slower than Chrome/Safari, I wonder why.

Of course it beats a native interpreter. WASM overhead is about 20%, interpreter overhead is about 1000%.

What's cool here is to have a GameBoy JIT runtime at all.

> Apple has one exception to its JIT restrictions: web browsers

i wonder if they ever let native apps compile and run wasm directly instead of opening a browser window.

The author's base assumption, and stated motivation for doing this project, is wrong.

https://github.com/StephenDev0/StikDebug

For an undergrad project, I suppose it's fine to conveniently forget about the existence of this solution for the sake of getting a good grade.

It’s wrong ‘for sideloaded apps that have the get-task-allow entitlement.’

It’s right for ‘regular’ apps.

Great, so now it's "right, unless you sideload" - which is exactly how every jailbreak tool starts before someone finds the entitlement it forgot to check. Enjoy patching that at 3am.

StikDebug doesn't really replace this, it's a debugger-attach trick to flip Apple's own JIT bit, not a Game Boy interpreter. Different problem entirely. Fair point that jailbreak-ish JIT tools already exist for plenty of devices though.

Very interesting article. Would've been fun to see the comparison between native interpreter & JIT-on-WASM on iOS as well

Very cool! I did something similar using Dolphin and LLVM, 16 years ago during my masters, for a course on virtual machines. I compiled the interpreter to LLVM bitcode and then used it that to build basic blocks. It was super slow, but it worked, and I had lots of fun working on it.

Still doesn't beat a natively-coded emulator. I got several that run faster on a 166MHz non-MMX Pentium than this emulator does on my Core Ultra i9.

Yeah compiled builds and JIT approaches are just different beasts. I hit similar comparisons benchmarking DOSBox variants a while back, dynarec vs interpreter isn't apples to apples once you factor in host arch and what's actually being optimized for.

On Mednafen I can speed up the emulator up to 4x while compiling c++ under an n270 netbook. With GCC, not Clang. Without compiling I might yield 16x speeds and more with ease.

N270 is a rough baseline though, those things were slow even for 2008. Mednafen's core is genuinely well-optimized C, but 4x on a netbook vs whatever multiple this WASM approach claims isn't really apples to apples without matching host hardware.

So it's a JIT-in-JIT? JiJIT?

yet on real old hardware it would be 20x slower in real life. same as all native javascript junk - its fast, but non usuable on older hardware

Here's a nickel kid. Go buy yourself a real computer.

Good thing I'm not running games on my 4gb Pentium 4 then.

Anyone check what happens on lower-end phones once JIT compile time and memory overhead get counted against battery? Beating a naive interpreter on desktop Chrome doesn't say much about real mobile constraints.