Commit

MO601 - Arquitetura de Computadores II

http://www.ic.unicamp.br/~rodolfo/mo601

Rodolfo Azevedo - rodolfo@ic.unicamp.br

Por que mais um estágio?

• Ambos processadores, em ordem e fora de ordem, podem ter instruções alcançando o estágio de write-back fora da ordem correta
• Processadores precisam tratar exceções
• Processadores precisam tratar falhas de predição de branches
• O estágio de commit é responsável por resolver esses problemas

Estado do processador

• Estado arquitetural
  • Valores de memória e registradores internos
  • Todos os registradores devem ser acessados e visíveis a todo o processador (valores confirmado)
• Estado especulativo
  • Dados precisam ser utilizados com cuidado (especulativamente)
  • Dados especulativos precisam ser rastreados pelo processador
  • O processador deve ser capaz de desfazer os estados especulativos e suas consequências
  • Commit do estado especulativo → Novo estado arquitetural

RISC vs CISC

• Instruções CISC são quebradas em micro-operações
• Em geral, as micro-operações precisam fazer commit juntas
  • Existem algumas exceções, como as instruções de cópia de memória do x86

Liberação dos Recursos

• As entradas do Reorder Buffer (ROB) e Memory Order Buffer (MOB) podem ser liberadas no momento do commit
• Registradores físicos podem ser liberados se não forem utilizados novamente

Tratamento dos Estados Arquiteturais

• Os valores dos stores só podem ser gravados na memória no estágio de commit
  • Loads precisam checar o store buffer
• Duas técnicas para rastrear o estado arquitetural
  • Reorder Buffer (ROB) e Retire Register File (RRF)
  • Merged Register File (MRF)

Retire Register File (RRF)

Retire Register File em ação

Merged Register File

• Banco de registrador que armazena estados arquiteturais e especulativos
• Precisa rastrear os valores especulativos
• Valores não são movidos de um lugar para o outro
• Melhor para processadores cujas instruções leem os operandos após o despacho (issue)
• Esquema centralizado vs descentralizado
  • ROB
  • MRF
  • Múltiplos pipelines

Recuperação

• Certifique-se de que a instrução que gerou exceção não é especulativa
• Duas tarefas distintas
  • Recuperação do front-end
    • Limpar os buffers intermediários
    • Restaurar o histórico do preditor de branch
    • Atualizar o PC
  • Recuperação do back-end
    • Remover todas as instruções especulativas
    • Restaurar a renaming table
    • Recuperar os estados arquiteturais

Pipeline para recuperar branches

Tratando as falhas de predição

• Para arquiteturas com ROB e RRF
  • Aguardar o branch chegar no estágio de commit
  • Utilizar o RRF para restaurar o estado arquitetural (renaming table)
• Merged Register File
  • Utilizar um log para detetar os valores especulativos
  • Toma tempo mas pode ser otimizado
  • Ajustar a renaming table e os identificadores dos registradores físicos

Exceções

• Exceções precisas vs imprecisas
• Aguardar até o estágio de commit
  • Garante que a instrução não é especulativa
• Todos os estados arquiteturais estão estáveis agora
• Descartar (flush) todas as instruções em andamento
• Recuperar o estado arquitetural
• Redirecionar o front-end para o tratador de exceções