CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DE MINAS GERAIS

CURSO DE ENGENHARIA DE COMPUTAÇÃO

DEPARTAMENTO DE COMPUTAÇÃO

MÁRCIO ROBERTO DIAS DE ARAÚJO

MIPS X-RAY: UMA EXTENSÃO PARA O SIMULADOR MARSPARA O ENSINO DE ARQUITETURA DE COMPUTADORES

BELO HORIZONTE

2014

MÁRCIO ROBERTO DIAS DE ARAÚJO

MIPS X-RAY: UMA EXTENSÃO PARA O SIMULADOR MARSPARA O ENSINO DE ARQUITETURA DE COMPUTADORES

Trabalho de Conclusão de Curso apresentado aoCurso de Engenharia de Computação do CentroFederal de Educação Tecnológica de MinasGerais, como requisito parcial para obtenção dograu de Engenheiro de Computação.

Orientador: Prof. Dr. Flávio Luis Cardeal Pádua

BELO HORIZONTE

2014

Centro Federal de Educação Tecnológica de Minas Gerais

Curso de Engenharia de Computação

Avaliação do Trabalho de Conclusão de Curso

Aluno: Márcio Roberto Dias de Araujo

Título do trabalho: MIPS X-Ray: Uma extensão para o simulador MARS para o ensino de Arquitetura de Computadores

Data da defesa: 11 de agosto de 2014

Horário: 14:00

Local da defesa: 401 DECOM

O presente Trabalho de Conclusão de Curso foi aprovado pela seguinte banca de avaliação:

Professor Flávio Luis Cardeal Pádua – OrientadorDepartamento de Computação

Centro Federal de Educação Tecnológica de Minas Gerais

Professor Fabrício Vivas Andrade – Membro da banca de avaliaçãoDepartamento de Computação

Centro Federal de Educação Tecnológica de Minas Gerais

Professor Sandro Renato Dias – Membro da banca de avaliaçãoDepartamento de Computação

Centro Federal de Educação Tecnológica de Minas Gerais

Resumo

Este trabalho aborda o projeto e o desenvolvimento de uma nova extensão, denominada MIPSX-Ray, para o ambiente de simulação MARS da arquitetura MIPS, o qual é amplamente utili-zado em processos de ensino e aprendizagem sobre arquiteturas de computadores em diversasinstituições de ensino do mundo. Especificamente, a extensão proposta viabilizará por meiode animações gráficas uma melhor compreensão de modelos de fluxos de dados e da operaçãoconjunta de unidades funcionais diante da execução de determinadas instruções pelo processa-dor da arquitetura. Dessa forma, diversos conceitos, muitas vezes complexos e abstratos sobrearquitetura de computadores poderão ser mais facilmente apresentados e assimilados pelos es-tudantes dessa área. Um código fonte de testes que executa as principais funções do conjunto deinstruções MIPS é utilizado para validar o aplicativo proposto, demonstrando grande potencialde aplicação desta ferramenta em cursos relacionados com arquitetura de computadores.

Palavras-chave: Arquitetura de computadores, Visualização gráfica de caminho de dados, Si-mulador MARS, Arquitetura MIPS, Extensão MIPS X-Ray.

Abstract

This work addresses the design and development of a new plug-in called MIPS X-Ray, inten-ded for the MARS simulation enviroment of MIPS architecture, which is widely used in variouseducational instituitons throughout the world. Specifically, by using graphical animations, theproposed plug-in enables a better understanding of data flows models and the combined opera-tion of functional units given the execution of certain instructions by the architecture processor.Thus, several computer archicteture concepts, which are often complex and abstract, can bemore easily presented to and assimilated by the students in the learning area. Through theuse of a validation source code with the main functions of the MIPS instructions set, the testsperformed with the proposed plug-in demonstrate the significant potential of this tool.

Keywords: Computer architecture education, Graphical visualization of datapaths, MARS si-mulator, MIPS architecture, MIPS X-Ray plugin.

Lista de Figuras

–FIGURA 1 Diagrama dos diferentes tipos de simuladores. . . . . . . . . . . . . . . . . . . . . . 14

–FIGURA 2 Interface do simulador MARS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

–FIGURA 3 Interface do simulador SPIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

–FIGURA 4 Interface do simulador CSMIPSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

–FIGURA 5 Caminho de dados do simulador MipsIt. . . . . . . . . . . . . . . . . . . . . . . . . . . 19

–FIGURA 6 Caminho de dados do simulador VisiMIPS. . . . . . . . . . . . . . . . . . . . . . . . 20

–FIGURA 7 Interface do simulador WebMIPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

–FIGURA 8 Conjunto de instruções básicas da arquitetura (PATTERSON; HENNESSY,2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

–FIGURA 9 Porta de leitura e escrita para um banco de registradores, (PATTERSON;HENNESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

–FIGURA 10 Diagrama lógico da Unidade de controle, (PATTERSON; HENNESSY,2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

–FIGURA 11 Diagrama lógico da unidade de controle da ALU (PATTERSON; HEN-NESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

–FIGURA 12 Diagrama do caminho de dados da arquitetura MIPS, baseado em (PAT-TERSON; HENNESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

–FIGURA 13 Interface gráfica da extensão MIPS X-ray. . . . . . . . . . . . . . . . . . . . . . . . . 37

–FIGURA 14 Parâmetros de configuração de um segmento de animação. . . . . . . . . . . 38

–FIGURA 15 Caminho de dados do banco de registradores. Adaptado de (PATTER-SON; HENNESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

–FIGURA 16 Caminho de dados da unidade de controle. Adaptado de (PATTERSON;HENNESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

–FIGURA 17 Resultado da execução da instrução do tipo R. . . . . . . . . . . . . . . . . . . . . . 45

–FIGURA 18 Resultado da execução da instrução do tipo I. . . . . . . . . . . . . . . . . . . . . . . 45

–FIGURA 19 Resultado da execução da instrução do tipo Load. . . . . . . . . . . . . . . . . . . 46

–FIGURA 20 Resultado da execução da instrução do tipo Store. . . . . . . . . . . . . . . . . . . 46

–FIGURA 21 Resultado da execução da instrução do tipo J. . . . . . . . . . . . . . . . . . . . . . . 47

–FIGURA 22 Resultado da execução da instrução do tipo Branch. . . . . . . . . . . . . . . . . 47

–FIGURA 23 Resultado da execução do caminho de dados do controle da ALU. . . . . 48

–FIGURA 24 Resultado da execução do caminho de dados do controle. . . . . . . . . . . . 48

–FIGURA 25 Resultado da operação de leitura do banco de registradores. . . . . . . . . . 49

–FIGURA 26 Resultado da operação de escrita do banco de registradores. . . . . . . . . . 49

–FIGURA 27 Utilização dos recursos pelo simulador MARS em ambiente Windows. 51

–FIGURA 28 Utilização dos recursos pela extensão MIPS X-Ray em ambiente Win-dows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

–FIGURA 29 Utilização dos recursos pelo simulador MARS em ambiente Linux. . . . 52

–FIGURA 30 Utilização dos recursos pela extensão MIPS X-Ray em ambiente Linux. 52

Lista de Abreviaturas e Siglas

MIPS Microprocessor Without Interlocked Pipeline Stages

MARS Mips Assembler and Runtime Simulator

VHDL Hardware Description Language

VHSIC Very High Speed Integrated Circuit

FSM Finite State Machine

RISC Reduced Instruction Set Computer

ISA Instruction Set Architecture

ALU Aritmetic Logic Unit

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1 Definição do problema de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 Objetivos: Geral e Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.1 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 Organização do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Simuladores de Propósito Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Simuladores com Suporte a VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Simuladores com Ferramentas de Visualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Fundamentação Teórica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Arquitetura do Conjunto de Instruções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Formato das Instruções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Unidades Funcionais do Processador MIPS e componentes auxiliares . . . . . . . . . 26

3.4 Diagrama de Caminho de Dados do Processador . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Mips X-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Análise do Simulador MARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Codificação da extensão MIPS X-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Análise dos Bits das Instruções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.4 Modelagem da Ferramenta de Visualização do Caminho de Dados . . . . . . . . . . . . 35

4.5 Modelagem da animação do caminho de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 O Caminho de Dados Interno às Unidades Funcionais . . . . . . . . . . . . . . . . . . . . . . 38

4.7 Caminho de dados do banco de registradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.8 Unidade de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.9 Unidade de controle da ALU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.10 Apresentação e acesso a extensão MIPS X-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.11 Metodologia de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Resultados experimentais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Resultados do teste de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Resultado dos testes de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3 Resultado dos testes com usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

9

1 Introdução

A arquitetura e organização de computadores é um dos principais campos estudados

durante o curso de graduação em Engenharia de Computação. Nesta disciplina são apresentados

ao aluno conceitos de hardware e software, que têm como objetivo formar uma base de conheci-

mentos sobre o funcionamento básico das estruturas computacionais. O conteúdo de hardware

é composto pelo estudo das estruturas físicas que compõem um computador, tais como pro-

cessadores, bancos de memória e controladores (PATTERSON; HENNESSY, 2008; HAYES,

2002). Esse estudo pode ser feito tanto pela análise de simulações de componentes, quanto pela

manipulação dos componentes que são utilizados no mercado, tais como microprocessadores

e placas de circuito integrado. Além do estudo do hardware, existe um foco em apresentar ao

aluno como o hardware é programado para executar suas tarefas. Para isso utiliza-se linguagens

de baixo nível, como a Assembly, pois a mesma possibilita uma manipulação praticamente

direta dos recursos de hardware do processador (YIN RUI-XIN ZUO, 2011).

Hardware e software em arquitetura de computadores não podem ser tratados separa-

damente, pois ambos estão intimamente relacionados. O conjunto de instruções de uma arqui-

tetura e as operações que definem como um processador irá executar suas tarefas são definidas

juntamente com a estrutura de hardware do processador. Por exemplo, a maneira como uma

instrução de soma é definida irá variar de acordo com maneira como a estrutura do processador

é concebida.

A principal estrutura computacional estudada em arquitetura de computadores é o pro-

cessador. Para esse estudo é escolhida uma arquitetura que tenha como característica básica

a simplicidade para que um enfoque didático possa ser utilizado para descrever seu funcio-

namento. São estudados o conjunto de instruções da arquitetura, sua estrutura física e como

cada tarefa é executada dentro do hardware. Para a análise das estruturas físicas é utilizada

uma abstração dos componentes que executam as tarefas, uma vez que a estrutura que forma

o processador consiste de milhões de transistores trabalhando em conjunto. Portanto, efetuar

um estudo nesse nível de detalhes fugiria totalmente do foco principal que consiste em compre-

ender os conceitos básicos de funcionamento da arquitetura. Devido a essa complexidade, são

feitas abstrações da estrutura do processador como blocos funcionais, que são caracterizados

por sua principal função dentro da arquitetura. Uma das abordagens clássicas para o ensino de

arquitetura de computadores é a utilização de diagramas que ilustram os componentes de uma

estrutura computacional (HENESSY JOHN L.; PATTERSON, 2003; TANENBAUM, 1984;

10

HAYES, 2002). Os diagramas são utilizados em diversos contextos da disciplina, pois trans-

mitem a informação de uma maneira intuitiva ao raciocínio humano. Uma imagem é capaz de

apresentar um conceito de uma forma mais natural do que um texto dissertativo.

Nesse contexto, um dos grandes desafios do ensino de arquitetura de computadores é

apresentar de uma maneira compreensiva o funcionamento de sistemas relativamente comple-

xos de estruturas computacionais.

1.1 Definição do problema de pesquisa

A abordagem padrão para a análise de sistemas de hardware consiste na divisão da es-

trutura do processador em blocos lógicos, que possuem tarefas e comportamentos distintos. Tais

blocos são organizados de maneira a formar diagramas lógicos que mostrem as estruturas fun-

cionais, a dependência e coordenação entre elas. Esses diagramas são denominados caminhos

de dados (NIKOLIC et al., 2009). A modelagem mais simples de um processador consiste das

seguintes unidades funcionais: contador de instruções, memória de dados e instruções, unidade

lógica aritmética, banco de registradores, unidade de controle e multiplexadores (PINCKNEY

et al., 2008). Cada um desses elementos executam tarefas específicas na operação do sistema,

apresentando um comportamento diferente para cada tipo de instrução. A grande variedade de

operações possíveis a um processador cria uma grande gama de troca de dados e ações distin-

tas. A abordagem que se provou didaticamente mais efetiva para apresentar o funcionamento

dos processadores é a utilização de caminhos de dados (LUSCO; STROUD, 2010). O motivo

para isso é justamente a quantidade de configurações possíveis de como um processador pode

trabalhar. Dessa forma, apresentar a descrição das operações apenas de maneira textual seria

pouco eficaz para um bom entendimento, sendo considerado um caminho natural a representa-

ção gráfica do funcionamento por meio de um diagrama de caminhos de dados.

Apesar da utilização do caminho de dados ser um auxílio para uma melhor compre-

ensão do processador, ainda assim o dinamismo do funcionamento do processador torna com-

plexa a análise do mesmo. Em um único ciclo de processamento, diferentes sinais são enviados

e recebidos, blocos funcionais alteram entre uma tarefa e outra de modo que a representação

estática de todo o comportamento exigiria um grande número de quadros para cobrir todas as

possibilidades de funcionamento da arquitetura (YIN RUI-XIN ZUO, 2003).

O comportamento básico das unidades funcionais depende do tipo de instrução exe-

cutada no momento. Esta instrução é definida por um comando da linguagem de programação

seguido dos parâmetros correspondentes a operação. A linguagem Assembly se posiciona como

11

uma das mais próximas em relação a linguagem de máquina, apresenta uma grande contribuição

para o aprendizado dos aspectos de baixo nível, uma vez que para sua utilização é necessário

um entendimento dos diferentes aspectos de hardware, como por exemplo a alocação de memó-

ria, utilização de registradores e execução das operações básicas que são utilizadas para criar

as rotinas. Um dos tópicos que são trabalhados frequentemente durante os cursos de arquite-

tura de computadores é como a linguagem de máquina, sequência de bits que representam as

operações, interage com o hardware e produz a operação solicitada.

Considerando este contexto, o presente trabalho tem como objetivo projetar e desen-

volver uma solução para auxiliar no estudo de arquitetura de computadores, implementando

uma ferramenta para apresentação visual de forma dinâmica do caminho de dados de um pro-

cessador que possibilite um melhor entendimento do fluxo de dados e ações que acontecem

neste. É foco também desse trabalho apresentar a relação da linguagem Assembly com a exe-

cução das operações do processador, apresentando ao usuário como as instruções influenciam o

funcionamento do mesmo.

1.2 Motivação

Na disciplina de arquitetura de computadores são apresentados diversos conceitos em

relação ao funcionamento de um processador, muitos desses conceitos são melhor compreendi-

dos através de ferramentas para visualização do funcionamento da arquitetura. Neste cenário,

simuladores foram criados, com o objetivo de mimetizar o comportamento do hardware, tor-

nando o conceito do funcionamento do hardware em algo mais tangível para o aluno (KABIR

et al., 2011; BRORSSON, 2002). Com a utilização de um simulador é possível executar passo

a passo as rotinas que não poderiam ser analisadas de maneira física apenas com a análise de

uma placa ou componente de hardware (WOLFFE et al., 2002). Entre os principais simuladores

existentes, um aspecto não é analisado pela maioria deles, qual seja, a propagação dos sinais

pelo caminho de dados (BRANOVIC et al., 2004; BEM; PETELCZYC, 2003). Muito embora

ótimos simuladores possibilitem ao usuário trabalhar com as principais unidades funcionais,

manipulando valores e executando tarefas em cada unidade (YI; DING, 2009; PINCKNEY et

al., 2008), a compreensão do funcionamento do processador como um todo não pode ser en-

tendida apenas observando as unidades funcionais trabalhando separadamente, sendo por isso

necessária uma ferramenta que possa apresentar o funcionamento das unidades em conjunto.

A compreensão da propagação dos sinais pelo caminho de dados depende da análise

de quais sinais são ativados de acordo com a instrução a ser executada. Desvios condicionais

12

e cargas de dados, por exemplo, utilizam diferentes sinais e manipulam dados de maneira dife-

rente, apesar de utilizarem as mesmas unidades funcionais e o mesmo caminho para os sinais.

Uma ferramenta que possibilite a visualização do fluxo de forma dinâmica, demonstrando as

interações entre as unidades, os sinais de controle e o tipo de execução no momento em que

uma instrução é carregada, representa um grande auxílio no processo de entendimento do com-

portamento de um processador.

1.3 Objetivos: Geral e Específicos

O objetivo geral desse trabalho consiste em desenvolver uma ferramenta que se integre

ao simulador da arquitetura MIPS, denominado MARS (VOLLMAR; SANDERSON, 2006),

fornecendo uma visualização dinâmica de um caminho de dados e demonstrando o fluxo dos

sinais entre as unidades funcionais. A ferramenta proposta recebe como entrada um código

fonte criado na linguagem Assembly, executado e compilado pelo simulador, e apresenta uma

animação do caminho de dados que demonstre como o processador responde ao código gerado.

1.3.1 Objetivos Específicos

• Facilitar a compreensão da execução do funcionamento do fluxo de dados de um proces-

sador;

• Possibilitar ao usuário uma compreensão de como o código fonte gerado é executado no

processador;

• Reduzir o tempo gasto com análises e explicações do funcionamento de caminho de dados

estáticos;

• Possibilitar a inclusão de uma nova funcionalidade ao simulador utilizado neste trabalho,

especificamente, a visualização de diagramas de caminho de dados;

• Possibilitar tanto a visualização macro do funcionamento do processador como um todo,

quanto a visualização micro do funcionamento interno de cada unidade funcional.

1.4 Contribuições

O presente trabalho apresenta uma nova ferramenta, sob a forma de uma extensão para

o simulador MARS, que possibilita ao aluno uma melhora na compreensão do funcionamento

13

de um processador, por meio da visualização do fluxo de dados dentro do mesmo. Dessa forma

propicia-se ao aluno uma visão de como software e hardware estão intimamente ligados, pela

visualização de como o código fonte gerado cria comportamentos distintos na execução das

operações de um processador.

1.5 Organização do Documento

Este trabalho está subdivido em seis capítulos. O capítulo 2 apresenta os trabalhos

que estão relacionados com o trabalho proposto. Nele é mapeado o estado da arte dos simula-

dores MIPS, apresentando os principais simuladores disponíveis e as suas características. Em

seguida são apresentados simuladores que suportam a linguagem de descrição de hardware

VHDL apresentando sua importância no desenvolvimento de novas arquiteturas. Finalmente

são apresentados simuladores focados em representação visual do funcionamento da arquite-

tura. Esses simuladores, assim como o proposto neste projeto, utilizam diagramas de caminho

de dados para representar o funcionamento dos processadores. O capítulo 3 consiste na funda-

mentação teórica, apresentando o conjunto de instruções da arquitetura, os blocos funcionais do

processador, seu funcionamento e uma descrição simplificada do funcionamento da simulação

implementada pelo MARS. O capítulo 4 descreve a metodologia de pesquisa, indicando os pas-

sos seguidos durante o seu desenvolvimento e teste para a validação da ferramenta produzida.

Os resultados experimentais obtidos são apresentados no capítulo 5. Finalmente no capítulo 6

são apresentadas as conclusões obtidas e as propostas de trabalhos futuros.

14

2 Trabalhos Relacionados

Neste capítulo são apresentados trabalhos relacionados ao contexto do problema apre-

sentado, buscando-se delinear o estado da arte dos simuladores e ferramentas da arquitetura

MIPS. Após a execução de uma análise das principais funcionalidades dos simuladores e suas

características mais importantes, foi feita uma classificação dos simuladores analisados com o

objetivo de particionar de simplificar o levantamento do estado da arte dos simuladores MIPS.

Os trabalhos desenvolvidos com estes objetivos podem ser agrupados em três diferentes clas-

ses de simuladores (ver Figura 1): simuladores de propósito geral, que possuem como foco a

criação de um modelo que representa o funcionamento básico do processador MIPS; simulado-

res com ferramentas de descrição de hardware, que além da simulação do funcionamento do

processador, possibilitam a criação de modelos de hardware usando a linguagem VHDL; simu-

ladores com ferramentas de visualização de caminho de dados, que possibilitam a visualização

do processador em forma de diagramas de fluxo de sinais.

2.1 Simuladores de Propósito Geral

Simuladores são softwares que modelam o funcionamento básico de um determinado

componente, no escopo desse problema um processador MIPS. Os simuladores possuem como

vantagem a abstração das características complexas do sistema, possibilitando ao usuário focar

nas características principais que se deseja trabalhar.

Figura 1: Diagrama dos diferentes tipos de simuladores.

15

Os simuladores são amplamente utilizados no ambiente educacional, pois possibilitam

a interação com as funcionalidades básicas de um processador mantendo o foco apenas nos

aspectos do mesmo que se deseja estudar. Entre os principais simuladores, pode-se destacar:

• MARS: MIPS Assembler and Runtime Simulator

MARS (VOLLMAR; SANDERSON, 2006) é um simulador da arquitetura MIPS 32 que

utiliza a linguagem Assembly. Foi desenvolvido utilizando a linguagem Java para apli-

cações Desktop. A licença utilizada como base para a aplicação é a de uso aberta da

universidade MIT. O simulador implementa em sua estrutura as unidades funcionais do

processador MIPS, sendo visíveis em tempo de execução ao usuário os 32 registradores

e a memória de dados com seus respectivos endereços e valores armazenados. O MARS

fornece aos usuários uma interface gráfica que permite tanto editar o código fonte quanto

visualizar a execução do processador respondendo ao código gerado, por meio da aná-

lise de registradores e memória. Os dados das unidades funcionais são apresentados ao

usuário por meio de tabelas de endereços e calores. Os criadores do projeto incentivam

a comunidade a desenvolver novas ferramentas, fornecendo uma estrutura básica para a

criação das mesmas. Ferramentas que oferecem melhorias reais para o sistema são agre-

gadas em versões futuras do simulador. O simulador MARS foi utilizado como base para

a elaboração desse projeto, devido a todas as suas funcionalidades e a larga utilização do

mesmo na área acadêmica. A sua interface gráfica pode ser vista conforme figura 2.

Figura 2: Interface do simulador MARS.

16

• SPIM: A MIPS 32 Simulator

SPIM (LARUS, 2014) é um simulador da arquitetura MIPS32 que executa a leitura de có-

digo fonte Assembly e apresenta ao usuário o fluxo de execução das instruções. O usuário

pode visualizar em tempo de execução o valor contido nos registradores da arquitetura e

memória conforme figura 3. O simulador SPIM não possui um ambiente de desenvolvi-

mento para a criação de código fonte. Para executar os códigos é necessário que o usuário

insira o arquivo já escrito, cabendo ao simulador a função apenas de compilar o código

fonte e rodar a simulação. Durante a simulação o programa executa uma lista de todas

as instruções que são executadas, assim como os endereços de memória correspondentes

àquela instrução.

O simulador SPIM juntamente com o simulador MARS se destacam como os simuladores

mais conhecidos e utilizados em cursos de arquitetura de computadores, principalmente

considerando os cursos que estudam a arquitetura MIPS 32. Amplamente discutida na

bibliografia de Patterson and Hennessy (PATTERSON; HENNESSY, 2008)

Figura 3: Interface do simulador SPIM.

17

• CSMIPSA: Enhanced Cycle Simulator for MIPS Architecture

CSMIPSA (ARORA; RAJPUROHIT, 2013) é um simulador que permite além da visu-

alização do funcionamento de um processador MIPS, a observação do estado interno do

processador e a visualização do banco de registradores e memória, conforme represen-

tado na figura 4. Com a utilização deste simulador é possível efetuar a validação de um

projeto de processador assim como o seu compilador. Além disso, é possível também

analisar a qualidade de um conjunto de instruções da arquitetura, verificando questões

como desempenho, tempo de processamento e utilização de recursos.

Figura 4: Interface do simulador CSMIPSA.

18

2.2 Simuladores com Suporte a VHDL

A linguagem VHDL (VHSIC Hardware Description Language) é utilizada na con-

cepção e projeto de circuitos digitais (PANDEY et al., 1999). Sistemas que a utilizam tem

como função principal a criação de projetos de estruturas computacionais, sejam processadores

complexos ou sistemas de arquitetura embarcados com poucos recursos disponíveis. Simula-

dores que trabalham com a linguagem VHDL geralmente trabalham diretamente na camada de

hardware da estrutura. Trabalhando em conjunto com simuladores é possível além de proje-

tar sistemas, modelar e testar arquiteturas, validando seu comportamento e testando a resposta

do sistema de acordo com diferentes entradas possíveis. A utilização de simuladores facilita

o desenvolvimento de projetos eletrônicos, pois é possível modelar, testar e revisar novos sis-

temas sem a necessidade de se confeccionar uma estrutura física, o que reduz os custos de

implementação e o tempo gasto, uma vez que é possível projetar uma estrutura e efetuar os tes-

tes imediatamente. Entre os principais simuladores com suporte à linguagem VHDL, pode-se

destacar:

• DIPS for MIPS: An Instrumented VHDL/Corba Kernel for distributed learning in EECS

Em (BUTUCARU, 1999) é apresentado o simulador DIPS for MIPS, o qual implementa

as funcionalidades do processador MIPS descrito por Patterson and Hennessy (PATTER-

SON; HENNESSY, 2008), representando caminho de dados, controle FSM 1 e memória.

O Simulador utiliza um modelo do processador usando um kernel VHDL. Dessa maneira

é possível observar o processador MIPS em nível de hardware. O simulador possibilita

que o usuário execute interações com o sistema por meio de uma interface gráfica, pas-

sando novos parâmetros ao sistema e observando a resposta do sistema com as alterações.

• A Single Clock Cycle MIPS RISC Processor Design Using VHDL

Em (REAZ et al., 2002) é apresentado um processador MIPS utilizando a linguagem

VHDL com o objetivo de realizar a descrição, verificação, simulação e execução do hard-

ware do processador. Um dos diferenciais desse modelo é representação das etapas de

processamento do processador, definidas como instruction fetch, instruction decode, exe-

cution, data memory and write back. Nesse modelo é possível executar a análise de tempo

de execução, funcionalidade e desempenho do projeto descrito e demonstrar a efetividade

do projeto.

1Finite State Machine é um modelo matemático usado para modelar programas de computador e circuitoslógicos sequenciais.(CHOW, 1978)

19

2.3 Simuladores com Ferramentas de Visualização

Dentre as recentes ferramentas desenvolvidas para estudo de arquitetura de computa-

dores, as que mais se destacaram foram as de visualização do funcionamento do processador.

Essas ferramentas facilitam a compreensão da arquitetura por meio de diagramas que abstraem

o funcionamento do processador e focam em suas características básicas, como o fluxo dos

sinais entre as diferentes partes da estrutura e as tarefas específicas de armazenamento de da-

dos e cálculos aritméticos. Entre os principais simuladores com ferramentas de visualização de

caminhos de dados, pode-se destacar:

• MipsIt: A Simulation and Development Environment Using Animation for Computer

MipsIt (KABIR et al., 2011) é um simulador que possibilita uma análise do processador

MIPS utilizando a representação de diagramas de caminho de dados, conforme apre-

sentado na figura 5. Neste simulador são representadas as unidades funcionais como

estruturas de blocos fechados, onde só é relevante para o modelo as entradas e saídas,

abstraindo-se o funcionamento interno das unidades. A simulação do caminho de dados

representa a troca de dados por meio da representação dos bits que são enviados de uma

unidade para outra. A cada etapa da instrução os dados são atualizados. Outra funcio-

nalidade do simulador é a análise dos dados armazenados em cada unidade funcional em

tempo de execução. Ao clicar na unidade é possível visualizar uma tabela com os dados

numéricos de cada instrução executada.

Figura 5: Caminho de dados do simulador MipsIt.

20

• VisiMIPS: Visual Simulator of MIPS 32 Pipelined Processor

O foco do simulador VisiMIPS (BRORSSON, 2002) é representação visual de um ca-

minho de dados multicíclo com estrutura de pipeline, conforme representado na figura

6. Nele diferentes instruções são executadas simultaneamente pelo processador, de ma-

neira a otimizar ao máximo o uso de todas as unidades funcionais, fazendo com que elas

executem suas tarefas independentemente das outras unidades. Assim como os outros

simuladores é possível ao usuário escrever o próprio código e visualizar a simulação do

mesmo no caminho de dados.

Figura 6: Caminho de dados do simulador VisiMIPS.

• WebMIPS: A New Web-Based MIPS Simulation Environment for Computer Archtecture

Education

O simulador WebMIPS (BRANOVIC et al., 2004) tem como foco a execução de um ca-

minho de dados multiciclo com estrutura de pipeline de maneira a detalhar os dados de

cada etapa da instrução. Além do diagrama esquemático do caminho de dados, é possível

acessar também os dados da memória, banco de registradores e memória de instruções.

Em tempo de execução é possível acessar a memória de dados e registradores e visuali-

zar os valores dos bits que formam o código da instrução e a classificação das mesmas

quando são escalonadas pelo processador para a execução em paralelo. A ferramenta foi

desenvolvida para acesso por meio da web (ver figura 7).

21

Figura 7: Interface do simulador WebMIPS.

• MIPS X-Ray: Extensão do simulador MARS para visualização de caminho de dados

A ferramenta desenvolvida nesse trabalho se enquadra na categoria de simuladores com

visualização de caminho de dados. A mesma possui como foco o desenvolvimento de

um caminho de dados que apresente ao usuário a visualização da troca de sinais entre as

unidades funcionais, assim como o entendimento do funcionamento interno das unidades.

A extensão MIPS X-Ray apresenta como nova contribuição para os simuladores com

visualização do caminho de dados uma abordagem diferenciada para o funcionamento

do processador, apresentando os sinais com códigos de cores que identificam os bits da

instrução, a animação dos sinais como um segmento que se desloca auxilia o usuário a

compreender a lógica de como as unidades se relacionam. Uma segunda contribuição é a

apresentação da lógica interna das unidades funcionais, funcionalidade inexistente entre

os simuladores existentes.

22

3 Fundamentação Teórica

Neste capítulo são apresentados os principais conceitos de arquitetura de computadores

envolvidos neste trabalho, especificamente: os conceitos básicos que envolvem a arquitetura do

conjunto de instruções, uma breve descrição das unidades funcionais presentes no processador,

o fluxo de dados entre as unidades funcionais e os diagramas de representação do processador.

3.1 Arquitetura do Conjunto de Instruções

Devido a complexidade envolvida na construção de estruturas computacionais, dife-

rentes níveis de abstração são utilizados, de forma que os detalhes dos níveis inferiores ficam

ocultos com o objetivo de oferecer um modelo mais simples para os níveis superiores. Uma

das abstrações mais importantes é a interface entre hardware e software, sendo definida como

a arquitetura do conjunto de instruções. Com essa abstração é possível trabalhar o software

sem entrar nos aspectos de hardware da arquitetura. A forma utilizada para criar essa interface

consiste na utilização de comandos de alto nível para indicar ao processador qual operação exe-

cutar, os quais são chamados de Instruction Set Architecture ISA. O conjunto de instruções da

arquitetura disponibilizado ao programador possibilita a criação de programas que posterior-

mente serão convertidos em linguagem de máquina pelo compilador e executados no processa-

dor (TANENBAUM, 1984).

A arquitetura do conjunto de instruções fornece comandos para cálculos aritméticos,

armazenamento de dados, operação de dispositivos de entrada e saída e alocação de memória.

Em geral, a grande maioria dessas operações são executadas pelo sistema operacional, sendo

transparente ao programador que apenas tem acesso aos comandos básicos na linguagem de-

senvolvida para a arquitetura.

Na arquitetura MIPS, os comandos da arquitetura de conjunto de instruções são re-

presentados por mnemônicos que identificam os comandos seguidos de parâmetros necessários

às suas execuções, conforme apresentado na figura 8. Pode-se listar os comandos possíveis

no conjunto de instruções em grupos distintos de acordo com as operações que executam (PAT-

TERSON; HENNESSY, 2008), especificamente: transferência de informação, cujas instruções

são responsáveis por acessar as informações em memória e enviá-las para registradores para

que os dados armazenados possam ser utilizados pelo processador; operações aritméticas, res-

ponsáveis pelos cálculos básicos de adição, subtração, divisão e multiplicação no processador;

23

operações lógicas e de comparação, são responsáveis por executar operações boleanas e de

comparação entre operadores; operações de deslocamento de bits são responsáveis pelas opera-

ções de shift, que movem bits para a esquerda ou a direita de sua posição original, preenchendo

as posições anteriormente ocupadas com zeros; instruções de salto alteram o fluxo de execução

normal das instruções, criando desvios na sequência de execuções. O ponteiro que indica a pró-

xima instrução a ser executada é modificado para a posição indicada pela instrução de desvio,

fazendo com que o programa seja executado daquele ponto em diante.

Figura 8: Conjunto de instruções básicas da arquitetura (PATTERSON; HENNESSY, 2008).

24

3.2 Formato das Instruções

O conjunto de instruções apresenta uma sintaxe mais próxima à linguagem natural,

com objetivo de tornar mais fácil a sua utilização por aqueles que irão desenvolver os progra-

mas. Entretanto para ser executada no processador uma instrução deve ser convertida para a

linguagem de máquina por um compilador. Na arquitetura MIPS cada instrução é formada por

um conjunto de 32 bits e apesar da existência de diferentes tipos de instruções, a quantidade de

bits para a escrita da instrução é sempre a mesma (HAYES, 2002). Os bits são organizados de

maneira que cada conjunto de bits forneça uma informação da instrução para a unidade funci-

onal que vai utilizá-la. A função de cada conjunto de bits irá variar de acordo com a instrução,

sendo que essa configuração é denominada formato da instrução (TANENBAUM, 1984). A

sequência de bits de uma instrução é subdividida em campos que possuem finalidades especí-

ficas na estrutura do processador. Esses campos podem ser utilizados da maneira descrita ou

aglomerados para armazenar um endereço de memória ou informação que será usada direta-

mente pelo processador. Segundo (PATTERSON; HENNESSY, 2008), os campos da instrução

se subdividem em:

• op: Com 6 bits de largura, neste campo é armazenado o código da operação básica da

instrução, chamada de opcode. É no campo op que se especifica qual instrução será

executada e quais sinais a unidade de controle deverá enviar para as demais unidades;

• rs: Com 5 bits de largura, esse campo armazena o endereço do primeiro registrador utili-

zado na instrução;

• rt: Com 5 bits de largura, esse campo armazena o endereço do segundo registrador utili-

zado na instrução;

• rd: Com 5 bits de largura, esse campo armazena o endereço do terceiro registrador utili-

zado na instrução;

• shamt: Com 5 bits de largura, esse campo indica a quantidade de bits que serão deslo-

cados de sua posição original, sendo que os bits adicionados com o deslocamento são

completados com zero;

• func: Com 6 bits de largura, esse campo armazena o complemento da operação no campo

op. Enquanto o campo op define de maneira global o funcionamento do processador, o

campo func define especificamente o funcionamento da unidade lógica e aritmética. Os

bits do campo func são enviados para a unidade de controle da ALU diferentemente do

campo op que é enviado para a unidade de controle principal.

25

Para que todas as instruções do conjunto da arquitetura possam ser executadas man-

tendo o tamanho de 32 bits é necessário que a configuração dos campos possa ser alterada de

acordo com o tipo de tarefa que o processador irá executar. Essas alterações acontecem de-

vido às particularidades de cada instrução executada e os dados que elas devem fornecer para

o processador. Existem três tipos diferentes de instruções, classificados de acordo com as in-

formações que são utilizadas para a execução pelo processador. As instruções na arquitetura

MIPS são definidas como do tipo R, tipo I e do tipo J (PATTERSON; HENNESSY, 2008). Em

todas as instruções os primeiros 6 bits são utilizados para identificar o operador da instrução,

enquanto os bits subsequentes variam de acordo com o tipo.

As instruções do tipo R (Register), usam em seu processamento três registradores. Para

isso é necessário que 3 campos de 5 bits cada possam endereçar esses registradores. Os dois pri-

meiros registradores serão utilizados para endereçar os registradores de origem, que armazenam

os dados que serão processados e o terceiro registrador é utilizado para armazenar o produto da

operação. As instruções do tipo R são as mais utilizadas na arquitetura, compreendendo entre

outras as operações lógicas e aritméticas que utilizam mais que dois registradores.

As instruções do tipo I (Immediate), possuem esse nome pois trabalham com leitura

de informações diretamente no código da instrução. Neste formato são reservados dois campos

para o armazenamento do endereço dos registradores, enquanto os bits restantes da instrução

são utilizados para o armazenamento de uma constante ou de um endereço de memória. Ope-

rações de soma com valores constantes, comparações de valores e armazenamento de dados na

memória são exemplos desse tipo de instrução.

As operações do tipo J (Jump), efetuam desvios no fluxo normal de execução. Neste

caso, a sequência de instruções é desviada para um determinado ponto definido como um ende-

reço. Além disso, todos os bits, exceto os bits de opcode, são utilizados para endereçar a posição

para onde irá ocorrer o desvio. As instruções do tipo J executam desvios incondicionais, isso

significa que eles acontecem sem a necessidade de qualquer teste ou comparação.

Tabela 1: Formato de instruções MIPS.

nome Campos Comentários

6 bits 1 5 bits 2 5 bits 5 bits 5 bits 6 bits intruções MIPS tem 32 bitsFormato R op rs rt rd shamt funct Instruções aritméticasFormato I op rs rt endereço/imediato Formato imediatoFormato J op endereço de destino Formato jump

Fonte: (PATTERSON; HENNESSY, 2008)

26

3.3 Unidades Funcionais do Processador MIPS e componentesauxiliares

O funcionamento correto e eficiente de um processador depende principalmente do

conjunto de instruções da arquitetura, tempo de ciclo de clock e o projeto específico da arqui-

tetura (PATTERSON; HENNESSY, 2008). O projeto da arquitetura consiste na elaboração de

unidades funcionais que executam tarefas específicas para a execução do processamento como

um todo. Fazem parte do caminho de dados as unidades funcionais e as conexões por onde tran-

sitam os dados e sinais de controle. Além da modelagem das unidades funcionais e caminhos

de dados deve se levar em questão a necessidade de criar um modelo que seja abrangente o sufi-

ciente para executar todas as instruções da arquitetura, considerando que cada instrução possui

diferentes parâmetros e exige comportamentos distintos das unidades funcionais. As unidades

funcionais da arquitetura MIPS consistem em dois tipos diferentes de elementos lógicos: os

elementos que operam modificações sobre os dados e os elementos que armazenam os dados.

Os elementos que operam valores são combinacionais, ou seja os elementos da saída dependem

exclusivamente dos elementos da entrada, como por exemplo a unidade lógico aritmética, os so-

madores e os multiplexadores presentes no caminho de dados. Os elementos que contêm estado

são aqueles dotados de armazenamento interno, sendo responsáveis por armazenar as informa-

ções que serão utilizadas pelas unidades combinacionais. São exemplos desse tipo de elemento

as memórias de dados, memória de instruções e banco de registradores (TANENBAUM, 1984).

Dentre as unidades funcionais presentes na arquitetura MIPS, tem-se a memória de

instruções e de dados, unidade lógico aritmética, banco de registradores, contador de programa,

unidade de controle e multiplexadores (PATTERSON; HENNESSY, 2008), os quais são breve-

mente descritos a seguir:

• Contador de programa (PC): é um registrador utilizado para armazenar o endereço da

próxima instrução que será executada. Este registrador irá enviar o valor do endereço

armazenado para a estrutura que armazena todas as instruções do programa, denominada

memória de instruções. Ao final do ciclo da instrução o contador de programa irá receber

a atualização do incremento do próximo endereço ou no caso de uma operação de desvio,

do endereço indicado pelo desvio;

• Memória de instruções: esta unidade funciona como um banco de memória específico

para o armazenamento das instruções. Uma decisão de projeto foi a de separar unidades

do mesmo tipo mas com funções diferentes, causando assim a redundância de unidades.

Esse é o caso da memória de instruções e memória de dados, ou seja, como para cada

27

instrução é necessário executar a leitura da instrução e posteriormente a leitura dos dados

necessários para a sua execução, o banco de memórias de instruções é separado do banco

de memória de dados. Os bits da instrução armazenados na memória são enviados para

as demais unidades funcionais para que a operação descrita na instrução seja executada.

A memória de instruções recebe como entrada o valor do contador de programa e fornece

como saída os 32 bits da instrução contida neste endereço;

• Banco de registradores: os registradores de uso geral de 32 bits estão localizados no

banco de registradores. Neste banco, qualquer registrador pode ser lido ou escrito desde

que se forneça o endereço do registrador que se deseja acessar (ver Figura 9). O banco

de registradores possui três entradas de endereços que podem ser utilizadas, sendo que

essas entradas definem quais registradores serão utilizados na operação. O banco de

registradores possui também uma entrada de dados para o envio de informações para

serem armazenadas em um dos registradores acessados. São enviados também ao banco

sinais de controle para definir o tipo de operação sobre o registrador como de leitura ou

escrita. O banco apresenta também duas saídas de dados para enviar os dados contidos

nos registradores, sendo que essas saídas se conectam à unidade lógico e aritmética;

• Unidade lógico aritmética: é a responsável pelas operações de soma, subtração, multi-

plicação, divisão e comparações lógicas. A ALU possui como entrada dois sinais de 32

bits e produz um sinal de saída também de 32 bits, gerando também um sinal de 1 bit caso

o resultado da operação executada seja zero. Devido ao grande número de operações em

uma ALU, a mesma não é controlada diretamente pela unidade de controle, mas por uma

unidade auxiliar que define a operação a ser realizada (HAYES, 2002). A unidade

Figura 9: Porta de leitura e escrita para um banco de registradores, (PATTERSON; HEN-NESSY, 2008).

28

lógico aritmética recebe seus sinais do banco de registradores, podendo também receber

um sinal de entrada diretamente do banco de memória de instruções no caso de instru-

ções do tipo imediato. Como saída, a ALU envia um sinal para o banco de memória ou

diretamente para o banco de registradores;

• Unidade de controle: a unidade de controle é responsável pelo envio dos sinais que de-

finem as operações executadas pelas demais unidades funcionais (ver Figura 10). O sinal

de entrada da unidade de controle é o responsável por indicar quais sinais serão ativa-

dos, sendo fornecido pelo opcode da instrução, formado pelos 6 primeiros bits (HAYES,

2002). A saída da unidade de controle são os 9 sinais que controlam as demais unidades.

É graças a unidade de controle que o projeto do caminho de dados consegue utilizar as

mesmas unidades funcionais para executar diferentes instruções;

• Memória de dados: a memória de dados tem como função armazenar os dados que serão

persistidos após o término da instrução. Os dados persistidos dessa forma se mantêm até

que sejam sobrescritos por outras ações de escrita, ou até que a fonte de energia seja

desativada. A memória de dados possui dois sinais de entrada, o endereço de memória

que será acessado e o dado que será armazenado na mesma. Além disso

Figura 10: Diagrama lógico da Unidade de controle, (PATTERSON; HENNESSY, 2008).

29

são enviados também dois sinais de controle para a unidade que definem a operação como

escrita ou leitura. Como sinal de saída tem-se o valor do dado referente ao endereço de

memória fornecido;

• Controle da ALU: esta unidade tem como função enviar o sinal que irá definir a operação

da ALU (ver Figura 11). Para isso, a unidade de controle envia um sinal de 2 bits que

define uma operação do tipo R, de leitura, escrita ou de comparação. Baseado neste sinal,

a unidade de controle da ALU analisará os bits do campo func da instrução para então

enviar o sinal para a ALU que irá enviar o sinal para a operação específica. A escolha de

vários níveis de decodificação para o controle, ou seja, a unidade de controle enviar sinais

para uma unidade de controle secundário que ativa uma unidade é comum neste tipo de

projeto, pois reduz o tamanho da unidade de controle principal ao mesmo tempo em que

favorece um melhor desempenho da mesma;

• Unidade de extensão de sinal: em algumas situações, todos os 32 bits de um registrador

são utilizados para armazenar um determinado valor. A função dessa unidade é tratar o

sinal de entrada, que não utiliza todos os 32 bits da sequência de bits, e completar todos

os bits disponíveis. Especificamente, quando esse sinal apresenta um bit de sinalização,

o mesmo deve ser posicionado no último bit da sequência. Para que isso aconteça, a

unidade de extensão de sinal preenche os bits disponíveis com zeros ou uns de acordo

com o ultimo bit do sinal e aloca o bit de sinalização na última posição da sequência,

dessa maneira o sinal do valor modificado não é perdido;

• Shift left: a função dessa unidade é executar o deslocamento dos bits da sequência para

a esquerda preenchendo a posição dos bits que se tornaram vazios com zeros;

Figura 11: Diagrama lógico da unidade de controle da ALU (PATTERSON; HENNESSY,2008).

30

• Somadores: em diferentes partes da caminho de dados é necessário executar a soma

de sinais. Para essa função são implementados somadores, especializações da ALU que

possuem apenas a função de soma de sinais. Os somadores recebem dois sinais distintos e

retornam como saída a soma dos sinais. Estes somadores são independentes da estrutura

da ALU, são utilizados em pontos distintos do caminho de dados apenas para a soma

de sinais, diferente da ALU que efetua além das operações de soma, multiplicações e

divisões, assim como das operações lógicas.

• Multiplexadores: os multiplexadores são unidades que determinam dentre diferentes si-

nais, quais serão utilizados no sistema. Um sinal de controle é enviado para o multiplexa-

dor, definindo portanto qual dado de entrada no mesmo irá ser transmitido pela saída. Os

multiplexadores são de grande importância para o controle do fluxo de dados, pois é por

meio deles que a unidade de controle habilita ou desabilita os sinais que serão utilizados

nas diferentes unidades funcionais;

3.4 Diagrama de Caminho de Dados do Processador

Os diagramas de caminho de dados são estruturas que representam as conexões entre

as unidades funcionais (ver Figura 12), essas estruturas definem como o sistema irá responder

Figura 12: Diagrama do caminho de dados da arquitetura MIPS, baseado em (PATTERSON;HENNESSY, 2008).

31

de acordo com os sinais fornecidos pela instrução armazenada na memória de instru-

ções. A modelagem do caminho de dados define como as unidades serão controladas, quais

unidades deverão ser replicadas e quais funcionalidades poderão ser implementadas. Existe

um equilíbrio entre o conjunto de instruções a serem implementadas, o tamanho de bits dos

registradores e o caminho de dados, todos esses fatores definem a arquitetura do processador.

A arquitetura MIPS é constituída de dois blocos de memória, um banco de registrado-

res, uma unidade lógico aritmética, uma unidade de controle principal e uma auxiliar, unidades

de deslocamento de bits, unidades de extensão de sinal, somadores e multiplexadores. Os bits

que definem a instrução, armazenados na memória de instruções, são enviados às demais unida-

des funcionais. Cada campo da instrução é enviado para uma unidade funcional, os bits do op-

code são enviados para a unidade de controle, os bits referentes aos endereços dos registradores

são enviados ao banco de registradores e o campo function será enviado à unidade de controle

da ALU. A utilização dos bits por cada unidade funcional será definido pelos sinais enviados

pela unidade de controle. É função da mesma identificar o tipo de instrução por meio dos bits do

opcode e comandar as demais unidades para efetuar uma determinada operação de acordo com

o comportamento esperado para aquele tipo de instrução (PATTERSON; HENNESSY, 2008).

32

4 Mips X-Ray

Este capítulo apresenta a extensão para visualização de caminho de dados MIPS X-

Ray, descrevendo-se o seu funcionamento, detalhes da implementação e as características da

aplicação. Serão apresentadas também as características básicas do MARS, simulador da ar-

quitetura MIPS que irá receber a extensão desenvolvida. O objetivo da extensão é entregar ao

usuário uma representação gráfica do funcionamento interno de um processador da arquitetura

MIPS. A extensão efetua a leitura da instrução carregada na memória e representa por meio

de um diagrama de blocos, denominado caminho de dados, uma animação que ilustra como

os sinais trafegam pelas diferentes unidades funcionais do processador. A representação pode

ser tanto do processador, demonstrando a troca de dados entre as unidades funcionais, quanto

pelo detalhamento interno das unidades funcionais, apresentando a entrada e saída dos sinais na

unidade e a sua lógica de execução por meio do caminho de dados interno.

Na primeira fase do trabalho foi executada uma análise da implementação do simula-

dor MARS, com o objetivo de identificar os modelos de dados que implementam as unidades

de memória de instruções e banco de registradores. Foram analisadas também a estrutura do

formato das instruções da arquitetura, com o objetivo de identificar e classificar o tipo de ins-

trução a ser executada pelo simulador. Em seguida foi feito o estudo dos diagramas de caminho

de dados do processador utilizado (PATTERSON; HENNESSY, 2008), com o objetivo de criar

um modelo que contemple todas as diferentes configurações de operações do processador. De

acordo com o tipo de saída das unidades funcionais são definidas cores para os sinais que são

trocados entre as unidades. As cores desses sinais estão relacionadas aos bits da instrução que

são apresentados na parte inferior da tela com o formato de uma legenda, cada bit possui a cor

que corresponde ao sinal no caminho de dados. O modelo foi desenvolvido tanto para o cami-

nho de dados do processador completo quanto para as unidades funcionais de controle e banco

de registradores. Com base nesse modelo foi iniciado o desenvolvimento da ferramenta pro-

posta. A seguir são descritas as etapas de desenvolvimento do trabalho, as decisões de projeto

e a descrição do desenvolvimento do código implementado.

4.1 Análise do Simulador MARS

No projeto do simulador MARS foi assumido o compromisso de fornecer ao usuá-

rio uma ferramenta em que ele pudesse escrever os seus códigos, compilá-los, simular o real

33

comportamento da arquitetura utilizando o código criado e visualizar os dados gerados. Para

alcançar todos esses objetivos foi desenvolvido um sistema constituído por ferramentas de edi-

ção de texto, um montador Assembly, estruturas para simulação das instruções e estruturas de

hardware da arquitetura. O usuário pode executar o código criado, instrução por instrução, e

visualizar as mudanças dos dados através de uma tabela de registradores e de endereços de

memória localizada na interface do simulador. É possível também analisar a saída dos dados

gerados pela unidade lógica e aritmética quando os mesmos são armazenados no banco de regis-

tradores ou memória. O principal foco do simulador MARS é o educacional, para isso ele utiliza

a arquitetura MIPS 32, que se baliza pela simplicidade, motivo para a sua grande utilização no

ensino de arquitetura de computadores. Como o simulador foi desenvolvido na linguagem Java

utilizando uma licença open source é possível que a comunidade contribua para a implemen-

tação de melhorias das funcionalidades existentes e a criação de novas funcionalidades para o

simulador.

O sistema apresenta duas possibilidades de simulação do código, quais sejam, a exe-

cução contínua ou passo a passo. Na execução passo a passo a cada instrução executada a

simulação é pausada, possibilitando ao usuário a visualização do estado do processador a cada

instrução (VOLLMAR; SANDERSON, 2006).

Uma possibilidade fornecida pelos desenvolvedores do simulador consiste na criação

de ferramentas por parte da comunidade. Essas ferramentas são criadas por meio de uma classe

no código fonte que fornece uma tela padrão e a implementação que possibilita a sincronização

da ferramenta que será desenvolvida ao simulador MARS. Pela interface do MARS é possível

analisar em modo de execução passo a passo o estado do banco de registradores e da memória

de dados. Com a utilização desses recursos foi possível a criação da ferramenta de visualização

do caminho de dados do processador.

4.2 Codificação da extensão MIPS X-Ray

Para iniciar o desenvolvimento da extensão MIPS X-Ray, a primeira atividade foi uma

análise do código fonte do simulador MARS, com foco especificamente na implementação das

estruturas de hardware e nas instruções. Para executar corretamente uma representação do cami-

nho de dados é fundamental a leitura dos sinais das unidades funcionais e dos bits da instrução

que está sendo executada pela aplicação. O simulador MARS implementa a unidade funcional

banco de registradores por meio de uma lista de registradores que possuem os atributos nome,

endereço e valor. Para acessar os seus dados é necessário enviar como parâmetro o endereço

34

que corresponde ao registrador que se deseja acessar, o banco de registradores devolve então o

valor armazenado naquele registrador. O acesso à memória é implementado de forma a permitir

seu acesso em tempo real pelas estruturas do simulador. Esse acesso é executado por meio da

implementação de uma metodologia de tratamento de eventos da linguagem Java denominada

Observers (ORACLE, 2014) e a partir do mesmo é possível visualizar qualquer alteração do

estado atual dos dados.

Para parametrizar os valores que são utilizados na animação do caminho de dados é

necessário obter o valor da próxima instrução a ser executada na memória de instruções. A

implementação da memória de instruções assim como a memória de dados é feito por meio

do tratamento de eventos. Um receptor de eventos foi instanciado na classe que implementa a

animação do caminho de dados de forma a perceber qualquer alteração ou leitura na memória

de instruções e capturar o valor da próxima instrução a ser executada. Dessa forma, uma nova

instância da animação é criada para cada evento de mudança do endereço da instrução pelo

simulador. No momento em que a memória de dados é atualizada, uma verificação do tipo da

instrução é executada para que a instrução correta seja definida na animação.

4.3 Análise dos Bits das Instruções

A instrução do que será executado pela unidade funcional é armazenada na forma de

um conjunto de bits na unidade denominada memória de instruções. Essas instruções são cria-

das a partir do código fonte escrito pelo usuário, convertidas em linguagem de máquina e depois

em um conjunto de bits pelo compilador para que o hardware seja capaz de efetuar a leitura dos

dados e executar a instrução. Na arquitetura MIPS 32, a instrução é formada por 32 bits e dife-

rentes conjuntos de bits são distribuídos como sinais para as diferentes unidades funcionais que

compõem o processador. Para desenvolver um modelo que seja capaz de representar correta-

mente todo o funcionamento do processador é necessário mapear todas as instruções e conjunto

de bits utilizados pela arquitetura. Para fazê-lo foram utilizadas as definições dos bits da arqui-

tetura conforme definido em (PATTERSON; HENNESSY, 2008). Os bits das instruções são

divididos em diferentes campos que possuem informações específicas para as unidades, entre

elas o campo opcode, definido como os 6 primeiros bits que definem para a unidade de controle

o tipo da instrução, o campo function, que define a operação da unidade de controle da ULA e os

endereços dos registradores. Esses dados foram armazenados em um arquivo de configuração

XML para servirem de base de dados para o aplicativo. A escolha de utilizar um arquivo XML

foi tomada devido a necessidade de isolar os dados da lógica do aplicativo. Neste arquivo de

configurações foram armazenados também os parâmetros da animação de cada trecho de sinal

35

percorrido no caminho de dados. Nele são definidas as coordenadas dos trechos que o sinal irá

percorrer durante a animação, assim como a cor que irá identificar cada tipo de dado de acordo

com a instrução. As cores utilizadas são mapeadas por uma legenda que apresenta os 32 bits

da instrução da operação, assim como as cores utilizadas para identificar o sinal lógico baixo

ou alto enviado pela unidade de controle para as demais unidades. Os modelos gerados para

a animação caracterizam as instruções em seis diferentes tipos, as operações do tipo R, tipo I,

tipo J e também as operações do tipo load, store e branch. Essas 6 classes abrangem todas os

tipos de instruções do conjunto de arquitetura MIPS.

Para o entendimento de como os bits da instrução influenciam o funcionamento de

cada unidade funcional é necessário analisar o diagrama do caminho de dados do processador,

por meio do qual se visualiza as conexões entre as unidades e a troca de dados e sinais entre

elas. Pode-se citar como um exemplo dessas conexões a interligação da saída da memória de

instruções com a unidade de controle. Nesta conexão forma-se um caminho por onde os 6

primeiros bits da instrução serão enviados para a unidade de controle. Esses bits irão informar

a unidade o tipo de instrução que será executada para que a unidade possa enviar os sinais de

controle para as demais unidades. Por meio deste exemplo pode-se ilustrar como a informação

presente nos bits de instrução são importantes para o funcionamento do hardware.

4.4 Modelagem da Ferramenta de Visualização do Caminho deDados

A aplicação foi desenvolvida utilizando a linguagem Java, tomando-se como base para

a implementação o simulador MARS. O ambiente de desenvolvimento utilizado foi o Eclipse e

para a execução da animação foi utilizada a biblioteca nativa do Java Graphics. Foram utilizadas

as classes MemoryAccessNotice para capturar as modificações da memória e a classe Memory

para acessar os dados da memória de instruções.

A extensão desenvolvida funciona em conjunto com o simulador MARS, de onde ob-

tém os dados armazenados em tempo de execução para detectar o comportamento do proces-

sador e executar a animação do funcionamento do processador. Uma vez que a extensão se

conecta ao MARS ela passa a observar qualquer atualização da memória de instruções. No

momento em que uma nova instrução é lida, a extensão efetua a leitura dos bits da instrução

em memória com o objetivo de identificar as seguintes informações: o tipo de instrução a ser

executada, o nome da instrução e os endereços dos dados que serão utilizados. Com esses da-

dos é possível mapear o comportamento de todo o caminho de dados e apresentar ao usuário

36

um diagrama de caminho de dados dinâmico, utilizando um código de cores e legendas para

representar os sinais e dados que entram e sai de cada unidade funcional. Para a representação

do caminho de dados foram determinados dois níveis de detalhamento. No primeiro foi feito

uma abordagem macro do funcionamento do processador, apresentando a comunicação das uni-

dades funcionais por meio da troca de sinais entre elas. Na segunda abordagem o foco está no

interior das unidades de controle e banco de registradores. Nela o usuário pode visualizar o

funcionamento interno das mesmas e como elas respondem aos dados de entrada e sinais de

controle.

A interface do aplicativo consiste em uma tela com a representação de todas as uni-

dades funcionais e as conexões entre elas, um botão para a compilação do código e um botão

para o início da próxima instrução da arquitetura, além dos botões de reset, conexão com o

simulador e ajuda. A figura 13 exibe a interface desenvolvida para a ferramenta MIPS X-Ray.

Para a visualização das unidades funcionais basta clicar sobre elas e uma nova janela irá se

abrir apresentando o caminho de dados da unidade específica. Para representar os sinais que

estão sendo enviados e recebidos foi desenvolvida uma animação de linhas coloridas que cami-

nham entre as conexões das diferentes unidades funcionais, dessa maneira é possível visualizar

o comportamento do processador analisando os sinais que trafegam pelos barramentos.

4.5 Modelagem da animação do caminho de dados

A animação do caminho de dados consiste na representação dos sinais trocados entre

as unidades funcionais sobre a influência dos bits da instrução. Para modelar a animação utiliza-

mos a biblioteca nativa do Java denominada Graphics. Com ela é possível desenhar em painéis,

denominados containers, diferentes formas geométricas. Especificamente, na implementação

realizada utilizou-se círculos. A modelagem do método que efetua a animação consiste em in-

serir na tela da posição definida uma sequência de círculos em uma linha vertical ou horizontal

criando assim a percepção de uma linha que cresce em uma determinada direção. A animação

dos diferentes segmentos de reta é executada de maneira simultânea por meio de contadores que

armazenam a posição inicial e final da reta, assim como a posição do instante do final do seg-

mento que cresce. Os dados de cada segmento são armazenados em uma lista que é carregada

de acordo com a lógica da animação, que define que um segmento só irá entrar em atividade no

momento em que um determinado segmento chegue ao fim.

37

Figura 13: Interface gráfica da extensão MIPS X-ray.

Todos esses dados são separados da lógica de implementação por meio de arquivos

XML que armazenam as coordenadas dos segmentos de reta da animação, a sequência em que

esses segmentos serão executados, código de cores para cada segmento de acordo com o tipo

de instrução e informações sobre as sequências de bits da instrução para identificação do tipo

da operação. Para criar o efeito de movimento dos segmentos de reta foi utilizado a classe

Timer, responsável por criar uma tarefa que interrompe a execução dos desenhos na tela, caso

contrário toda a instrução ocorreria rápido demais para a visualização. Uma vez que o sinal

foi percorrido até o seu destino, o efeito de animação deixa de ocorrer, para isso o desenho

da linha é executado simultaneamente. A cada ativação da tarefa pelo objeto Timer, ocorre a

inclusão dos desenhos de cada linha de fluxo, sendo necessário que cada segmento do desenho

aconteça independentemente. Para isso cada segmento foi mapeado no arquivo de configuração,

um exemplo da configuração pode ser visto na Figura 14. Para representar a lógica de como

as unidades se comunicam existe uma sequência lógica com que os segmentos de reta são

inicializados. Por exemplo, em uma porta AND o sinal de saída só irá ser ativado após o

momento em que os dois sinais cheguem nas entradas. Um outro artifício para representar o

funcionamento são as cores dos segmentos, utilizando o mesmo exemplo da porta AND, se os

38

Figura 14: Parâmetros de configuração de um segmento de animação.

segmentos que representam o sinal de entrada forem da cor que representa nível alto,

a cor do segmento de saída será de nível alto, caso contrário a cor será a correspondente a nível

lógico baixo. O mesmo ocorre para todas as unidades: todos os sinais obedecem uma sequência

lógica de acontecimentos e cores que ilustram o tipo de sinal que irá ser gerado. Todas essas

informações são organizadas no arquivo de configuração XML, e são carregados de acordo com

o tipo de instrução. Uma vez que esses dados são carregados do arquivo para a aplicação cada

segmento é implementado por um objeto que encapsula suas coordenadas, as cores, direção e

sentido, assim como o seu estado atual, ou seja, se o trecho do segmento já foi completado,

está acontecendo ou se não foi sequer iniciado. Com esses parâmetros é possível executar

a animação de maneira iterativa, garantindo que os segmentos que já chegaram ao seu destino

permaneçam desenhados na imagem, os segmentos que ainda estão em direção ao destino sejam

incrementados suavemente de forma a causar a sensação que estão se movendo em direção ao

destino e por fim que os segmentos que ainda não foram ativados se mantenham inativos até

que as dependências para a sua ativação, os segmentos antecessores, sejam concluídos.

4.6 O Caminho de Dados Interno às Unidades Funcionais

Além do caminho de dados do processador como um todo, uma segunda abordagem

da ferramenta de visualização é a análise do funcionamento interno das unidades funcionais,

oferecendo ao usuário a visualização em formato caixa branca de tais unidades. Devido ao

nível de abstração dado para o caminho de dados, seria inviável efetuar uma análise em nível

macro da conexão entre as diferentes unidades funcionais ao mesmo tempo em que se analisa o

funcionamento interno das mesmas. Entretanto é possível realizar esse estudo utilizando ferra-

mentas computacionais, que efetuem a redução do nível de abstração do caminho de dados de

39

forma a analisar o funcionamento das unidades funcionais de maneira individual. Para isso o

usuário seleciona a unidade funcional e um novo caminho de dados é representado em uma tela

a parte para apresentar o interior do bloco. As telas são independentes do caminho de dados

principal e podem ser executadas de maneira simultânea, apresentando o funcionamento de di-

ferentes unidades ao mesmo tempo, bastando para isso que o usuário clique sobre a unidade que

deseja o detalhamento no caminho de dados principal. A implementação da unidade funcional

acontece de maneira similar à do caminho de dados do processador. Um novo arquivo de confi-

guração foi desenvolvido para cada unidade, nele são definidos os segmentos de animação para

a animação. Na extensão MIPS X-Ray foram implementados o caminho de dados do banco de

registradores, unidades de controle principal e unidade de controle da ALU.

4.7 Caminho de dados do banco de registradores

O banco de registradores é a unidade que possui como função alocar os registradores,

as estruturas de armazenamento rápido do processador. Nela os dados que serão utilizados

imediatamente pelo processador serão armazenados. Os componentes que fazem parte do banco

de registradores são 32 registradores, estruturas de memória de 32 bits, dois multiplexadores de

32 entradas que servem para controlar o valor de qual registrador será enviado para a saída

da unidade, um decodificador de 1 entrada para 32 saídas que tem como função indicar qual

registrador vai ser escrito na operação de gravação e portas lógicas do tipo AND na entrada

de cada registrador para o tratamento dos sinais de controle. O banco de registradores possui

como sinais de entrada os endereços dos registradores de leitura, o endereço do registrador de

escrita e o dado que será armazenado no registrador de escrita. O sinal de controle é um sinal

que define se a operação realizada será de leitura ou escrita. Como saídas tem-se o valor dos

registradores indicados pelos endereços de entrada. Um diagrama esquemático da estrutura do

banco de registradores pode ser vista na figura 15. O banco de registradores possui duas etapas

na execução das instruções, uma operação de leitura e uma de escrita. A operação de leitura

consiste no envio dos dados dos registradores para as saídas da unidade funcional. Para isso os

endereços dos registradores que se deseja obter são enviados para cada um dos multiplexadores.

Esses endereços irão definir qual registrador será enviado na saída do multiplexador. A operação

de escrita consiste no armazenamento do valor na entrada escrita de dados para o registrador

indicado pelo endereço de escrita. Para executar essa operação o endereço é enviado para a

entrada de um decodificador e as saídas do mesmo apresentarão sinal lógico baixo, exceto a

saída correspondente ao endereço do registrador. As saídas do decodificador são enviadas para

portas AND, uma entrada dessa porta vem do sinal do decodificador e a outra do sinal de

40

...

REGISTRADOR 2

REGISTRADOR 31

REGISTRADOR 32

REGISTRADOR 1

ENDEREÇO

REGISTRADOR 2

ENDEREÇO

REGISTRADOR 1

1

...DECODIFICADOR1 PARA N

2

32

31

ESCRITA

DE DADOS

DATA

CTRL

DATA

DATA

DATA

DATA

CTRL

CTRL

CTRL

CTRL

REGISTRADOR

DE ESCRITA

SINAL DE CONTROLEESCRITA

Figura 15: Caminho de dados do banco de registradores. Adaptado de (PATTERSON; HEN-NESSY, 2008).

controle de escrita. Quando os dois sinais de entrada da porta AND estiverem em nível

lógico alto a saída da porta irá enviar um sinal para permitir que o valor na entrada dados do

registrador seja escrito.

4.8 Unidade de controle

A unidade de controle define o comportamento das demais unidades funcionais através

das suas saídas. Os componentes que fazem parte da unidade de controle são 4 portas do

tipo AND com 6 entradas cada e 2 portas do tipo OR com 2 entradas cada. Foram utilizadas

também portas de negação na entrada de algumas portas AND, conforme a Figura 16. Os

sinais de entrada da unidade são os 6 primeiros bits da instrução, denominados opcode, como

saída tem-se 9 sinais de controle para as demais unidades funcionais que possuem a seguinte

denominação:

• RegDst é enviado para o multiplexador que controla de onde será lido o endereço do

registrador de escrita do banco de registradores;

• ALUSrc é enviado para o multiplexador que controla a origem do sinal que será enviado

para a segunda entrada da ALU;

41

• MemToReg é enviado para o multiplexador posicionado após a memória de dados, a sua

função é controlar se o valor enviado como dado para a escrita em registrador irá vir

diretamente da saída da ALU ou da memória de dados;

• WriteReg é o sinal que define que a operação no banco de registradores será de escrita;

• ReadMem define para a memória de dados que a operação a ser executada será a de leitura;

• WriteMem define para a memória de dados que a operação a ser executada será a de

escrita;

• Branch é o sinal que é enviado para a porta AND que controla a próxima instrução que

será executada pelo processador;

• opALU0 e opALU1 são enviados para a unidade de controle da ALU que tem o seu fun-

cionamento descrito na próxima seção.

4.9 Unidade de controle da ALU

A unidade lógica aritmética possui uma unidade de controle especializada para definir

as suas operações por meio de uma sequência de bits. São componentes da unidade de controle

da ALU assim como a unidade de controle portas lógicas do tipo AND e do tipo OR (figura 17).

A unidade de controle da ALU recebe como sinais de entrada os 4 bits finais da instrução

Figura 16: Caminho de dados da unidade de controle. Adaptado de (PATTERSON; HEN-NESSY, 2008).

42

denominado function e recebe também os sinais AluOp0 e AluOp1 da unidade de

controle, fornecendo como saída os bits de controle op1, op2 e op3 para a ALU, os quais são

utilizados para definir qual será a operação executada pela unidade lógica aritmética. Apesar

da definição do tipo da instrução ocorrer pelos 6 primeiros bits, estes não são os únicos bits

que definem o comportamento do processador. Uma segunda unidade de controle para a ALU

é utilizada para definir o subtipo da instrução a ser executada. O conjunto dos 6 ultimos bits,

denominado function, assim como os sinais do controle principal são enviados para o controle

da ALU, como saída esta unidade envia o sinal para definir o subtipo da operação executada na

ALU. Apenas nas operações do tipo R os 6 últimos bits da instrução têm a função de indicar a

operação para a ALU. Isso acontece pois apenas as operações desse tipo utilizam a ALU para

funções específicas que necessitam de um controle próprio. Desses 6 bits apenas os 4 últimos

são utilizados para definir as operações da ALU, os 2 bits restantes são chamados don’t care,

pois não são relevantes para a execução da lógica de controle na unidade.

4.10 Apresentação e acesso a extensão MIPS X-Ray

A extensão MIPS X-Ray, assim como o seu nome sugere, foi desenvolvida com o obje-

tivo de executar um raio X do processador MIPS. Não no sentido de apresentar os componentes

e transistores da arquitetura, mas o comportamento e funcionamento da mesma. A extensão se

encontra disponibilizada como parte das ferramentas do simulador MARS, a partir de sua ver-

são 4.5, podendo ser encontrada na página da faculdade do estado de Missouri na seção MARS

(VOLLMAR; SANDERSON, 2014). Juntamente com o arquivo executável é disponibilizado

o código fonte do simulador, sendo possível estuda-la, implementar melhorias ou novas funci-

onalidades à ferramenta, para isso é necessário apenas descompactar o arquivo e inclui-lo no

ambiente de desenvolvimento que se deseja utilizar.

Foram publicados artigos para apresentar a ferramenta MIPS X-ray na International

Conference on Education Tecnology and Computer (ICETC) (SALLES et al., 2010) apresen-

tando a sua versão inicial. Posteriormente a versão atual da extensão foi apresentada na Inter-

national Journal of Recent Contributions from Enginnering, Cience & IT (ARAUJO MARCIO

et al., 2014).

43

4.11 Metodologia de testes

Para validar a operação correta da aplicação foram utilizados testes de execução com

o objetivo de verificar o correto funcionamento da ferramenta em relação a desempenho, usa-

bilidade e confiabilidade dos dados fornecidos pela extensão. Para os testes foram utilizados os

sistemas operacionais Linux Ubuntu 12.10 e Windows 8 executando em um computador com

processador Core 2 Duo com 3,15 GHz e 4 GB de memória RAM.

Para os testes da aplicação foi elaborado um código fonte de validação, constituído de

instruções dos diferentes tipos, de forma a cobrir as diferentes operações do conjunto de instru-

ções da arquitetura. Para cada operação foi verificado se as animações geradas correspondiam a

descrição do comportamento do processador, analisando tanto a animação do caminho de dados

do processador quanto das unidades funcionais. Os resultados foram analisados tomando como

base as informações da literatura de referência. Além das animações, foram verificadas a repre-

sentação dos dados das instruções contidas na legenda da simulação, com o objetivo de verificar

se a identificação dos registradores e dos bits da instrução foram gerados corretamente. Para a

verificação de usabilidade do sistema foram efetuados testes utilizando todas as interfaces do

sistema de modo a verificar o seu funcionamento e a visibilidade das funções disponíveis para

o usuário. Por fim para visualização do desempenho da aplicação utilizou-se o gerenciador de

recursos do sistema, analisando o uso de processamento e memória da máquina virtual Java

com o objetivo de verificar se a utilização dos recursos do sistema é coerente com os valores

utilizados pelo simulador MARS.

Além dos testes anteriores a ferramenta foi submetida a uso pelos alunos que estão

cursando ou já cursaram a disciplina de arquitetura de computadores do curso de engenharia de

computação do Centro Federal de Educação Tecnológica CEFET-MG. Após a sua utilização foi

solicitado que os mesmos respondessem um questionário com o objetivo de obter dados sobre

a experiência com a ferramenta e uma análise de suas funcionalidades.

44

5 Resultados experimentais

Neste capítulo são apresentados os resultados experimentais obtidos na elaboração da

ferramenta proposta. Serão apresentados os resultados relativos aos testes de execução da ex-

tensão, assim como os testes de desempenho e usabilidade. Os testes consistiram na execução

de diferentes tipos de instruções e análise da animação resultante, de maneira a executar todos

os possíveis cenários descritos na bibliografia padrão do MIPS. Foram também efetuados testes

de usabilidade, para atestar o correto funcionamento da ferramenta e suas interfaces, garantindo

assim que todas as funcionalidades do sistema apresentem um correto funcionamento. Foram

analisados os recursos de hardware consumidos durante a utilização da ferramenta com o ob-

jetivo de garantir que a aplicação possa ser executada na grande maioria dos computadores,

independente da configuração.

5.1 Resultados do teste de validação

Para a execução do teste utilizou-se um código fonte de validação. Nele foram escritas

instruções de todos os tipos do conjunto de arquitetura e com a utilização desse código foi pos-

sível executar todos os cenários cobertos pela ferramenta. A rotina de testes de funcionamento

consistiu em inicializar o MIPS X-Ray, carregar o código fonte no simulador MARS e iniciar a

execução das instruções. Para cada instrução foram executadas as animações do caminho de da-

dos principal, das unidades de controle e do banco de registradores com o objetivo de visualizar

erros de execução, travamentos, e validação das informações contidas na animação.

Nas Figuras 18 a 23 são exibidas as telas resultantes das operações básicas da extensão,

apresentando-se o caminho de dados das operações do tipo Register, Immediate, Load, Store,

Jump e Branch.

45

Figura 17: Resultado da execução da instrução do tipo R.

Figura 18: Resultado da execução da instrução do tipo I.

46

Figura 19: Resultado da execução da instrução do tipo Load.

Figura 20: Resultado da execução da instrução do tipo Store.

47

Figura 21: Resultado da execução da instrução do tipo J.

Figura 22: Resultado da execução da instrução do tipo Branch.

Foram testados também o caminho de dados das unidades de controle e do banco de

registrador, submetendo-se a ferramenta ao mesmo código para validação utilizado nos testes

48

anteriores. As Figuras 24, 25, 26 e 27 apresentam a configuração final do caminho de dados.

Figura 23: Resultado da execução do caminho de dados do controle da ALU.

Figura 24: Resultado da execução do caminho de dados do controle.

49

Figura 25: Resultado da operação de leitura do banco de registradores.

Figura 26: Resultado da operação de escrita do banco de registradores.

Comparando as imagens capturadas na execução do programa com a literatura básica

(PATTERSON; HENNESSY, 2008), pode-se validar o correto funcionamento da animação do

caminho de dados. Ao efetuar a comparação entre as cores utilizadas nos sinais entre as uni-

dades funcionais e a legenda que indica os bits das instruções, é possível constatar a coerência

50

entre ambas. Finalmente ao verificar a sequência dos bits das instruções mais uma vez ana-

lisando a literatura de referência (PATTERSON; HENNESSY, 2008), verifica-se que os bits

correspondem aos endereços dos registradores e opcode das instruções caracterizando assim o

funcionamento correto da extensão.

5.2 Resultado dos testes de desempenho

Para a execução dos testes de desempenho o sistema foi inicializado utilizando a quan-

tidade mínima de recursos necessários ao sistema operacional de modo a garantir que o hou-

vesse recursos computacionais suficientes para a execução dos testes. O simulador MARS foi

inicializado com o código de validação utilizado nos testes anteriores e durante a sua execução

foram medidos os recursos de processamento e memória utilizados. Em seguida, a extensão

para visualização foi inicializada e novamente foram medidos os recursos computacionais com

o objetivo de identificar a variação dos recursos utilizados pela extensão. Os testes foram execu-

tados tanto em ambiente Windows, plataforma Windows 8 quanto no sistema operacional Linux,

plataforma Ubuntu 13.10. A medição dos recursos utilizados foi feita observando os dados de

consumo da máquina virtual Java. As medições no ambiente Windows estão apresentadas nas

Figuras 28 e 29, onde se pode verificar que o simulador consome cerca de 10% de processa-

mento e cerca de 42 MB de memória. Com a inicialização da extensão MIPS X-Ray observa-se

que o processamento se manteve praticamente constante e a utilização de memória aumentou

aproximadamente 30 MB. Durante o teste não foram observados travamentos ou queda de de-

sempenho da aplicação, sugerindo-se que no ambiente Windows a ferramenta desenvolvida é

capaz de rodar com uma utilização aceitável dos recursos, sem prejudicar o funcionamento do

sistema.

Os mesmos testes foram feitos em ambiente Linux, observando-se conforme mostrado

nas Figuras 30 e 31 que a execução do simulador exigiu mais recursos computacionais quando

comparados com o ambiente Windows. O processamento utilizado foi de aproximadamente

10% e o consumo de memória de 86 MB. Com a inicialização da extensão a utilização do

processador aumentou para 40% e o consumo de memória aumentou para 130 MB, aumentando

então em 40 MB, valor coerente com o medido no ambiente Windows. Apesar de a aplicação

consumir uma quantidade maior de recursos não foram observados qualquer travamento ou

perda de desempenho por parte do sistema operacional, o que sugere que a aplicação é executada

corretamente independente do sistema operacional, com uma utilização aceitável de recursos.

51

Figura 27: Utilização dos recursos pelo simulador MARS em ambiente Windows.

Figura 28: Utilização dos recursos pela extensão MIPS X-Ray em ambiente Windows.

52

Figura 29: Utilização dos recursos pelo simulador MARS em ambiente Linux.

Figura 30: Utilização dos recursos pela extensão MIPS X-Ray em ambiente Linux.

53

5.3 Resultado dos testes com usuários

Os testes de usabilidade foram efetuados por 30 alunos que cursam ou já cursaram a

disciplina de arquitetura de computadores do curso de engenharia de computação no Centro

Federal de Educação Tecnológica CEFET-MG. O objetivo dos testes consistiu em analisar as

funcionalidades da ferramenta, detectar eventuais problemas de execução e levantar possíveis

dúvidas quanto as informações fornecidas pela aplicação. Foram disponibilizados aos usuários

além da aplicação, o código fonte de validação utilizado nos testes da ferramenta, um manual

com as instruções necessárias para executar a aplicação e um questionário com perguntas sobre

o desempenho, usabilidade e clareza nas informações transmitidas pela ferramenta. Foi solici-

tado aos usuários que apresentassem sugestões para melhorias e dúvidas levantadas durante a

utilização da extensão.

Após a utilização da ferramenta não foram notados pelos usuários erros ou travamentos

assim como consumo excessivo dos recursos computacionais do sistema. Os usuários foram

capazes de utilizar os recursos da ferramenta, afirmando que a interface do sistema se mostrou

intuitiva para a utilização das suas funcionalidades. Ao analisar a interface 23% dos usuários

apresentaram dificuldades no entendimento conjunto do caminho de dados principal e do banco

de registradores. A dificuldade foi evidenciada pelo fato das cores utilizadas para representar

os sinais possuírem cores distintas no caminho de dados principal e do banco de registradores.

Para solucionar esse problema as cores utilizadas em ambos foram padronizadas. Cerca de

10% dos usuários reportaram que a legenda que representa os dígitos dos bits da instrução

apresentou sobreposição quando a ferramenta foi utilizada em ambiente Linux. Isso ocorreu

devido ao uso de uma fonte que possui configurações distintas para o ambiente Windows e

ambiente Linux. Para solucionar esse problema a fonte foi alterada para uma que seja comum a

ambos os sistemas operacionais, evitando assim erros de formatação. Aproximadamente 15%

dos usuários reportaram que em ambiente Linux o tempo gasto para a animação ser executada

é perceptivelmente maior do que no ambiente Windows. Verificou-se em testes posteriores que

a variação dos tempos de execução se deve a classe Timer, responsável pela atualização dos

quadros da animação. A classe apresentou um tempo de atualização distinto para cada um dos

sistemas operacionais, isso acontece pois em sua implementação o controle da atualização é

delegado ao sistema operacional, causando uma diferença em seu comportamento.

Ao final do questionário foi solicitado aos alunos sugestões de alterações na ferramenta

com o objetivo de efetivar melhorias que possibilitem um maior entendimento das característi-

cas do caminho de dados, desenvolver as interfaces com o usuário e criar novas funcionalidades

para a ferramenta.

54

As sugestões enumeradas no questionário para a melhoria da ferramenta utilizada fo-

ram:

• Implementação de um controle para a velocidade da animação, possibilitando um au-

mento ou redução da mesma;

• Controle do fluxo da animação, possibilitando pausar, retroceder ou avançar a sequência

da animação;

• Implementação de uma função para a execução sequencial das instruções, de maneira que

ao final da animação de uma instrução a próxima seja iniciada automaticamente;

• Detalhamento das demais unidades funcionais;

• Alteração da legenda para a inclusão de mais informações a respeito dos sinais enviados

entre as unidades;

• Identificação da largura de bits do barramento de cada sinal no caminho de dados princi-

pal.

As sugestões de melhorias serão implementadas e incluídas em versões posteriores da ferra-

menta.

55

6 Conclusões

Diversos cursos de arquitetura de computadores fazem uso de simuladores para propi-

ciar aos alunos um contato direto com a arquitetura estudada, porém esse contato fica limitado

ao desenvolvimento de programas e análise dos componentes do hardware de maneira macro,

sem que seja visualizada a interação entre todas as unidades funcionais presentes na arquitetura.

Este trabalho se apresenta como uma alternativa para conectar os conceitos fundamen-

tais de arquitetura de computadores com a prática propiciada pelos simuladores. Neste trabalho

foi projetada uma ferramenta de visualização de diagramas de caminho de dados, utilizando

como base o trabalho de Vollmar e Sanderson (VOLLMAR; SANDERSON, 2006), criadores

do simulador MARS. A ferramenta foi integrada à lista de ferramentas do MARS e executada

conectada ao mesmo. Desta maneira, puderam-se utilizar todas as ferramentas do simulador em

conjunto com a ferramenta de visualização do caminho de dados. Esta versão preliminar do sis-

tema foi bem sucedida em apresentar de uma maneira didática o funcionamento do processador

MIPS por meio de uma animação dinâmica, coerente com as instruções executadas.

O projeto implementado se soma às ferramentas de simulação já existentes no intuito

de acrescentar melhoria no ensino de arquitetura e organização de computadores. O formato de

extensão do simulador MARS possibilita que essa ferramenta seja submetida a avaliação dos

criadores do simulador MARS, e em caso de aprovação ser integrada oficialmente às demais

ferramentas existentes.

Ressalta-se a implementação nesse trabalho do processo de animação do caminho de

dados das seguintes unidades funcionais: Banco de Registradores, Unidade de Controle e Uni-

dade de Controle da unidade lógica aritmética. Nestas animações foram representadas os sinais

de entrada, saída e a lógica de funcionamento interno das unidades.

Com a conclusão desse trabalho se apresentam novas possibilidades para trabalhos fu-

turos, uma dessas possibilidades é a adequação da ferramenta desenvolvida para processadores

que fazem uso de operações em pipeline. Finalmente é possível também o desenvolvimento

de caminho de dados para as demais unidades funcionais, tais como as unidades de memória e

ALU, o que não foi abordado neste trabalho.

56

Referências

ARAUJO MARCIO, F. L. C.; ANDRADE, F. V.; CORREA-JUNIOR, F. Mips x-ray: A mars si-mulator plug-in for teaching computer architecture. Recent Contributions from Enginnering,Science & IT (iJES), v. 2, p. pp–36, 2014.

ARORA, H.; RAJPUROHIT, Y. Enhanced cycle simulator for mips architecture csmipsa. In:UKSIM. UKSIm, Computer Modelling and Simulation. Cambridge, UK, 2013. p. 365–373.

BEM, E. Z.; PETELCZYC, L. MiniMIPS: A Simulation Project for the Computer ArchitectureLaboratory. In: ACM. ACM SIGCSE Bulletin. New York, NY, USA, 2003. v. 35, n. 1, p.64–68.

BRANOVIC, I.; GIORGI, R.; MARTINELLI, E. WebMIPS: A New Web-based MIPS Si-mulation Environment for Computer Architecture Education. In: ACM. ACM workshop onComputer Architecture Education. New York, NY, USA, 2004. p. 19.

BRORSSON, M. MipsIt: A Simulation and Development Environment Using Animation forComputer Architecture Education. In: ACM. ACM workshop on Computer ArchitectureEducation. New York, NY, USA, 2002. p. 12.

BUTUCARU, H. P. Dips for mips: An instrumented vhdl/corba kernel for distributed learningin eecs. In: IEEE. IEEE Microelectronic Systems Education. Arlington, VA, USA, 1999. p.30–31.

CHOW, T. S. Testing software design modeled by finite-state machines. IEEE Trans. SoftwareEng., v. 4, n. 3, p. 178–187, 1978.

HAYES, J. P. Computer Architecture and Organization. New York, NY, USA: McGraw-Hill,Inc., 2002.

HENESSY JOHN L.; PATTERSON, D. A. Computer Architecture : A Quantitative Appro-ach. New York, NY, USA: Morgan Kaufmann, 2003.

KABIR, M. T.; BARI, M. T.; HAQUE, A. L. VisiMips: Visual Simulator of MIPS32 Pipeli-ned Processor. In: ICCSE. International Conference on Computer Science & Education.Singapura, 2011. p. 788–793.

LARUS, J. SPIM: A MIPS32 Simulator. 2014. Disponível em: <http://pages.cs.wisc.edu-/˜larus/spim.html>.

LUSCO, M. A.; STROUD. PSIM: A Processor SIMulator for Basic Computer Architecture andOperation Education. In: IEEE. IEEE SoutheastCon. New York, NY, USA, 2010. p. 115–118.

NIKOLIC, B.; RADIVOJEVIC, Z.; DJORDJEVIC, J.; MILUTINOVIC, V. A Survey and Eva-luation of Simulators Suitable for Teaching Courses in Computer Architecture and Organiza-tion. IEEE Transactions on Education, v. 52, n. 4, p. 449–458, 2009.

ORACLE. Java Platform, API Specification. 2014. Disponível em: <http://docs.oracle.com-/javase/7/docs/api/java/util/Observable.html>.

57

PANDEY, S.; UMAMAGESWARAN, K.; WILSEY, P. Vhdl semantics and validating transfor-mations. IEEE Computer-Aided Design of Integrated Circuits and Systems, n. 7, p. 936–955, 1999.

PATTERSON, D. A.; HENNESSY, J. L. Computer Organization and Design: The Hard-ware/Software Interface. San Francisco, CA, USA: Morgan Kaufmann, 2008.

PINCKNEY, N.; BARR, T.; DAYRINGER, M.; MCKNETT, M.; JIANG, N.; NYGAARD,C.; HARRIS, D. M.; STANLEY, J.; PHILLIPS, B. A Mips R2000 Implementation. In: ACM.IEEE Design Automation Conference. New York, NY, USA, 2008. p. 102–107.

REAZ, M. B. I.; ISLAM, M. S.; SULAIMAN, M. S. A Single Clock Cycle MIPS RISC Proces-sor Design Using VHDL. In: IEEE. IEEE Semiconductor Electronics. Arlington, VA, USA,2002. p. 199–203.

SALLES, C.; ARAUJO, M. R.; PADUA, F. L.; JUNIOR, F. Mips x-ray: A plug-in to marssimulator for datapath visualization. International Conference on Education Tecnhnologyand Computer, v. 2, p. 32–36, 2010.

TANENBAUM, A. S. Structured Computer Organization. Upper Saddle River, NJ, USA:Prentice Hall PTR, 1984.

VOLLMAR, K.; SANDERSON, P. MARS: An Education-Oriented MIPS Assembly LanguageSimulator. In: ACM. ACM SIGCSE Bulletin. New York, NY, USA, 2006. v. 38, n. 1, p. 239–243.

VOLLMAR, K.; SANDERSON, P. MARS, Assembler and Runtime Simulator. 2014. Dis-ponível em: <http://courses.missouristate.edu/KenVollmar/MARS>.

WOLFFE, G. S.; YURCIK, W.; OSBORNE, H.; HOLLIDAY, M. A. Teaching Computer Or-ganization/Architecture with Limited Resources Using Simulators. In: ACM. ACM SIGCSEBulletin. New York, NY, USA, 2002. v. 34, n. 1, p. 176–180.

YI, K.; DING, Y.-H. 32-Bit RISC CPU Based on MIPS Instruction Fetch Module Design. In:JCAI. International Joint Conference on Artificial Intelligence. Hainan Island,China, 2009.p. 754–760.

YIN RUI-XIN ZUO, Y. Z. Li-jie. A Visual Instruction Set Architecture and Simulation Toolfor Computer Engineering Education. In: FIE. Frontiers in Education. Cambridge, MA, USA,2003. p. 1–6.

YIN RUI-XIN ZUO, Y. Z. Li-jie. Teaching and Research on Assembly Language for Compu-tational Thinking. In: IEEE. Consumer Electronics, Communications and Networks. Xian-Ning, China, 2011. p. 3649–3652.