finds.dev← search

// the find

ptitSeb/box64

★ 5,370 · C · MIT · updated Apr 2026

Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64, RV64 and LoongArch Linux devices

Box64 is a userspace x86_64 emulator for ARM64, RISC-V, and LoongArch Linux systems. It intercepts x86_64 system calls and library calls, routing the latter directly to native ARM libraries for performance, with a JIT dynarec that gives 5-10x speedup over pure interpretation. Primary audience is people wanting to run x86_64 Linux games or Steam on ARM SBCs, handhelds, and servers.

- The native library passthrough is genuinely clever: instead of emulating libc/SDL/OpenGL, it maps x86_64 calls to the host's native ARM64 versions, avoiding a huge emulation bottleneck that kills most other approaches.

- Dynarec coverage is thorough across four targets (ARM64, RV64, LoongArch, ppc64le in-progress), including AVX/AVX2 translation and x87 FPU — the file tree shows dedicated per-opcode files covering the full encoding space including 66/F2/F3 prefixes.

- Active, fast-moving development with real hardware sponsor backing (Radxa, Pine64, Ampere, StarFive) and a public game compatibility database, making it practically useful rather than a research toy.

- The multi-pass dynarec design (pass0–pass3 headers per target) and separate interpreter fallback means it degrades gracefully when JIT can't handle an instruction rather than hard-crashing.

- The wrapper layer for native libraries is generated code that must be manually kept in sync with library ABIs — any unimplemented or incorrectly wrapped function silently misbehaves rather than erroring cleanly, and debugging this is painful.

- 32-bit x86 support (Box32) is explicitly marked experimental and incomplete, so anything that drops into 32-bit mode (most Wine WOW64 scenarios, many older games) is a gamble.

- The codebase is enormous and largely underdocumented at the implementation level — the per-opcode dynarec files are thousands of lines of dense C with minimal comments, making contributing or auditing correctness very difficult for anyone not already deep in x86 encoding.

- Memory model correctness on weakly-ordered ARM is managed via a `STRONGMEM` tuning knob exposed to end users, which means applications that depend on x86 TSO semantics can silently produce wrong results unless the user knows to set the right env variable.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →