Why does the same game need ARM64 and x64 builds?

Why rebuild the program if the game content is the same?

Suppose a game already has a Windows/x64 version and you want it to run on an ARM64 device. Some maps or textures may remain usable, but the executable contains machine instructions built for the original processor’s rules. A different CPU generally cannot execute those instructions unchanged.

With source code, developers can rebuild for a new target and adapt the required interfaces. With an existing executable, binary translation and other compatibility implementations may offer another route. This helps explain why one game can have several porting or compatibility approaches.

ARM64 and x64 primarily distinguish instruction set architectures (ISAs): the machine instructions a CPU recognizes, what they do and the registers software can use. Registers are small storage locations used directly during computation.

A microarchitecture is how a chip internally decodes, schedules and executes those instructions. One ISA can have different implementations. Two projects saying “ARM64 supported” therefore does not establish equal performance across devices. Whether software can run and how well it runs are separate questions.

Which rules change when a game moves between ARM64 and x64?

We are comparing two mainstream 64-bit instruction sets. ARM64 generally corresponds to AArch64 using A64 instructions. x64 generally means x86-64, also called AMD64. “x86” can name the wider family, but download labels often use it specifically for a 32-bit build, so it should not be treated as interchangeable with x64.

Both can add, loop and read data. They express those operations differently. Even incrementing a value can use different assembly notation:

x86-64 (Intel syntax): ADD RAX, 1
AArch64:              ADD X0, X0, #1

These lines illustrate incrementing a value, not a complete one-to-one translation: their effects on flags, such as zero and carry conditions, are not identical. CPUs also read the binary encodings, rather than these human-readable names.

A 64-bit ISA does not require every instruction to be 64 bits long. A64 supports 64-bit general-purpose registers while using 32-bit instruction encodings. Encoding length alone also cannot establish speed or power consumption; implementation, manufacturing process and workload matter too.

What does translation solve when a native build is unavailable?

A translator can interpret the original game program’s instructions and generate code that reproduces the required behavior on the destination CPU. This is binary translation. It does not require the game’s source code, and provides one route across the instruction-set boundary for an existing executable.

To run x86-64 code on an ARM64 device, a dynamic translator typically reads a block of original code, decodes its operations, emits ARM64 code and executes that code on the real CPU. It must preserve the original program’s register values, memory behavior and branch results. Reproducing an operation may require multiple host instructions or helper functions.

Translated blocks can be cached. When the code and relevant state remain applicable, later execution can reuse the block instead of translating it again. Microsoft’s Windows on Arm documentation and QEMU’s translator documentation describe block translation and reuse.

The destination CPU still executes its own instruction set. Cross-architecture execution works because software reproduces the required behavior, not because an ARM processor directly decodes every x86 instruction.

Why can’t an ARM64 Mac build simply run on a phone?

CPU instructions are one layer. Games also create windows, draw graphics, play sound and read input through operating-system and graphics interfaces. Two ARM64 devices do not necessarily accept the same executable format, system calls or input methods.

Translating a Windows game’s x64 instructions into ARM64 therefore does not automatically make it an Android game. Nor are Mac and iPhone applications interchangeable merely because both use ARM64. A native port adapts to its target system; a compatibility setup may additionally need system or graphics interface translation. Wine’s Windows API implementation illustrates interface compatibility work, which should be distinguished from CPU instruction translation.

That is why PortGames separates “Originally on” from “Play on.” A game originating on PC does not establish Windows as a project’s target. An ARM64 label does not replace the supported system, device requirements or run records. Sharing an ISA satisfies part of the compatibility conditions, rather than guaranteeing the whole game will work.

Device conditions remain useful for this reason: the ISA describes computational rules, system and graphics support describe the interfaces available, and a run record describes an observed result for a particular device, version and scene.

Arm · Instruction set architecture and microarchitecture · Arm · A64 Instruction Set Architecture Guide · Intel · X86 Encoder Decoder User Guide · Intel · Architecture and instruction manuals · QEMU · Translator internals · QEMU · System call translation · Microsoft · How emulation works on Arm · Microsoft · ARM64 ABI conventions · Wine · Windows API implementation