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!
It has decent compatibility and good speed. Furthermore, I challenge anyone to find a PSX emulator with fewer lines of code with competitive speed and accuracy. To my knowledge, this is by far the simplest such implementation, and is able to do this by taking advantage of Javascript JIT compilation.
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.
> 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.
Restrictions aside, many years ago I landed a self-hosted Array.sort implementation in Firefox's JS Engine that performed better than the native C++ implementation :] -- it's a recurring theme.
What are you basing this statement on? The code comments read very human to me. Your the one hurting their chances of finding a job by falsely saying this.
Every company they apply to will be leveraging LLMs. Time to get over it. No need to be grumpy old man about such things. Every generation has faced such foes. The old always yields to the new.
You can’t vibe code a production capable C compiler if you’ve never written one.
Sure, companies are asking for LLM experience. But whether they know it or not they are also hiring someone who knows what they’re doing with the output.
Projects like this are still worth doing by hand. I’d dare say it’s even enjoyable.
I don't disagree with you. I just don't think it's particularly charitable for a presumably seasoned developer to not only go out of their way to accuse some junior of using LLMs but then declare that this obviously makes them unemployable.
True, but the WASM JIT is pretty low overhead because WASM seems to be a good design for what it needs to do. It's what I was referring to with the 20% overhead figure.
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.
I would not expect the average undergraduate to understand the intricacies of how iOS does dynamic codesigning enforcement. There are plenty of people who have graduated with advanced degrees and work at Apple who don't really understand how it works, either.
Here's an example used in PuzzleScript: https://github.com/increpare/PuzzleScript/blob/dc1e0fc979365...
reply