Execução nativa do convidado
No Windows x86-64, o código de máquina do convidado roda diretamente. Um worker do anfitrião carrega cada pthread do convidado, e a base de FS é restaurada depois de toda chamada bloqueante porque o Windows não a conserva.
Notas do repositório até 10 de outubro de 2026
Um worker por thread convidada
O despachante inicia um worker do anfitrião para cada pthread do convidado, instala o TLS dessa thread e entra no convidado no endereço pedido, com os registradores de argumento da System V. Join, detach, yield, sleep, callbacks aninhados e scePthreadExit voltam todos por este caminho. A thread HLE só é concluída depois que a execução do convidado deixou esse contexto.
A ponte verifica que o ponto de entrada é executável e que a pilha e o TLS estão mapeados. Ela salva os registradores não voláteis do Windows, MXCSR e a palavra de controle do x87, troca para a pilha do convidado, instala a base de FS do convidado e chama a entrada. Um scePthreadExit síncrono sai por um escape nativo que descarta os quadros de pilha do convidado e restaura o FS do anfitrião antes de o despachante ver a interrupção.
O Windows derruba a base de FS
Instalar FS uma vez não basta. O Windows não preserva uma base de FS escrita pelo usuário através de uma troca de contexto. Depois de um sleep, rdfsbase lê zero de novo. O código do convidado guarda o armazenamento local da thread em FS, sob a convenção System V, então o acesso seguinte relativo a FS falharia perto do endereço zero. Nada no convidado está errado. O anfitrião derrubou um registrador no qual o convidado tem o direito de confiar.
O despachante, portanto, restaura FS depois das chamadas bloqueantes. As esperas usam um futex consciente de sequência, para que um despertar que chegue entre um unlock e o estacionamento seja consumido uma vez, e para que um broadcast continue visível a todo esperador que observou a sequência mais antiga. Se o histórico fixo de despertares algum dia saturar, o despachante desperta a mais e deixa o HLE reverificar o objeto. As suspensões temporizadas usam um atraso privado e não alertável, para que um despertar sem relação não transforme um worker de áudio numa espera ativa.
Falhas e outros sistemas operacionais
Uma thread convidada em falha fica contida. O diagnóstico atribui o endereço a um módulo e a um símbolo quando consegue, e o processo não precisa morrer com uma exceção não tratada do anfitrião. PS5_CPU_WAIT_DIAGNOSTICS=1 liga de novo o rastreio verboso das esperas. Ele fica desligado durante o jogo normal porque vários workers estacionados, imprimindo ao mesmo tempo, podem eles mesmos atrasar um quadro.
A execução nativa exige Windows x86-64 e o recurso de processador RDWRFSGSBASE. As compilações de Linux e de macOS ainda compilam o decodificador, o carregador e o HLE, e informam a ponte nativa como sem suporte. Os binários do convidado são código de máquina x86-64. Eles não são interpretados.
O que está implementado
- Execução nativa x86-64 do convidado no Windows, com um worker do anfitrião por pthread do convidado.
- Chamadas System V, pilhas do convidado e FS restaurado depois das chamadas bloqueantes.
- Esperas conscientes de sequência, falhas contidas e saída de pthread que restaura o anfitrião.
- Inspeção, decodificação e HLE no Linux e no macOS, sem execução nativa.
O que ainda falta
- Não há interpretador. Anfitriões que não sejam Windows x86-64 não executam o convidado.
- Uma CPU que não consegue escrever as bases de FS e de GS não pode entrar na ponte nativa.
- O diagnóstico verboso das esperas fica desligado por padrão, porque a impressão dele atrasa o jogo.
Mecanismos relacionados
O que estas páginas descrevem