Microsoft Xbox 360

The Xenon CPU contains three symmetric PowerPC cores, each implementing the PPE (Power Processing Element) from IBM's Cell architecture with Xbox-specific modifications. Each core supports 2-way SMT, yielding 6 hardware threads total. The cores are in-order, 2-wide superscalar with a 23-stage pipeline, fabricated on 90nm SOI at 165 million transistors.

Each core contains 5 functional unitsa Branch Unit (BRU), Fixed-Point Unit (FXU), Load/Store Unit (LSU), Floating-Point Unit (FPU), and a VMX128 vector unit. The pipeline fetches 4 instructions per cycle but issues only 2. Branch mispredictions cost approximately 23 cycles due to the deep pipeline. A Gshare predictor with a 4K-entry table handles dynamic prediction; static hints are encoded in the BO field's y-bit. SMT is particularly effective on in-order cores because the second thread fills execution slots that would otherwise stall.

Cache hierarchy32 KB L1 I-cache (2-way associative) and 32 KB L1 D-cache (4-way associative, write-through, no write-allocate) per core. A shared 1 MB L2 cache (8-way set associative) runs at half clock speed (1.6 GHz). L1 data cache latency is ~3–4 cycles; L2 hits cost ~20–30 cycles; main memory access exceeds 400 cycles. The L2 cache integrates the security engine that performs AES-128 memory encryption and SHA-1 integrity hashing — each 128-byte cache line has a 16-byte hash stored in 64 KB of CPU-internal SRAM.

PowerPC ISA: register file and encoding

All instructions are fixed 32-bit width, word-aligned, big-endian. Bits 0–5 always carry the primary opcode (OPCD). The Xenon implements PowerPC ISA v2.02 (64-bit), though games run in 32-bit mode via MSR[SF]=0.

Register file per thread32 GPRs (r0–r31, 64-bit wide), 32 FPRs (f0–f31, 64-bit double-precision), Condition Register (CR, 32 bits as 8 × 4-bit fields CR0–CR7 with LT/GT/EQ/SO bits), XER (Summary Overflow, Overflow, Carry), Link Register (LR), Count Register (CTR), FPSCR (Floating-Point Status and Control), and 128 VMX128 vector registers (VR0–VR127, 128-bit each).

The major instruction encoding forms, each 32 bits

• I-form (unconditional branch): [OPCD 0:5][LI 6:29][AA 30][LK 31] — opcode 18 for b/bl; LI is a 24-bit signed offset shifted left 2 for ±32 MB range
• B-form (conditional branch): [OPCD 0:5][BO 6:10][BI 11:15][BD 16:29][AA 30][LK 31] — opcode 16; BO encodes CTR decrement and condition test options; BI selects which CR bit to test
• D-form (immediate/displacement): [OPCD 0:5][RT 6:10][RA 11:15][D 16:31] — used by addi (opcode 14), lwz (32), stw (36), lbz (34), lhz (40), lfs (48), lfd (50)
• DS-form (64-bit load/store): [OPCD 0:5][RT 6:10][RA 11:15][DS 16:29][XO 30:31] — opcode 58 for ld; 14-bit displacement shifted left 2
• X-form (register-register): [OPCD 0:5][RT 6:10][RA 11:15][RB 16:20][XO 21:30][Rc 31] — opcode 31; used by and (XO=28), or (XO=444), xor (XO=316), cmp, indexed loads/stores, cache ops
• XO-form (integer arithmetic): [OPCD 0:5][RT 6:10][RA 11:15][RB 16:20][OE 21][XO 22:30][Rc 31] — opcode 31; add (XO=266), subf (XO=40), mullw (XO=235), divw (XO=491)
• XL-form (CR ops, branch-to-register): [OPCD 0:5][BO 6:10][BI 11:15][BB 16:20][XO 21:30][LK 31] — opcode 19; bclr (XO=16, i.e. blr), bcctr (XO=528), crand (XO=257), cror (XO=449)
• XFX-form (SPR access): [OPCD 0:5][RT 6:10][spr 11:20][XO 21:30] — opcode 31; mfspr (XO=339), mtspr (XO=467); the SPR field is split: encoded as spr[5:9]‖spr[0:4]. Key SPRs: LR=8, CTR=9, XER=1
• A-form (FP multiply-add): [OPCD 0:5][FRT 6:10][FRA 11:15][FRB 16:20][FRC 21:25][XO 26:30][Rc 31] — opcode 63 (double), 59 (single); fmadd (XO=29), fmsub (28), fmul (25), fadd (21)
• M-form (rotate/mask): [OPCD 0:5][RS 6:10][RA 11:15][SH 16:20][MB 21:25][ME 26:30][Rc 31] — opcode 21 for rlwinm; MB and ME define a contiguous bitmask for extract/insert/rotate operations

Estimated instruction latenciesinteger add 2 cycles, integer multiply 4–7 cycles, integer divide ~33 cycles, FP add/multiply/fmadd ~6 cycles, FP divide ~33 cycles, VMX128 dot product 14 cycles.

Thread synchronization primitives

PowerPC uses a weak memory model — loads and stores may be reordered unless explicitly ordered. The atomic pattern uses load-linked/store-conditional:

• lwarx rT, rA, rB: Load Word And Reserve Indexed — loads a word and sets a hardware reservation on that cache line
• stwcx. rS, rA, rB: Store Word Conditional — stores only if the reservation is still valid; sets CR0[EQ] on success
• sync (hwsync): Full memory barrier — orders all loads and stores before/after
• lwsync: Lightweight sync — orders LD-LD, LD-ST, ST-ST but not ST-LD reordering
• eieio: Enforce In-order Execution of I/O — orders stores, primarily for memory-mapped I/O
• isync: Instruction synchronization — ensures prior context-altering instructions (e.g., mtmsr) complete before fetching subsequent instructions

Xenon-specific extensions

Three privilege levelsHypervisor (real mode, MSR[HV]=1), Kernel (supervisor, MSR[PR]=0), User (MSR[PR]=1). The sc instruction (opcode 17) triggers a syscall interrupt; SRR0 saves the return address, SRR1 saves MSR, and execution transfers to the hypervisor. Return via rfid (privileged).

HRMOR (Hypervisor Real Mode Offset Register) applies an offset to all physical addresses when address MSB is clear, mapping the hypervisor into encrypted memory space. The custom xdcbt instruction was designed to prefetch data directly into L1 bypassing L2, but it proved fatally dangerous — the branch predictor could speculatively execute it on never-taken paths, causing cache incoherency. It was effectively deprecated; no shipped games used it.

The CPU die contains a hidden security engine, 32 KB boot ROM (housing the 1BL bootloader and Microsoft's RSA public keys), 64 KB SRAM (for integrity hashes), and 768 bits of eFuse (one-time-programmable fuses storing the unique-per-console CPU Key, lockdown counters, and console type flags).

VMX128 is Microsoft/IBM's custom extension to AltiVec, designed to eliminate register spills in graphics-heavy inner loops on the in-order Xenon. Where standard AltiVec has 32 vector registers (5-bit fields), VMX128 provides 128 vector registers (7-bit fields) per hardware thread — a total of 768 vector registers system-wide across all 6 threads.

Encoding the 128-register file in 32-bit instructions

The extra 2 register bits are placed in non-contiguous positions within the instruction word, using otherwise-unused opcode bits. Per the IBM patent (US8312424B2) and the definitive Biallas binutils patch:

• VD128 (destination): low 5 bits at positions [6:10], high 2 bits at [29:30]. Full register = (VDh << 5) | VD
• VA128 (source A): low 5 bits at [16:20], bit 6 at position [10], bit 5 at position [5]. Full register = (A << 6) | (a << 5) | VA
• VB128 (source B): low 5 bits at [11:15], high 2 bits at [27:28]. Full register = (VBh << 5) | VB
• VC128 (fourth operand, vperm128 only): 3 bits at [6:8] — only VR0–VR7 can serve as the permutation control vector

Seven VX128 encoding sub-forms exist, each with different opcode mask patterns

VX128(op,xop)   = OP(op) | (xop & 0x3d0)    // Primary arithmetic
VX128_1(op,xop) = OP(op) | (xop & 0x7f3)    // Load/store
VX128_2(op,xop) = OP(op) | (xop & 0x210)    // vperm128
VX128_3(op,xop) = OP(op) | (xop & 0x7f0)    // Conversion, rounding, reciprocal
VX128_4(op,xop) = OP(op) | (xop & 0x730)    // D3D pack, rotate-mask-insert
VX128_5(op,xop) = OP(op) | (xop & 0x10)     // vsldoi128
VX128_P(op,xop) = OP(op) | (xop & 0x630)    // vpermwi128

Primary opcodes4 for load/store and vsldoi128, 5 for arithmetic/logical/pack, 6 for compare/shift/convert/D3D/splat.

Key VMX128-unique instructions not in standard AltiVec

The most important custom instructions for a recompiler to handle

Dot products — vmsum3fp128 (XOP 400) and vmsum4fp128 (XOP 464) compute 3- and 4-component dot products in a single instruction, producing 9.6 billion dot products/second across all three cores. These have no direct AltiVec equivalent.

D3D format pack/unpack — vpkd3d128 (XOP 1552) and vupkd3d128 (XOP 2032) convert between four 32-bit floats and compressed vertex formats natively: D3DCOLOR (ARGB8888), FLOAT16×2/×4, SHORT2/4, UBYTE4, and DEC3N/UDEC3 (10.10.10.2). Three immediate fields (VD3D0, VD3D1, VD3D2) select the format, shift, and mask. These yield ~50% vertex bandwidth savings.

Permute word immediate — vpermwi128 (VX128_P form) performs arbitrary word-level swizzle using an 8-bit immediate, functioning as a fast component reordering instruction.

Rotate-left-immediate-mask-insert — vrlimi128 (VX128_4 form) rotates and selectively inserts elements using a mask, enabling efficient single-component updates.

Multiply-add cross — vmaddcfp128 (XOP 272) computes VD = VA×VS + VB with different operand ordering from standard vmaddfp128 (VD = VA×VB + VS), giving compilers more register allocation flexibility.

Multiply — vmulfp128 (XOP 144) is a standalone vector float multiply not present in original AltiVec (which only had vmaddfp).

The full instruction set includes 128-register variants of all standard AltiVec operations: vaddfp128, vsubfp128, vand128, vor128, vxor128, vnor128, vandc128, vsel128, all compare variants, all pack variants, shift/rotate word operations, merge high/low, unpack, round, convert (FP↔int), reciprocal/rsqrt estimates, and exp2/log2 estimates.

VMX128 drops some standard AltiVec integer multiply-add instructions to free the encoding bits needed for the register extension fields. Register classes form a hierarchy: VR0–VR7 (3-bit vperm128 VC field), VR0–VR31 (backward-compatible with legacy VMX), VR0–VR127 (full VMX128).

The Xenos GPU was the first console GPU with a unified shader architecture, prototyping concepts that became ATI's TeraScale microarchitecture in the R600/HD 2000 series. Codenamed "C1," it sits architecturally between the R500 (Radeon X1000) and R600, at 232 million transistors on TSMC 90nm plus a ~105 million transistor eDRAM daughter die by NEC.

48 unified shader ALUs in 3 SIMD groups

The GPU organizes 48 shader ALUs into 3 groups of 16. Each group independently executes either vertex or pixel shader programs; a hardware sequencer dynamically load-balances workloads across groups. Each ALU co-issues a vec4 + scalar operation simultaneously (effectively "5D" per clock), processing exclusively FP32 — no half-precision penalty. This yields 480 FP ops/clock or 240 GFLOPS at 500 MHz.

Per clock across the full GPU16 bilinear texture fetches, 48 vector + 48 scalar ALU operations, 16 float4 interpolants, 32 control flow operations, 1 triangle setup, and 8 pixels resolved to system memory from eDRAM.

Xenos exceeds Shader Model 3.0 significantly4096 instruction slots (vs. 512), >500,000 executable instructions per draw call, 64 temporary registers (vs. 32), 512 shared constant registers, 32 texture samplers, and 16 interpolated registers. Key beyond-SM3.0 features include:

• MEMEXPORT: GPU scatter-writes to arbitrary memory addresses, enabling DX10-class stream-out
• Vertex kill: The kill instruction works in vertex shaders for geometry-level LOD reduction
• Hardware tessellation: A dedicated fixed-function tessellation unit accepts triangles, rectangles, and quads with per-edge tessellation levels, generating parametric coordinates fed to a displacement-mapping vertex shader — predating DX11 tessellation by 6 years
• Alpha-to-mask: Converts pixel shader alpha output to a sample mask for sort-independent translucency
• 4 simultaneous MRTs with independent blend states

Shader microcode format

Xenos shaders consist of three instruction types in a format closely related to the publicly documented R600 ISA:

Control Flow (CF) instructions manage executionEXEC, EXEC_END, COND_EXEC, LOOP_START/END, COND_JMP, COND_CALL, RETURN, ALLOC. ALU instructions encode a simultaneous vector + scalar operation on 64 GPRs (R0–R63). Vector ops include ADD, MUL, MAD, DOT4, DOT3, DOT2ADD, MIN, MAX, FLOOR, FRAC, TRUNC, SET, CND, MOVA. Scalar ops include RECIP, RECIPSQ, EXP, LOG, SQRT, SIN, COS, PRED_SET*. Fetch instructions subdivide into vertex fetch (VTX, pulling from vertex buffers with format conversion) and texture fetch (TEX, with sampler state, LOD bias, filtering). Shaders are stored as raw microcode in system memory; the GPU executes them directly without driver compilation.

10 MB eDRAM: the rendering backbone

The eDRAM daughter die provides 256 GB/s internal bandwidth and connects to the GPU parent die at 32 GB/s (compressed). It contains 192 parallel pixel processors that autonomously perform Z/stencil testing, alpha blending, and MSAA resolve — these operations are effectively "free" as they consume no shader cycles or main memory bandwidth. Supported render target formats include 8-8-8-8 INT, FP10 (7e3-7e3-7e3-2) for free HDR at the same memory cost as 32-bit integer, 16-16-16-16 INT, and FP16 (at 2× memory and half blending speed). MSAA operates at 2× or 4× with a rotated grid pattern.

Tiled rendering is forced by eDRAM capacity

At 32-bit color + 32-bit depth, the 10 MB eDRAM exactly holds common configurations

1280×720 without MSAA fits in a single tile. With 2× MSAA it requires ~2 tiles; with 4× MSAA ~3–4 tiles. Tiles are large screen-space regions (half- or quarter-screen), not the small 16×16 tiles of mobile GPUs. Internal eDRAM addressing uses 32×32-pixel micro-tiles with swizzled memory layout; 3D textures use 32×32×4 tiles.

Predicated tiling mechanismThe D3D runtime accumulates draw calls into a command buffer, then replays the buffer once per tile. Hardware predication uses screen-space extent tracking to skip primitives that don't intersect the current tile. Z-buffer state persists across tile passes. Each completed tile is resolved (MSAA downsampled) on the daughter die and DMA'd to a system memory texture. Tiling increases vertex processing (geometry re-processed per overlapping tile) but not pixel processing.

Texture formats and specialized capabilities

Standard formatsDXT1–5 (BC1–3), 8/16/32-bit integer, FP16, FP32, 5-6-5, 5-5-5-1, 10-10-10-2, texture arrays up to 64 faces. Xbox 360-specific compressed formats: DXT3A (4-bit scalar), DXT5A (single-channel, equivalent to BC4), DXN (two-channel, equivalent to BC5/3Dc for normal maps), CTX1 (compact two-channel). The GPU provides 16 filtered + 16 unfiltered texture fetch units at 8 Gtexels/sec.

Xbox Procedural Synthesis (XPS) enables CPU-generated geometry to stream directly to the GPU at 10.8 GB/s via a dedicated channel through the CPU L2 cache, bypassing main memory entirely.

Command buffer and register interface

Xenos uses ATI's PM4 (Packet Manager 4) command format, shared with Radeon R600 and later AMD GPUs. Each packet has a 32-bit header where bits [31:30] encode the type:

• Type 0: Direct register write — bits [15:0] = base register offset, [29:16] = count-1, followed by data words for consecutive registers
• Type 2: NOP/alignment filler
• Type 3: Complex operations — bits [15:8] = opcode, [29:16] = count-1, bit [0] = predicate. Opcodes include DRAW_INDEX, SET_CONSTANT, IM_LOAD (shader microcode upload), EVENT_WRITE, WAIT_REG_MEM, SURFACE_SYNC, COND_EXEC

The system uses Unified Memory Architecture — CPU and GPU share a single 512 MB GDDR3 pool at 700 MHz over a 128-bit bus (two 64-bit memory controllers on the GPU die). The GPU doubles as the northbridge; CPU memory access flows through the FSB at 21.6 GB/s (10.8 GB/s each direction) into the GPU's memory controllers.

Memory map layout

Physical RAM occupies 0x00000000–0x1FFFFFFF (512 MB). GPU registers are memory-mapped I/O (MMIO). The eDRAM is not directly CPU-addressable — it is internal to the GPU daughter die, accessed only through the GPU render pipeline and resolve operations. NAND flash (16–512 MB depending on revision) connects to the Southbridge via a proprietary 8-bit bus.

Virtual memory uses 4 KB and 64 KB page sizes. The hypervisor manages software page tables and preloads the TLB rather than using hardware page walks. All XEX sections align to 64 KB boundaries. Three memory protection modes match XEX section types: read-only, read-write, and read-execute. The hypervisor performs per-boot AES-128 memory encryption seeded from the eFuse hash, timebase counter, and hardware RNG.

The Xbox 360 audio pipeline splits between a dedicated XMA hardware decoder in the Southbridge and CPU-side software processing for everything else. There is no general-purpose audio DSP — unlike the original Xbox's Nvidia MCPX.

All mixing, effects processing, spatialization, sample rate conversion, and Dolby Digital 5.1 encoding run on the Xenon CPU, heavily leveraging VMX128 SIMD. The system supports 256+ simultaneous audio voices. Two APIs exist: XAudio (low-level DSP access) and XACT (high-level event-driven audio).

GDFX disc format

Games ship on DVD-9 dual-layer media read by a 12× CAV drive at up to ~16 MB/s. The custom GDFX (Game Disc Format for Xbox) filesystem resides in a game partition starting at sector offset 0x1FB20. Usable capacity is ~7.3 GB (XGD2) or ~8.3 GB (XGD3, post-2011), with remaining space consumed by anti-piracy security sectors.

The volume descriptor at the 32nd segment offset begins with magic **MICROSOFTXBOXMEDIA followed by the root directory sector number, size, and creation timestamp. Directory entries form a binary search tree** (sorted by filename) with 4-byte-aligned variable-length records: left/right child offsets (uint16 each, divided by 4), starting sector (uint32), file size (uint32), attribute flags (uint8), filename length (uint8), and ASCII filename. File data is stored contiguously from its starting sector.

Controller interface

Two-layer kernel architecture

The Xbox 360 runs a hypervisor at the highest privilege level (real mode, memory paging disabled) with a modified Windows NT kernel (xboxkrnl.exe) beneath it. Both kernel and user code run under the same lower privilege mode — the hypervisor alone has full hardware access. Only one game process runs at a time, though it can spawn multiple threads. Key kernel modules: xboxkrnl.exe (800+ exports by ordinal — memory management, threading, I/O, crypto) and xam.xex (Xbox Auxiliary Module — Xbox Live, UI).

System calls use the sc instructionr0 holds the syscall number, r3–r12 hold arguments, and the hypervisor dispatches via its syscall table. The kernel provides NT-derived functions: NtAllocateVirtualMemory, ExCreateThread, KeSetAffinityThread, NtCreateFile, XexLoadImage, plus Xbox-specific functions like VdRetrainEDRAMWorker and the XeCrypt* family for AES/RSA/SHA operations.

XEX2 executable format

The XEX container wraps an encrypted, compressed PowerPC PE executable. The 24-byte header starts with magic XEX2 (0x58455832), followed by module flags, PE data offset, reserved field, security info offset, and optional header count.

Security info (at the security info offset) containsheader size, image size, RSA-2048 signature (256 bytes), load address, Media ID (16 bytes), AES key seed (16 bytes for per-file encryption key derivation), SHA-1 hash data, region code, and an array of image data entries with per-block SHA-1 digests.

Optional headers follow the main header as ID/data pairs. The ID's low byte encodes data size: 0x01 means inline 4-byte value, 0xFF means offset-to-sized-data, other values = (ID & 0xFF) × 4 bytes. Key headers include:

• 0x010100 — Entry point address
• 0x010201 — Image base address
• 0x020200 — Default stack size
• 0x0103FF — Import libraries (ordinal-based references to xboxkrnl.exe and xam.xex)
• 0x0003FF — Base file format (compression/encryption type)
• 0x040006 — Execution ID (Media ID, Version, TitleID)
• 0x040310 — Game ratings (ESRB, PEGI, CERO, USK per-region bytes)
• 0xE10402 — Exports by name

EncryptionSection contents use AES-128 CBC. The retail key is {0x20, 0xB1, 0x85, 0xA5, 0x9D, 0x28, 0xFD, 0xC3, 0x40, 0x58, 0x3F, 0xBB, 0x08, 0x96, 0xBF, 0x91}; devkit key is all zeros. The per-file AES key seed is decrypted with this key to derive the review cycle. Compression: LZX compression with per-block integrity hashes. The inner PE uses Windows CE format exception tables (.pdata) — the Xbox 360 compiler backend derived from Microsoft's WinCE PowerPC compiler, and these tables provide function boundaries critical for static recompilation.

Hypervisor security model

Byte order: swap on every load and store

Both Xenia and XenonRecomp keep guest memory in native big-endian format and byte-swap at every load/store boundary. This is the only correct approach because pointer arithmetic, DMA, and MMIO all depend on the original memory layout. Implementation uses __builtin_bswap32/bswap per access, or ideally the x86 MOVBE instruction (Haswell+) which performs load+swap atomically. For vector loads, VPSHUFB with a byte-reverse mask handles the endian conversion. Swapping the entire memory image is not viable.

Condition register: explicit computation with lazy evaluation

PowerPC's 8 CR fields (32 bits) have no x86 analogue. The proven approach stores each CR field in the guest context struct and computes LT/GT/EQ/SO bits explicitly on compare and "dot" instructions. Since most arithmetic instructions do not update CR (only the . suffixed variants do), the overhead is manageable. For static recompilation to C++, the host compiler optimizes the resulting comparisons effectively. Lazy evaluation (deferring CR computation until a conditional branch reads it) is an alternative but risks branch misprediction overhead in the lazy dispatcher.

Link register: function mapping for static recompilation

XenonRecomp maps each PPC function 1:1 to a C++ function. bl becomes a C++ call; blr becomes return. Indirect calls (via CTR or function pointers) use a perfect hash table where func_addr * 2 indexes into a table of recompiled function pointers. Jump tables (detected by the pattern mtctr r0 → bctr) are converted to C++ switch statements using TOML configuration files generated by static analysis.

VMX128 to SSE/AVX: the register allocation wall

The 128→16 register ratio is the core challenge. Both XenonRecomp and Xenia store all 128 VRs in a guest state struct in memory. The C++ compiler's register allocator (for static recompilation) or the JIT's allocator (for Xenia) decides which VRs to keep in XMM registers versus spill. In practice, most game functions use far fewer than 128 VRs simultaneously — the extended file was designed for deep software pipelining on the in-order Xenon. Profiling hot loops to identify frequently-accessed VRs and prioritizing their allocation to physical XMM registers is the key optimization.

Direct 1:1 instruction mappings cover most operations: vaddfp128→ADDPS, vsubfp128→SUBPS, vmulfp128→MULPS, vmaddfp128→VFMADD231PS (FMA3), vand128→ANDPS, vor128→ORPS, vxor128→XORPS, vcmpeqfp128→CMPEQPS, vmaxfp128→MAXPS, vminfp128→MINPS, vrefp128→RCPPS, vrsqrtefp128→RSQRTPS, vsel128→BLENDVPS (SSE4.1), all rounding variants→ROUNDPS (SSE4.1), shift/compare integer→corresponding SSE2 integer ops.

Multi-instruction sequences are required forvmsum3fp128/vmsum4fp128 → SSE4.1 DPPS with mask 0x71 or 0xF1 respectively. vperm128 (byte-level cross-vector permute) → the 3-instruction SSSE3/SSE4.1 decomposition: mask indices to low 4 bits, subtract from 0xF for endian reversal, PSHUFB both sources independently, PBLENDVB to select between results based on bit 4 of each control byte. vpkd3d128/vupkd3d128 (D3D format conversion) → format-dependent sequences using PSHUFB, shifts, masks, CVTDQ2PS, and VCVTPH2PS (F16C for half-float). vexptefp128/vlogefp128 → polynomial approximation sequences (no x86 equivalent). vrlw128 (rotate left word) → (x << n) | (x >> (32-n)) per element.

Floating-point fidelity: require FMA3

Atomics and memory barriers: x86 TSO simplifies everything

PPC lwarx/stwcx. (load-linked/store-conditional) translates to x86 lock cmpxchg loops. The key difference: PPC LL/SC can spuriously fail on cache line eviction; x86 CAS fails only on value mismatch, so the old value must be captured for the compare.

Because x86 TSO is strictly stronger than PPC's weak memory model, most PPC barriers are no-ops on x86: lwsync (orders LD-LD, LD-ST, ST-ST) → no-op (TSO already prevents these reorderings). eieio → SFENCE only if non-temporal stores are used. isync → no-op in most cases. Only sync (full barrier) potentially needs MFENCE, and even this is often unnecessary when surrounding lock-prefixed instructions already provide implicit full barriers.

Threading: pin 6 guest threads to host threads

Xbox 360 games assign specific workloads to specific hardware threads (typically: thread 0 for game logic, thread 1 for rendering, thread 2 for audio, threads 3–5 for physics/AI/streaming). The recompiler should map these to 6 host OS threads with appropriate affinity. Thread synchronization primitives map naturally: PPC events → Win32/POSIX events, PPC mutants → recursive mutexes, PPC semaphores → counting semaphores. KeSetAffinityThread calls translate to host thread affinity APIs.

GPU emulation: the hardest problem

The Xbox 360 is deceptively complex beneath its unified-memory simplicity. The VMX128 extension is the CPU's most distinctive feature — its 128-register file and custom D3D-aware instructions require careful encoding-level understanding, but the actual translation to SSE/AVX is well-proven by multiple existing projects. The byte-swap-on-load/store strategy, explicit CR field computation, and FMA3 requirement are settled engineering decisions validated by Xenia and XenonRecomp.