Ejecución nativa del invitado
En Windows x86-64 el código de máquina del invitado se ejecuta de forma directa. Un worker del anfitrión lleva cada pthread invitado, y la base de FS se restaura después de cada llamada bloqueante porque Windows no la conserva.
Notas del repositorio hasta el 10 de octubre de 2026
Un worker por hilo invitado
El despachador arranca un worker del anfitrión por cada pthread invitado, instala el TLS de ese hilo y entra en el invitado en la dirección pedida con los registros de argumentos de System V. Join, detach, yield, sleep, los callbacks anidados y scePthreadExit vuelven todos por esta ruta. El hilo HLE se completa solo después de que la ejecución del invitado ha salido de ese contexto.
El puente comprueba que el punto de entrada es ejecutable y que la pila y el TLS están mapeados. Guarda los registros no volátiles de Windows, MXCSR y la palabra de control de x87, cambia a la pila del invitado, instala la base de FS del invitado y llama a la entrada. Un scePthreadExit síncrono sale por un escape nativo que descarta los marcos del invitado y restaura el FS del anfitrión antes de que el despachador vea la interrupción.
Windows suelta la base de FS
Instalar FS una vez no basta. Windows no conserva una base de FS escrita por el usuario a través de un cambio de contexto. Después de un sueño, rdfsbase vuelve a leer cero. El código del invitado guarda su almacenamiento local de hilo en FS, bajo la convención System V, así que el siguiente acceso relativo a FS fallaría cerca de la dirección cero. Nada en el invitado está mal. El anfitrión soltó un registro en el que el invitado tiene derecho a confiar.
Por eso el despachador restaura FS después de las llamadas bloqueantes. Las esperas usan un futex consciente de la secuencia para que un despertar que llega entre un desbloqueo y el aparcamiento se consuma una vez, y una difusión siga siendo visible para cada espera que observó la secuencia anterior. Si el historial fijo de despertares llega a saturarse, el despachador despierta de más y deja que HLE vuelva a comprobar el objeto. Los sueños con tiempo usan una espera privada no alertable para que un despertar ajeno no convierta a un worker de audio en un bucle activo.
Fallos y otros sistemas operativos
Un hilo invitado que falla queda contenido. El diagnóstico atribuye la dirección a un módulo y a un símbolo cuando puede, y el proceso no tiene que morir con una excepción del anfitrión no controlada. PS5_CPU_WAIT_DIAGNOSTICS=1 vuelve a encender la traza verbosa de esperas. Está apagada durante el juego normal porque varios workers aparcados que imprimen a la vez pueden, por sí solos, atascar un fotograma.
La ejecución nativa exige Windows x86-64 y la característica de procesador RDWRFSGSBASE. Las compilaciones de Linux y de macOS siguen compilando el decodificador, el cargador y HLE, e informan del puente nativo como no admitido. Los binarios del invitado son código de máquina x86-64. No se interpretan.
Qué está implementado
- Ejecución nativa del invitado x86-64 en Windows, un worker del anfitrión por cada pthread invitado.
- Llamadas System V, pilas del invitado y FS restaurado después de las llamadas bloqueantes.
- Esperas conscientes de la secuencia, fallos contenidos y una salida de pthread que restaura al anfitrión.
- Inspección, descodificación y HLE en Linux y macOS, sin ejecución nativa.
Qué falta todavía
- No hay intérprete. Los anfitriones que no son Windows x86-64 no ejecutan al invitado.
- Una CPU que no puede escribir las bases de FS y de GS no puede entrar en el puente nativo.
- El diagnóstico verboso de esperas está apagado de forma predeterminada porque su impresión atasca el juego.
Mecanismos relacionados
Qué describen estas páginas