mips x-ray: uma extensão para o simulador - Piim-Lab - Cefet-MG

C ENTRO F EDERAL DE E DUCAÇÃO T ECNOLÓGICA DE M INAS G ERAIS
C URSO DE E NGENHARIA DE C OMPUTAÇÃO
D EPARTAMENTO DE C OMPUTAÇÃO
M ÁRCIO ROBERTO D IAS DE A RAÚJO
MIPS X-R AY: U MA EXTENSÃO PARA O SIMULADOR MARS
PARA O ENSINO DE A RQUITETURA DE C OMPUTADORES
B ELO H ORIZONTE
2014
M ÁRCIO ROBERTO D IAS DE A RAÚJO
MIPS X-R AY: U MA EXTENSÃO PARA O SIMULADOR MARS
PARA O ENSINO DE A RQUITETURA DE C OMPUTADORES
Trabalho de Conclusão de Curso apresentado ao
Curso de Engenharia de Computação do Centro
Federal de Educação Tecnológica de Minas
Gerais, como requisito parcial para obtenção do
grau de Engenheiro de Computação.
Orientador: Prof. Dr. Flávio Luis Cardeal Pádua
B ELO H ORIZONTE
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 – Orientador
Departamento de Computação
Centro Federal de Educação Tecnológica de Minas Gerais
Professor Fabrício Vivas Andrade – Membro da banca de avaliação
Departamento de Computação
Centro Federal de Educação Tecnológica de Minas Gerais
Professor Sandro Renato Dias – Membro da banca de avaliação
Departamento 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 MIPS
X-Ray, para o ambiente de simulação MARS da arquitetura MIPS, o qual é amplamente utilizado em processos de ensino e aprendizagem sobre arquiteturas de computadores em diversas
instituições de ensino do mundo. Especificamente, a extensão proposta viabilizará por meio
de animações gráficas uma melhor compreensão de modelos de fluxos de dados e da operação
conjunta de unidades funcionais diante da execução de determinadas instruções pelo processador da arquitetura. Dessa forma, diversos conceitos, muitas vezes complexos e abstratos sobre
arquitetura de computadores poderão ser mais facilmente apresentados e assimilados pelos estudantes dessa área. Um código fonte de testes que executa as principais funções do conjunto de
instruções MIPS é utilizado para validar o aplicativo proposto, demonstrando grande potencial
de aplicação desta ferramenta em cursos relacionados com arquitetura de computadores.
Palavras-chave: Arquitetura de computadores, Visualização gráfica de caminho de dados, Simulador 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, intended for the MARS simulation enviroment of MIPS architecture, which is widely used in various
educational instituitons throughout the world. Specifically, by using graphical animations, the
proposed plug-in enables a better understanding of data flows models and the combined operation 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 be
more easily presented to and assimilated by the students in the learning area. Through the
use of a validation source code with the main functions of the MIPS instructions set, the tests
performed with the proposed plug-in demonstrate the significant potential of this tool.
Keywords: Computer architecture education, Graphical visualization of datapaths, MARS simulator, 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; HENNESSY, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
FIGURA 12 – Diagrama do caminho de dados da arquitetura MIPS, baseado em (PATTERSON; 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 (PATTERSON; 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 Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
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
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
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
2
3
4
4.10 Apresentação e acesso a extensão MIPS X-Ray . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.11 Metodologia de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
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
Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5
6
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 conhecimentos 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 processadores, 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 separadamente, pois ambos estão intimamente relacionados. O conjunto de instruções de uma arquitetura 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 processador. 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 funcionamento. 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 compreender 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 transmitem 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 complexos 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 funcionais, 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 distintas. 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 compreensão do processador, ainda assim o dinamismo do funcionamento do processador torna complexa 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 executada 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 arquitetura 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 desenvolver 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 processador 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 execuçã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 compreendidos 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, tornando 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 entendida 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 diferente, 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 comportamento 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 processador;
• 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 simuladores 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 arquitetura. 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 fundamentaçã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 passos 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 apresentado, 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 classes 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; simuladores 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; simuladores 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 aplicaçõ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 agregadas 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 desenvolvimento 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 visualizaçã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 representado 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. Simuladores 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 projetar 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 sistemas 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 testes 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 (PATTERSON; 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, passando 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 hardware do processador. Um dos diferenciais desse modelo é representação das etapas de
processamento do processador, definidas como instruction fetch, instruction decode, execution, 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.
1 Finite
State Machine é um modelo matemático usado para modelar programas de computador e circuitos
ló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 dados 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 apresentado 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 funcionalidade 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 caminho de dados multicíclo com estrutura de pipeline, conforme representado na figura
6. Nele diferentes instruções são executadas simultaneamente pelo processador, de maneira 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 caminho 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 visualizar 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 executar, 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 posteriormente serão convertidos em linguagem de máquina pelo compilador e executados no processador (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 desenvolvida para a arquitetura.
Na arquitetura MIPS, os comandos da arquitetura de conjunto de instruções são representados 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 (PATTERSON; 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, responsá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 programas. 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 funcional 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 diretamente 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 utilizado na instrução;
• rt: Com 5 bits de largura, esse campo armazena o endereço do segundo registrador utilizado na instrução;
• rd: Com 5 bits de largura, esse campo armazena o endereço do terceiro registrador utilizado na instrução;
• shamt: Com 5 bits de largura, esse campo indica a quantidade de bits que serão deslocados 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 mantendo 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 devido à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 informaçõ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 primeiros 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. Operaçõ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 endereç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
Formato R
Formato I
Formato J
Campos
6 bits 1
op
op
op
5 bits 2
rs
rs
5 bits 5 bits 5 bits 6 bits
rt
rd
shamt funct
rt
endereço/imediato
endereço de destino
Comentários
intruções MIPS tem 32 bits
Instruções aritméticas
Formato imediato
Formato jump
Fonte: (PATTERSON; HENNESSY, 2008)
26
3.3
Unidades Funcionais do Processador MIPS e componentes
auxiliares
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 arquitetura (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 transitam 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 suficiente 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 somadores 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 brevemente 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, multiplicaçã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; HENNESSY, 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 definem 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 ativados, 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 sinais, quais serão utilizados no sistema. Um sinal de controle é enviado para o multiplexador, 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 registradores, 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 unidades funcionais. Cada campo da instrução é enviado para uma unidade funcional, os bits do opcode 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 XRay, 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 arquitetura 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 simulador 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 instruçã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 caminho 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 proposta. 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 registradores 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 implementaçã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 execuçã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 caminho 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 criadas 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 diferentes 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 corretamente 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 arquitetura 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 de
Dados
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 obtém os dados armazenados em tempo de execução para detectar o comportamento do processador 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 dados é 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 unidades 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 unidades 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 caminham 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 utilizamos 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 inserir 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 segmento 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 ferramentas 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 diferentes 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 configuraçã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
SINAL DE CONTROLE
ESCRITA
ENDEREÇO
REGISTRADOR 1
1
CTRL
DATA
2
DECODIFICADOR
1 PARA N
...
31
32
CTRL
DATA
CTRL
REGISTRADOR 1
REGISTRADOR 2
...
DATA
CTRL
DATA
REGISTRADOR 31
CTRL
DATA
REGISTRADOR 32
ENDEREÇO
REGISTRADOR 2
REGISTRADOR
DE ESCRITA
ESCRITA
DE DADOS
Figura 15: Caminho de dados do banco de registradores. Adaptado de (PATTERSON; HENNESSY, 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 funcionamento 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; HENNESSY, 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 versã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 funcionalidades à 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) apresentando a sua versão inicial. Posteriormente a versão atual da extensão foi apresentada na International 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, usabilidade 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 representaçã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 extensã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 objetivo 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 possí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 dados 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 unidades 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 analisando 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 houvesse 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 executados 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 processamento 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 desempenho 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 solicitado 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ísticas 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 foram:
• Implementação de um controle para a velocidade da animação, possibilitando um aumento 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 principal.
As sugestões de melhorias serão implementadas e incluídas em versões posteriores da ferramenta.
55
6 Conclusões
Diversos cursos de arquitetura de computadores fazem uso de simuladores para propiciar 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 fundamentais 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 sistema 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 Unidade 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 futuros, 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 simulator 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 Architecture
Laboratory. 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 Simulation Environment for Computer Architecture Education. In: ACM. ACM workshop on
Computer Architecture Education. New York, NY, USA, 2004. p. 19.
BRORSSON, M. MipsIt: A Simulation and Development Environment Using Animation for
Computer Architecture Education. In: ACM. ACM workshop on Computer Architecture
Education. New York, NY, USA, 2002. p. 12.
BUTUCARU, H. P. Dips for mips: An instrumented vhdl/corba kernel for distributed learning
in 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. Software
Eng., 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 Approach. New York, NY, USA: Morgan Kaufmann, 2003.
KABIR, M. T.; BARI, M. T.; HAQUE, A. L. VisiMips: Visual Simulator of MIPS32 Pipelined 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 and
Operation Education. In: IEEE. IEEE SoutheastCon. New York, NY, USA, 2010. p. 115–118.
NIKOLIC, B.; RADIVOJEVIC, Z.; DJORDJEVIC, J.; MILUTINOVIC, V. A Survey and Evaluation of Simulators Suitable for Teaching Courses in Computer Architecture and Organization. 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 transformations. 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 Hardware/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 Processor 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 mars
simulator for datapath visualization. International Conference on Education Tecnhnology
and 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 Language
Simulator. 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. Disponível em: <http://courses.missouristate.edu/KenVollmar/MARS>.
WOLFFE, G. S.; YURCIK, W.; OSBORNE, H.; HOLLIDAY, M. A. Teaching Computer Organization/Architecture with Limited Resources Using Simulators. In: ACM. ACM SIGCSE
Bulletin. 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 Tool
for 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 Computational Thinking. In: IEEE. Consumer Electronics, Communications and Networks. XianNing, China, 2011. p. 3649–3652.