PIPELINE DO MIPS 32

UNIVERSIDADE FEDERAL DE VIÇOSA

Campus de Rio Paranaíba

Sistemas de Informação

PIPELINE DO MIPS 32

Trabalho

Disciplina: Arquitetura de Computadores (SIN 131)

Professor: João Fernando Mari

Alunos:

Eliane A.

David M.

Denilson L, C.

1.0 INTRODUÇÃO

Este trabalho, tem por objetivo apresentar a simulação de três algoritmos no Simulador Assembly online ‘MIPS Five Stage Pipeline’ da Universidade de Massachusetts, e apresentar as descrições dos hazards de dados e de controle.

2.0 CÓDIGO A

Abaixo segue a simulação, identificação e descrição dos hazards no Código A, com resolução tanto por bolha, quanto por encaminhamento.

Código A

0 - add $1, $2, $3

1 - add $4, $1, $2

2 - sub $3, $3, $1

3 - sw $4, 12($0)

4 - lw $1, 8($3)

2.1 Solução por Bolha

Na solução por bolha, perdeu-se 3 ciclos de processador por causa dos hazards que ocorreram e foram solucionados por bolha, conforme a figura 1.

Na linha 1 ocorreu um hazard de dados do tipo read before write, em que a instrução 1 (add) precisou de um dado (no registrador F1) que a instrução anterior, ainda não havia gravado.

Na linha 2 também ocorreu o mesmo tipo de hazard, onde a instrução 2 (sub) precisou do mesmo dado (registrador F1) que ainda não havia sido gravado.

Na linha 3 ocorreu um hazard de dados do tipo read before write, em que a instrução 3 (sw) precisou de um dado (registrador f4) que a instrução 1 (add) ainda não havia gravado.

Na linha 4 ocorreu o mesmo tipo de hazard, onde a instrução lw, precisou de um dado (do registrador F3), que a instrução 2 ainda não havia gravado.

Figura1: Código A, com solução por bolha

2.2 Solução por Encaminhamento

Na versão usando encaminhamento, os hazards foram resolvidos de forma mais eficiente, em que o processador não precisou ficar nenhum ciclo ocioso, conforme a figura 2.

Na instrução 1 ocorreu um hazard do tipo read before write, em que a instrução precisou dos dados do registrador F1, que a instrução anterior ainda não havia gravado, para isso, os dados foram encaminhados da saída para entrada da ULA para resolver o hazard.

Na instrução 2 ocorreu um hazard do tipo read before write, em que a instrução precisou dos dados contidos no registrador F1, que a instrução 0 ainda não havia gravado no registrador. Para resolver o problema, os dados foram encaminhados da instrução 0 para a entrada da ULA da instrução 2.

Na instrução 3 ocorreu um hazard do tipo read before write, em que a instrução precisou dos dados do registrador F4 para gravar na memória, mas a instrução 1 ainda não havia gravado no registrador, precisou fazer o encaminhamento para solucionar o hazard.

Na instrução 4 ocorreu um hazard do tipo read before write, em que a instrução precisou dos dados do registrador F3, para calcular o endereço, entretanto a instrução 2 não havia concluído a gravação, logo precisou encaminhar da saída da ULA da instrução 2 para a entrada da ULA da instrução 4.

Figura 2: Código A, com solução por encaminhamento

3.0 CÓDIGO B

Abaixo segue a simulação, identificação e descrição dos hazards no Código B, com resolução tanto por bolha, quanto por encaminhamento.

Código B

0 - lw $2, 64($0)

1 - add $3, $1, $2

2 - sub $4, $3, $2

3 - sw $3, 12($4)

4 - lw $3, 128($1)

5 - add $3, $2, $4

6 - sub $2, $0, $3

3.1 Solução por Bolha

O código B com solução sem encaminhamento, precisou de seis ciclos a mais para solucionar os hazards, conforme a figura 3.

Na instrução 1, ocorreu um hazard do tipo load use data, onde a instrução add precisou dos dados que estaria no registrador F2, porém a instrução load ainda não havia terminado de carregar os dados, sendo necessário dois stall para resolver o hazard.

Na instrução 2, ocorreu um hazard do tipo read before write, onde a instrução 2 (sub), precisou de um dado que a instrução 1 não havia gravado no registrador, por isso gastou-se mais dois stall para resolver o hazard. A instrução também precisaria dos dados da instrução 1(lw).

Na instrução 3, ocorreu um duplo hazard do tipo read before write, onde a instrução 3 (sw), precisou dos dados dos registradores F3 e F4, que as instruções 2 e 3 ainda não haviam disponibilizados.

Na instrução 3, ocorreu dois hazards, um do tipo read before write e outro load use data, pois a instrução 4 (lw) não havia carregado os dados e nem a instrução 5 (add) salvo os dados.

Figura 3: Código B, com solução por bolha

3.2 Solução por Encaminhamento

A solução do Código B por encaminhamento, conforme pode ser observado na Figura 4, foi bem mais otimizada a ponto de perder apenas um ciclo de clock para resolver o hazard.

Na instrução 1, ocorreu um hazard do tipo load use data, em que a instrução add precisou dos dados que a instrução anterior ainda não havia carregado para o registrador F2, como