Native guest execution
On Windows x86-64 the guest's machine code runs directly. One host worker carries each guest pthread, and the FS base is restored after every blocking call because Windows does not keep it.
Repository notes through October 10, 2026
One worker per guest thread
The dispatcher starts one host worker for each guest pthread, installs that thread's TLS, and enters the guest at the requested address with the System V argument registers. Join, detach, yield, sleep, nested callbacks and scePthreadExit all come back through this path. The HLE thread is completed only after guest execution has left that context.
The bridge checks that the entry point is executable and that the stack and TLS are mapped. It saves the Windows nonvolatile registers, MXCSR and the x87 control word, switches to the guest stack, installs the guest FS base, and calls the entry. A synchronous scePthreadExit leaves through a native escape that discards the guest frames and restores the host FS before the dispatcher sees the interrupt.
Windows drops the FS base
Installing FS once is not enough. Windows does not preserve a user-written FS base across a context switch. After a sleep, rdfsbase reads zero again. Guest code keeps its thread-local storage in FS, under the System V convention, so the next FS-relative access would fault near address zero. Nothing in the guest is wrong. The host dropped a register the guest is entitled to rely on.
The dispatcher therefore restores FS after blocking calls. Waits use a sequence-aware futex so a wake that arrives between an unlock and the park is consumed once, and a broadcast remains visible to every waiter that observed the older sequence. If the fixed wake history is ever saturated, the dispatcher over-wakes and lets HLE recheck the object. Timed sleeps use a private non-alertable delay so an unrelated wake cannot turn an audio worker into a spin.
Faults and other operating systems
A faulting guest thread is contained. Diagnostics attribute the address to a module and a symbol when they can, and the process does not have to die with an unhandled host exception. PS5_CPU_WAIT_DIAGNOSTICS=1 turns the verbose wait trace back on. It is off during normal play because several parked workers printing at once can themselves stall a frame.
Native execution requires Windows x86-64 and the RDWRFSGSBASE processor feature. Linux and macOS builds still compile the decoder, the loader and HLE, and they report the native bridge as unsupported. Guest binaries are x86-64 machine code. They are not interpreted.
What is implemented
- Native x86-64 guest execution on Windows, one host worker per guest pthread.
- System V calls, guest stacks, and FS restored after blocking calls.
- Sequence-aware waits, contained faults, and pthread exit that restores the host.
- Inspection, decoding and HLE on Linux and macOS, without native execution.
What is still missing
- There is no interpreter. Hosts other than Windows x86-64 do not run the guest.
- A CPU that cannot write FS and GS bases cannot enter the native bridge.
- Verbose wait diagnostics are off by default because their printing stalls play.
Related mechanisms
What these pages are