Why JIT-to-Wasm Beats the Native Interpreter Barrier

Platform restrictions often stifle developer creativity. Consider the long-standing struggle to bring high-performance emulators to iOS. Because Apple restricts direct just-in-time (JIT) compilation to native machine code for third-party apps, developers are forced to rely on slow, CPU-bound interpreters. But there is a loophole. Apple allows JIT compilation within web browsers. WebKit's JavaScriptCore engine dynamically compiles JavaScript and WebAssembly into native machine code.

WATaBoy, an experimental Game Boy emulator, exploits this loophole by implementing a "JIT-to-Wasm" compiler. Instead of compiling SM83 (the Game Boy CPU) instructions directly to ARM or x86 assembly, it compiles them to WebAssembly bytecode at runtime. The browser then compiles this bytecode into native machine code. This technique bypasses platform bans and outperforms native interpreters, offering a fascinating look at the future of cross-platform runtime design.

The Architecture of JIT-to-Wasm

Traditional JIT compilers translate guest instructions directly to host machine code. This requires writing architecture-specific backends for every target platform. JIT-to-Wasm shifts this burden. By targeting WebAssembly, the emulator delegates the complex task of machine-code generation and optimization to the browser's highly optimized engine.

+-------------------+      +-------------------+      +-------------------+
|   SM83 Opcode     | ---> |   Wasm Bytecode   | ---> | Native Machine    |
|   (Game Boy CPU)  |      |   (Generated)     |      | Code (via Browser)|
+-------------------+      +-------------------+      +-------------------+

Emulating a console like the Game Boy requires strict cycle accuracy. To achieve this without sacrificing performance, WATaBoy adapts techniques from projects like GameRoy. It predicts when interrupts will occur before executing a JIT block. If an interrupt is imminent, the system falls back to a slower interpreter. Additionally, it uses lazy evaluation for non-CPU components accessed via Memory-Mapped I/O (MMIO). This hybrid approach keeps the JIT pipeline fast and accurate.

Developer Angle: Low-Level Codegen in Rust

Implementing a JIT-to-Wasm compiler requires generating Wasm bytecode dynamically. While tools like wasm-bindgen are excellent for standard web applications, they introduce unnecessary overhead for low-level bytecode manipulation.

Instead, developers can use Rust and pass data across the Rust-JavaScript boundary using the C ABI, relying on raw pointers and buffer lengths. This approach requires Nightly Rust to utilize inline Wasm. Switching the environment is straightforward:

rustup default nightly

The core dependency for generating bytecode is the wasm-encoder crate. It provides a builder pattern to emit Wasm instructions programmatically. Below is a conceptual example of how to dynamically build a Wasm module containing an addition function using wasm-encoder:

use wasm_encoder::*;

fn make_add_module() -> Vec<u8> {
    let mut module = Module::new();

    // Define the function signature: (i32, i32) -> i32
    let mut types = TypeSection::new();
    let params = vec![ValType::I32, ValType::I32];
    let results = vec![ValType::I32];
    types.ty().function(params, results);
    module.section(&types);

    // Declare the function
    let mut functions = FunctionSection::new();
    let type_index = 0;
    functions.function(type_index);
    module.section(&functions);

    // Export the function so the host can call it
    let mut exports = ExportSection::new();
    exports.export("my_add_func", ExportKind::Func, 0);
    module.section(&exports);

    // Encode the actual instructions
    let mut codes = CodeSection::new();
    let locals = vec![];
    let mut my_add_func = Function::new(locals);
    my_add_func
        .instructions()
        .local_get(0) // Push first parameter
        .local_get(1) // Push second parameter
        .i32_add()    // Add them
        .end();
    codes.function(&my_add_func);
    module.section(&codes);

    module.finish()
}

This generated bytecode is compiled by the browser's WebAssembly engine at runtime, turning the dynamic instructions into optimized native code.

Performance Trade-offs and the JIT Frontier

While JIT-to-Wasm offers an elegant escape hatch from platform restrictions, it is not a silver bullet. The architecture introduces specific trade-offs that developers must weigh.

First, there is compilation latency. Generating Wasm bytecode and handing it to the browser engine for compilation takes time. For short-lived tasks, the overhead of compilation can easily exceed the execution time, making a simple interpreter faster. This approach only shines when code blocks are executed repeatedly, amortizing the compilation cost.

Second, boundary crossing remains a bottleneck. Passing state between the host emulator, the Rust runtime, and the dynamically generated Wasm modules requires careful memory management. Using the C ABI and shared memory buffers minimizes this overhead, but it demands meticulous pointer tracking and unsafe Rust blocks.

Despite these caveats, the performance gains are real. By utilizing the browser's JIT compiler, developers can achieve execution speeds that leave traditional interpreters far behind. This technique is highly relevant for web-based emulators, dynamic language runtimes, and database query engines looking to run optimized code in sandboxed environments.