FEX-2609.1 lands as a pointed hotfix that repairs a Linux syscall regression
The patched build carries just three commits, but it fixes a real correctness break for anyone running 32-bit Linux apps or the new disk cache on ARM hardware.
FEX is a usermode x86 and x86-64 emulator for ARM64 Linux, and it's one of the faster ways to run PC software on ARM. People run it on Raspberry Pi 5s, on Apple Silicon under Linux, and increasingly on Snapdragon X2 Elite laptops. It translates x86 instructions into native ARM64 on the fly instead of taking QEMU's slower full-system route, which is the whole point of it existing over Box64 in the first place.
The latest patch is the opposite of a feature drop.
FEX-2609.1 shipped September 21, exactly thirteen days after FEX-2609. It contains three commits. All three are from Ryan Houdek, the project's primary maintainer under the handle Sonicadvance1, which tracks with how FEX runs: one main figure doing both the shiny work and the cleanup.
Why a single syscall matters so much
The headline fix is a correctness regression that 2609 itself introduced. That earlier release removed a syscall optimization, and the side effect was that the syscall instruction stopped counting as a block end. A block end is where FEX flushes a chunk of translated code and hands control back to the frontend. Get that wrong and emulated Linux programs start mishandling system calls, which tends to look like crashes or hangs.
The .1 patch restores that behavior in the opcode dispatcher and the decoder tables. Software interrupts like int 0x80 get their block-end flag back, and the Linux syscall handler now explicitly moves the instruction pointer two bytes past the opcode.
There's a comment in the patch worth quoting:
Skip past the syscall or int 0x80 instruction. Both of which are 2-bytes.
The logic here aligns Linux with the already-working ARM64EC and WoW64 paths. FEX stops special-casing its own Linux handling and treats RIP control the same way those paths already do. Houdek notes the frontend now modifies RIP manually, which is fine, and matches what arm64ec and wow64 do.
A second, smaller fix
The same commit also rescues the RDPID instruction on Win32. That one had been accidentally swept up in the syscall changes. FEX now reports RDPID correctly as unimplemented on Windows hosts that lack the TPIDRRO register, which keeps Windows binary emulation from handing out a bogus CPU ID.
Because both changes alter generated code, FEX bumped its disk-cache format version from 19 to 20. Instruction-count regression baselines were updated as well, so the CI stays honest.
That brings up the disk cache, since the .1 patch partly exists in its shadow. The on-disk JIT cache is the headline feature of 2609, for what it's worth. You flip it on with a FEX_DISKCACHE=1 environment variable or a JSON option, and FEX writes generated code to a FOZ database. On the next run it looks the code up before re-jitting, which should cut some of the stutter when you launch a game. It's experimental and opt-in, and it grows unbounded right now. No size limits. No stale-entry eviction. Turn it on and you'll clear cache files out of $HOME/.cache/fex-emu/ occasionally just to reclaim space.
What 2609 itself delivered
To understand why the patch was necessary, it helps to review what 2609 actually did. That release leaned hard on JIT work. There were undefined-flag corrections, deadlock fixes, and a PMULHRSW optimization the maintainers claim lifted Geekbench numbers, with a possible ~2x uplift on games that lean on that instruction family. Self-modifying-code detection got faster, which matters for some Unity games, and lock contention in the JIT dropped.
There was also a quieter change with a real security angle. FEX used to ship fallback paths for when its unixlib helper library wasn't present. That release removed those fallbacks, and while doing so the team found a genuine bug: swapping XTAJIT or Prism for FEX could accidentally trigger Windows syscalls through the old shims. Removing them kills that misdirected path.
One nice touch worth a mention: FEX got a new logo. A redesigned rainbow-gear mark. Feature releases deserve flair too.
Where this fits
At its core, FEX-2609.1 is a small hotfix. But it's a useful reminder of how much an emulator lives or dies on instruction-level detail. A two-byte x86 opcode, a manual RIP advance by exactly two bytes, a flag flipped to block end. Mess any of those up and whole categories of Linux apps break.
The bigger signal is that FEX is converging on one clean model across its host and target combinations. Linux syscalls now behave like ARM64EC and WoW64. That kind of architectural convergence is usually a good sign for an open-source project that's moved well past the proof-of-concept stage. It's arguably competing with commercial translation layers on feature-rich ARM laptops, and fixes like this are what keep it credible there.
The FEX community took to 2609 hard, with 19 users reacting across thumbs-up, hooray, heart, and rocket emojis. The .1 patch will mostly register with the subset running 32-bit Linux apps or pushing the new disk cache, both directly affected by the change.
The patch is available now. Pull it straight from the GitHub releases page, or open the diff between 2609 and 2609.1 if you want to see the flag flips for yourself. The project runs a roughly monthly cadence, so the next mainline tag is expected within weeks.
