universidade do vale do itajaÍ centro de …siaibib01.univali.br/pdf/paulo viniccius vieira.pdf ·...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Bipide: AMBIENTE DE DESENVOLVIMENTO INTEGRADO PARA A ARQUITETURA DOS PROCESSADORES BIP
Área de Compiladores
por
Paulo Viníccius Vieira
André Luis Alice Raabe, Dr. Orientador
Cesar Albenes Zeferino, Dr. Co-orientador
Itajaí (SC), junho de 2009
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Bipide: AMBIENTE DE DESENVOLVIMENTO INTEGRADO PARA A ARQUITETURA DOS PROCESSADORES BIP
Área de Compiladores
por
Paulo Viníccius Vieira Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: André Luis Alice Raabe, Dr.
Itajaí (SC), junho de 2009
ii
DEDICATÓRIA
A todos que contribuíram para o desenvolvimento deste trabalho.
iii
AGRADECIMENTOS
A minha avó, pelo amor que tem por mim, por me educar e fazer com que eu me tornasse o que sou. E mesmo sem saber direito o que eu fazia e o que eu passei nestes últimos meses, torcia por mim.
A minha mãe, que mesmo a distancia, sempre esteve ao meu lado, me amando, motivando e
me apoiando. Por ser minha mãe, amiga e confidente.
Ao meu avô, que mesmo não estando mais presente, me deu lições que jamais esquecerei.
Ao meu orientador e professor André Luis Alice Raabe, pelo incentivo, confiança e ensinamentos. Simplicidade e objetividade no meu curto tempo disponível para orientação.
Ao meu co-orientador e professor César Albenes Zeferino, pelo incentivo, confiança, ensinamentos e por possibilitar meu ingresso na Pesquisa.
Aos meus professores, pelos ensinamentos passados nestes anos. Aos meus amigos de faculdade, LSED e L2S que me acompanharam por estes anos de
aprendizagem e trabalho. Ao meu amigo Maicon, que acompanhou de perto meu trabalho e sempre me ajudou. Ao meu amigo e Ivan, pela compreensão ao me liberar algumas horas de trabalho para
desenvolver este projeto. E a mim, que passei por isto e sobrevivi.
SUMÁRIO
LISTA DE ABREVIATURAS ................................................................. vi
LISTA DE FIGURAS ............................................................................. vii
LISTA DE TABELAS ........................................................................... viii
RESUMO ................................................................................................... ix
ABSTRACT ................................................................................................ x
1 INTRODUÇÃO ................................................................................... 11
1.1 PROBLEMATIZAÇÃO ................................................................................... 12
1.1.1 Formulação do Problema ............................................................................... 12
1.1.2 Solução Proposta ............................................................................................ 12 1.2 OBJETIVOS ...................................................................................................... 13 1.2.1 Objetivo Geral ................................................................................................ 13 1.2.2 Objetivos Específicos ...................................................................................... 13 1.3 METODOLOGIA ............................................................................................. 14
1.4 ESTRUTURA DO TRABALHO ..................................................................... 14
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 15
2.1 ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES ............... .. 15
2.1.1 Arquitetura ..................................................................................................... 15 2.1.2 Organização .................................................................................................... 18 2.1.3 Processadores .................................................................................................. 20 2.1.4 Microcontroladores ........................................................................................ 21 2.2 PROCESSADORES BIP .................................................................................. 22
2.2.1 BIP I ................................................................................................................. 23 2.2.2 BIP II ............................................................................................................... 25 2.2.3 Organização dos Processadores BIP I e BIP II ............................................ 27
2.3 SIMULADORES DE ARQUITETURA ......................................................... 28
2.3.1 NeanderWin .................................................................................................... 28 2.3.2 Simularq .......................................................................................................... 30 2.3.3 4AC .................................................................................................................. 32 2.3.4 VLIW -DLX ..................................................................................................... 33
2.3.5 R10k ................................................................................................................. 34 2.3.6 MipsIt ............................................................................................................... 36 2.3.7 Comparação entre os Simuladores Analisados ............................................ 37
2.4 COMPILADORES ............................................................................................ 38
2.4.1 Fases de um Compilador ................................................................................ 39
2.4.2 Ferramentas para Construção de Compiladores ......................................... 42
2.5 WINDOWS PRESENTATION FOUNDATION ........................................... 43 2.5.1 XAML .............................................................................................................. 44
v
3 DESENVOLVIMENTO ...................................................................... 47
3.1 ESPECIFICAÇÃO ............................................................................................ 47
3.1.1 Requisitos Funcionais ..................................................................................... 47 3.1.2 Requisitos Não Funcionais ............................................................................. 48
3.1.3 Regras de Negócio ........................................................................................... 48 3.1.4 Modelo de Casos de Uso ................................................................................. 48
3.2 DEFINIÇÃO DA LINGUAGEM ..................................................................... 51
3.2.1 Diretrizes para definição do subconjunto da linguagem Portugol ............. 52 3.3 IMPLEMENTAÇÃO ........................................................................................ 54
3.3.1 Implementação do compilador ...................................................................... 54
3.3.2 Implementação do simulador ........................................................................ 59
3.3.3 Integração do compilador e demais componentes do ambiente ................. 62 3.3.4 Visão geral das funcionalidades e dos aspectos da interface gráfica ......... 65 3.3.5 Verificação ....................................................................................................... 70
4 CONCLUSÕES .................................................................................... 73
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 76
A. GRAMÁTICA PORTUGOL DEFINIDA NO ANTLR ........... ........ 81 B. CONJUNTO DE INSTRUÇÕES UTILIZADAS PARA VALIDAÇÃO DO SIMULADOR .......................................................... 83
C. PROGRAMAS PORTUGOL UTILIZADOS PARA VALIDAÇÃO DO COMPILADOR................................................................................. 86
D. QUESTIONÁRIO PARA AVALIAÇÃO DO AMBIENTE BIPIDE PELOS USUÁRIOS ................................................................................. 91
E. RESULTADOS DA AVALIAÇÃO ................................................... 91
LISTA DE ABREVIATURAS
ACC Accumulator ANTLR ANother Tool for Language Recognition ASIP Application-Specific Instruction-set Processor BIP Basic Instruction-set Processor BNF Bakus-Naur Form CI Circuito Integrado CISC Complex Instruction Set Computers CPU Central Processing Unit E/S Entrada/Saída IDE Integrated Development Environment IR Instruction Register LSED Laboratório de Sistemas Embarcados e Distribuídos MIPS Microprocessor without Interlocked Pipeline Stages OCR Optical Character Recognition PC Program Counter PIC Programmable Intelligent Computer RAM Random Access Memory RI Registrador de Instruções RISC Reduced Instruction Set Computer ROM Read Only Memory TOS Top of Stack UCP Unidade Central de Processamento ULA Unidade Lógica Aritmética UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí VLIW Very Long Instruction Word WPF Windows Presentation Foundation XAML eXtensible Application Markup Language XML eXtensible Markup Language µBIP microBIP
LISTA DE FIGURAS
Figura 1. Fonte dos operando nas diferentes classes de conjunto de instruções. .............................. 16
Figura 2. Arquitetura de Memória ..................................................................................................... 20 Figura 3. Organização do processador BIP I ..................................................................................... 27 Figura 4. Organização do Processador BIP II ................................................................................... 28 Figura 5. Tela Principal do Sistema NeanderWin ............................................................................. 30 Figura 6. Tela Principal do Simularq ................................................................................................ 31 Figura 7. Detalhe de um multiplexador simulado pelo Simularq ...................................................... 32
Figura 8. Tela Principal do 4AC ....................................................................................................... 33 Figura 9. Tela Principal do VLIW-DLX ........................................................................................... 34 Figura 10. Tela Principal do R10k .................................................................................................... 35 Figura 11. Simulação de uma arquitetura pipeline no MipsIt ........................................................... 36 Figura 12. Compilador ...................................................................................................................... 39
Figura 13. Árvore sintática da expressão 3*a + (b-2) ....................................................................... 40 Figura 14. Código fonte na linguagem C# para exibir uma janela Windows .................................... 44
Figura 15. Código fonte na linguagem XAML para exibir uma janela Windows ............................. 45
Figura 16. Janelas criadas com as linguagens C# e WPF: (a) C#; (b) WPF ..................................... 45
Figura 17. Camada de interface e lógica de aplicação em WPF ....................................................... 46
Figura 18. Modelo de Casos de Uso .................................................................................................. 49 Figura 19. Estrutura do programa Portugol ....................................................................................... 51 Figura 20. Mensagem de erro gerada pelo ANTLR .......................................................................... 57 Figura 21. Ações semânticas para inserção de nome do comando nas mensagens de erro ............... 58
Figura 22. Implementação do Método GetErrorMessage para tratamento de erros gerados ............ 58
Figura 23. Visão geral da ferramenta Expression Blend 2 ................................................................ 59 Figura 24. Implementação de uma animação através do Expression Blend 2 .................................. 60
Figura 25. Início da animação de uma instrução ADD ..................................................................... 61 Figura 26. Sequência da animação de uma instrução ADD .............................................................. 62
Figura 27. Final da animação de uma instrução ADD ...................................................................... 62 Figura 28. Visão simplificada das classes onde são armazenados os códigos do Programa ............. 64
Figura 29. Interface do módulo de programação ............................................................................... 65 Figura 30. Interface do módulo de simulação ................................................................................... 67 Figura 31. Relação de elementos na interface do módulo de simulação ........................................... 69
Figura 32. Interface do módulo de ajuda ........................................................................................... 70
LISTA DE TABELAS
Tabela 1. Arquitetura do BIP I .......................................................................................................... 24
Tabela 2. Conjunto de instruções do BIP I ........................................................................................ 24 Tabela 3. Arquitetura do BIP II ......................................................................................................... 25
Tabela 4. Conjunto de instruções do BIP II ...................................................................................... 26 Tabela 5. Funcionalidades dos sistemas analisados .......................................................................... 37 Tabela 6. Lista de símbolos da gramática Portugol ........................................................................... 53 Tabela 7. Ações Semânticas para a geração de declaração e definição de variáveis ........................ 55 Tabela 8. Ações Semânticas para a geração de desvios condicionais ............................................... 56
Tabela 9. Ações Semânticas para a geração de desvios condicionais ............................................... 57
Tabela 10. Características do Expression Blend 2 em relação ao Visual Studio 2008 ..................... 60
Tabela 11. Programa utilizado para validar uma instrução de laço de repetição .............................. 71
Tabela 12. Conjunto de programas utilizados para validação do simulador ..................................... 83
Tabela 13. Conjunto de programas utilizados para validação do compilador ................................... 86
RESUMO
VIEIRA, Paulo Viníccius. Bipide - Ambiente de Desenvolvimento Integrado para a Arquitetura dos Processadores BIP. Itajaí, 2009. 107f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. O ensino de conceitos introdutórios de programação apresenta um nível de abstração que prejudica o aprendizado de alunos que possuem dificuldades em lidar com o raciocínio lógico necessário ao entendimento da lógica de programação. Pensando nesta dificuldade, uma família de processadores, denominada BIP – Basic Instruction-set Processor, foi desenvolvida visando à integração interdisciplinar e o apoio ao ensino em disciplinas de fases iniciais do curso de Ciência da Computação. Neste contexto este trabalho apresenta um ambiente de desenvolvimento integrado denominado Bipide, que possibilita o desenvolvimento, execução e simulação de programas em linguagem Portugol, relacionando-os à arquitetura dos processadores da família BIP. Com isto, disponibiliza-se uma ferramenta de apoio ao ensino das disciplinas de Algoritmos e Programação que auxiliará na redução da abstração envolvida em conceitos fundamentais da lógica de programação e permitirá coletar evidências empíricas sobre a vantagem em reduzir o nível de abstração envolvido nesta aprendizagem. Este trabalho apresenta uma revisão de fundamentos associados à Arquitetura e Organização de Computadores e ao desenvolvimento de compiladores, assim como descreve o projeto e a implementação do ambiente desenvolvido, o qual se encontra pronto para ser utilizado em experimentos em sala de aula, pois não foram identificados erros nos testes de conformidade realizados. Palavras-chave: Simuladores de Arquitetura de Computadores. Compiladores. Aprendizagem de Programação.
ABSTRACT
The teaching of introductory programming concepts involves a high level of abstraction that creates difficulties for students who are dealing with initial programming logic. To approach this problem, a family of processors, called BIP - Basic Instruction-set Processor, was developed to support the integration and interdisciplinary teaching in courses of early stages on Computer Science. Therefore, this paper presents an integrated development environment (IDE) called Bipide, which enables the development, implementation and simulation of programs written in structured Portuguese (called Portugol) linking them to the processor architecture of the BIP family. The IDE provides a tool to support the teaching of subjects of introductory programming reducing the abstraction involved in fundamental concepts of programming logic. It will also serve as an instrument to collect empirical evidence on the advantage to reduce the level of abstraction involved in this type of learning. This paper presents a review of fundamentals associated with the Computer Architecture and Organization and compilers development, and describes the design and implementation of the IDE. The system is ready to be used in experiments in the classroom. Keywords: Computer Architecture Simulators. Compilers. Programming Learning.
1 INTRODUÇÃO
As disciplinas da área de Arquitetura e Organização de Computadores são fundamentais na
formação de alunos dos cursos de Ciência da Computação e de Engenharia da Computação. Estas
disciplinas, além de fornecer os conhecimentos básicos para a compreensão dos conceitos
apresentados durante o curso, fornecem subsídios fundamentais para a aprendizagem e
compreensão da lógica de programação.
Considerando esse último aspecto, é fato amplamente conhecido que alunos apresentam
dificuldades na aprendizagem de conceitos de algoritmos e programação, em especial nas fases
iniciais do curso (CARBONE; KAASBOLL, 1998; MENEZES; NOBRE, 2002; PIMENTEL et al.,
2003; GOOD; BRNA, 2004; KHALIFE, 2006). Essa dificuldade está relacionada, entre outros
aspectos, à ausência de afinidade com o raciocínio lógico formal que é o fundamento para a
capacidade de abstração dos alunos. Nesse sentido, o estudo da arquitetura do computador cria a
possibilidade de estabelecer relações dos conceitos de programação com aspectos concretos do
hardware, reduzindo assim a necessidade de abstração.
No entanto, identifica-se uma falta de sincronia nos currículos tradicionais em que o estudo
da arquitetura e da organização do computador ocorre depois do ensino da programação. Para
contornar esse problema, em muitos cursos costuma-se apresentar algumas noções básicas de
arquitetura e organização de computadores no primeiro ano do curso. Essa abordagem normalmente
apresenta dois problemas: (i) a falta de uma articulação adequada entre os professores das
disciplinas introdutórias a fim de estabelecer uma sincronia na apresentação dos conteúdos que
possa beneficiar a aprendizagem de programação; e (ii) a limitação dos modelos utilizados para a
apresentação dos conceitos básicos de arquitetura (MORANDI et al., 2006).
Uma iniciativa para minimizar esses problemas foi desenvolvida por pesquisadores do
Laboratório de Sistemas Embarcados e Distribuídos da Universidade do Vale do Itajaí. Trata-se de
uma família de processadores com um conjunto de instruções básicas, denominada BIP (Basic
Instruction-set Processor), projetada visando auxiliar o aprendizado de conceitos de arquitetura e
organização de computadores por alunos de fases iniciais de cursos de graduação em Computação e
promover a integração interdisciplinar (MORANDI; RAABE; ZEFERINO, 2006). O objetivo é que
esses processadores possam servir de referência para a apresentação dos conceitos básicos
necessários ao melhor entendimento das abstrações utilizadas nas disciplinas da área de Algoritmos
12
e Programação e que também possam ser explorados posteriormente em disciplinas afins, como
Circuitos Digitais, Sistemas Operacionais e Compiladores.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
Acredita-se que introduzir conceitos básicos de Arquitetura e Organização de Computadores
aos alunos auxilia na redução da abstração envolvida em conceitos de programação, como
variáveis, atribuições, operações aritméticas, desvios e laços de repetição.
Segundo Borges e Silva (2006), o uso de simuladores que permitam a compreensão do
funcionamento do processador é fundamental para o ensino adequado da arquitetura de
computadores e, consequentemente, pode influenciar positivamente na aprendizagem de alunos que
em geral apresentam problemas em lidar com abstrações.
No entanto, os simuladores disponíveis para ensino costumam apresentar uma interface de
usuário pouco elaborada e com poucos recursos operacionais, o que ocasiona, mesmo em
arquiteturas mais simples, dificuldade em se trabalhar com eles por parte dos alunos. Alguns
simuladores necessitam que a codificação do programa seja em linguagem de máquina; outros ainda
só suportam a execução através de linha de comando (BORGES; SILVA, 2006; BORUNDA;
BREWER; ERTEN, 2006).
1.1.2 Solução Proposta
A solução proposta neste trabalho consiste no projeto e implementação de um ambiente de
desenvolvimento integrado1 (IDE - Integrated Development Environment) cujo objetivo é auxiliar
na utilização dos processadores BIP na aprendizagem de programação.
Segundo Myatt (2007), a utilização de IDEs oferece benefícios que podem favorecer a
redução do tempo de aprendizagem. Entre os benefícios disponibilizados destaca-se: (i) interface
1 IDEs são ambientes de desenvolvimento que oferecem ferramentas de apoio ao desenvolvimento de software e integram serviços que facilitam este processo (MYATT, 2007).
13
gráfica de desenvolvimento; (ii) integração com o compilador; (iii) facilidade para análise e teste de
código; e (iv) facilidade para depuração de código através de execução passo a passo,
O ambiente desenvolvido, denominado Bipide (BIP - Basic Instruction-set Processor – IDE
- Integrated Development Environment), possibilita o desenvolvimento de programas em linguagem
Portugol2. Estes programas poderão ser compilados e simulados através deste ambiente, onde será
exibida a linguagem assembly resultante do processo de compilação e a simulação destes programas
sobre a arquitetura dos processadores BIP.
A utilização da linguagem Portugol deve-se ao fato da mesma ser constantemente utilizada
nas aulas inicias das disciplinas de Algoritmos e Programação. Esta linguagem utiliza comandos em
português, o que facilita o aprendizado da lógica de programação e habitua o aluno iniciante com o
formalismo da programação (ESMIN, 2000 apud MIRANDA, 2004).
1.2 OBJETIVOS
1.2.1 Objetivo Geral
O objetivo geral deste trabalho é a construção de um ambiente de desenvolvimento
integrado que possibilite a criação de programas e ilustre a execução destes, relacionando-os aos
aspectos da arquitetura dos processadores BIP I e BIP II.
1.2.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
• Consolidar conceitos sobre compiladores;
• Consolidar conceitos de arquitetura e organização de computadores;
• Estudar a arquitetura e o conjunto de instruções dos processadores da família BIP;
• Implementar e disponibilizar um ambiente de desenvolvimento integrado para
programação em linguagem Portugol e visualização do assembly e do estado dos
componentes dos processadores BIP I e BIP II;
2 Portugol é uma pseudolinguagem utilizada na descrição de algoritmos.
14
• Testar e verificar o sistema desenvolvido; e
• Documentar e divulgar o projeto.
1.3 METODOLOGIA
A metodologia adotada no desenvolvimento deste trabalho foi dividida em quatro partes:
• Estudo: Nesta etapa foram realizados estudos a fim de adquirir o conhecimento
necessário sobre os conceitos e tecnologias utilizadas, além de uma pesquisa sobre a
característica de ferramentas similares. Os recursos utilizados nesta etapa foram livros,
artigos publicados e manuais;
• Projeto: Nesta etapa foi realizada a especificação do sistema, através do levantamento de
requisitos e definição de casos de uso. Foi definida também a gramática a ser utilizada
no compilador utilizado;
• Revisão: Foi realizada uma revisão do projeto inicial, levando em consideração as
questões levantadas durante a apresentação do TCC I;
• Desenvolvimento: Esta etapa é caracterizada pela implementação do ambiente baseada
no projeto realizado, compreendendo o desenvolvimento de um compilador, simulador,
ajuda e interface do ambiente.
• Avaliação/Verificação: Nesta etapa foram realizados testes a fim de eliminar possíveis
erros existentes e validar a ferramenta; e
• Documentação: Consiste na redação deste trabalho, fundamentando e detalhando o
desenvolvimento do ambiente Bipide. Esta etapa também inclui a redação de artigo
científico divulgando o projeto.
1.4 ESTRUTURA DO TRABALHO
Este documento esta estruturado em três capítulos. O Capítulo 1, Introdução, apresenta uma
visão geral sobre o tema abordado no trabalho bem como seus objetivos. O Capítulo 2,
Fundamentação Teórica, apresenta o resultado da etapa de estudo, com uma revisão bibliográfica
dos temas envolvidos no trabalho. No Capítulo 3, Projeto, é apresentado o projeto do ambiente,
incluindo sua especificação e a definição de linguagem do compilador desenvolvido. O capítulo 4
detalha a implementação da ferramenta e apresenta suas principais funcionalidades.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é apresentada a revisão bibliográfica sobre os temas envolvidos no projeto. A
Seção 2.1 apresenta uma revisão sobre Arquitetura e Organização de Computadores. Na Seção 2.2 é
apresentado um levantamento das características dos processadores BIP. A seção 2.3 apresenta uma
breve descrição sobre simuladores de arquitetura e apresenta os simuladores analisados durante o
estudo de ferramentas similares. Na Seção 2.4 é apresentada uma revisão sobre compiladores e
apresenta a ferramenta ANTLR (ANother Tool for Language Recognition), utilizada para o
desenvolvimento do compilador. Finalizando este capítulo, a Seção 2.5 apresenta uma breve
descrição da tecnologia WPF (Windows Presentation Foundation), uma das tecnologias utilizadas
para o desenvolvimento do ambiente.
2.1 ARQUITETURA E ORGANIZAÇÃO DE COMPUTADORES
Nesta seção são apresentados os conceitos básicos sobre arquitetura e organização de
computadores necessários ao desenvolvimento do presente trabalho.
2.1.1 Arquitetura
Segundo Stallings (2005), o termo arquitetura de computador refere-se principalmente aos
atributos que têm impacto direto sobre a execução lógica de um sistema e que são visíveis ao
programador como: (i) conjunto de instruções; (ii) modos de endereçamento; (iii) memória de
programa e dados; (iv) registradores; (v) portas de entrada e saída; e (vi) interrupções.
2.1.1.1 Conjunto de Instruções
Uma instrução indica ao processador uma sequência de micro-operações que deverá ser
executada (WEBER, 2004).
De acordo com seu propósito e formato, as instruções podem ser classificadas como: (i)
instruções de transferência de dados; (ii) instruções aritméticas e lógicas; e (iii) instruções de desvio
(condicional ou incondicional) e de teste (ou de comparação). Um conjunto de instruções refere-se
ao conjunto de todas as instruções reconhecidas por um computador (WEBER, 2004).
16
Segundo Hennessy e Patterson (2003), a forma do armazenamento interno do processador
tem influência sobre o conjunto de instruções, já que os operandos das instruções podem variar de
acordo com o tipo de armazenamento. Assim, têm-se os seguintes tipos de arquitetura:
• Arquitetura de pilha: Armazenamento baseado em pilha. A arquitetura possui um
registrador TOS (Top of Stack) que armazena o topo da pilha. O processamento é
realizado com os dois operandos retirados do topo da pilha e o resultado é novamente
armazenado no topo da pilha (Figura 1 (a));
• Arquitetura de acumulador: Armazenamento baseado em acumulador. O acumulador é
um registrador utilizado como um dos operandos da operação realizada pela ULA
(Unidade Lógica Aritmética). Após o cálculo o resultado é armazenado novamente no
acumulador, sendo utilizado para a próxima operação a ser realizada (Figura 1 (b)); e
• Arquitetura de registradores de uso real: Armazenamento baseado em banco de
registradores. Os operandos são armazenados em registradores ou posições da memória.
A Figura 1 (c) ilustra uma arquitetura onde um dos operandos da ULA está armazenado
em memória; na Figura 1 (d) são utilizados somente registradores como operandos fonte
para a ULA e as variáveis são carregadas e atualizadas por meio de instruções de
transferência (load-store) – Figura 1 (d).
Figura 1. Fonte dos operando nas diferentes classes de conjunto de instruções.
Fonte: Adaptado de Hennessy e Patterson (2003).
17
De acordo com a quantidade e tipo de instruções suportadas, os computadores podem ser
classificados em duas classes:
• Máquinas CISC (Complex Instruction Set Computers – Computador com um Conjunto
Complexo de Instruções): os computadores classificados como CISC possuem um
conjunto diversificado de instruções;
• Máquinas RISC (Reduced Instruction Set Computer – Computador com um Conjunto
Reduzido de Instruções): possuem um conjunto reduzido de instruções e apresentam
como características básicas: (i) um conjunto limitado de instruções com formato fixo;
(ii) um grande número de registradores; e (iii) enfoque na otimização do uso do pipeline3
de instruções (STALLINGS, 2005).
A principal diferença entre as duas classes é que máquinas RISC são arquiteturas de load-
store - Figura 1 (c), já em máquinas CISC as instruções podem ler ou gravar seus resultados
diretamente na memória - Figura 1 (d) (CARTER, 2003).
2.1.1.2 Registradores
Em um processador existem diversos registradores, sendo que alguns destes devem ser de
conhecimento do programador, denominados de registradores especiais. Weber (2004) cita alguns
dos registradores especiais encontrados em arquiteturas de computadores:
• Apontador de Instruções: contém o endereço da próxima instrução a ser buscada na
memória e executada. Normalmente são conhecidos como PC (Program Counter);
• Registrador de Instruções (RI): armazena o código da instrução que está sendo
executada;
• Registrador de Estado (STATUS): armazena informações a respeito dos resultados da
ULA.
3 Pipeline é uma técnica de hardware que permite a busca e execução de novas instruções antes que a execução anterior seja terminada, acelerando o processo de execução de instruções (STALLINGS, 2005).
18
2.1.1.3 Interrupções
O mecanismo de interrupção presente nos processadores possui três funções principais: (i)
permitir que dispositivos externos interrompam o processamento atual do processador para atender
sua necessidade; (ii) liberar o processador da tarefa de pesquisar todos os dispositivos verificando se
algum necessita de atendimento; e (iii) permitir que o processador execute operações de outro
programa enquanto o programa atual aguarda por uma resposta informando que o processador
concluiu a tarefa e, então, possa voltar a processar o mesmo programa (WEBER, 2004;
STALLINGS, 2005).
2.1.1.4 Portas de Entrada/Saída
As portas de Entrada/Saída (E/S) são os meios físicos que permitem as atividades de troca
de informação entre o processador e o meio externo. Através das portas de E/S o processador pode
trocar informações com o usuário ou se comunicar com outros dispositivos como, por exemplo,
dispositivos de armazenamento (WEBER, 2004).
2.1.2 Organização
O termo organização de computadores refere-se aos atributos que não são visíveis ao
programador, ou seja, trata de como o processador é implementado e aborda blocos básicos como
caminho de dados e unidade de controle (STALLINGS, 2005).
2.1.2.1 Caminho de Dados
O Hardware necessário para execução de uma instrução é formato pela unidade de execução
e pelo banco de registradores. Essas unidades compõem o caminho de dados (WEBER, 2004).
A unidade de execução é composta por uma ou mais ULAs, registradores de uso geral e
específicos interligados por um barramento. Ao ser executada na unidade de execução, uma
instrução segue um ciclo chamado de ciclo de instrução. Este ciclo normalmente é formado pelas
seguintes etapas (WEBER, 2004; STALLINGS, 2005):
• Busca de Instrução: nesta etapa, o registrador de instrução (RI) recebe a instrução da
memória de instrução apontada pelo registrador PC e o registrador PC é atualizado para
o endereço da próxima instrução;
19
• Decodificação: a instrução é decodificada pela unidade de controle para definir qual
instrução deve ser executada;
• Execução: Nesta etapa, os operandos são carregados do banco de registradores e, de
acordo com a operação identificada na etapa de decodificação, é realizado o cálculo pela
ULA. Após executado, o resultado da operação é armazenado no banco de registradores.
2.1.2.2 Unidade de Controle
A unidade de controle gera sinais de controle responsáveis por gerenciar o fluxo interno de
dados, a memória e a comunicação com os dispositivos de entrada e saída. Cada sinal de controle
comanda uma micro-operação, como por exemplo, uma ativação da memória ou a seleção de uma
operação pela ULA, conforme a instrução atual (WEBER, 2004).
2.1.2.3 Memórias
O sistema de memória serve como um local para o armazenamento de dados e programa. A
memória é dividida em “palavras”, que podem ser identificadas por um endereço único. Existem
dois tipos básicos de memória: (i) ROM (Read Only Memory – Memória Apenas de Leitura), que
permite acesso apenas para leitura de dados e normalmente é utilizada para armazenar o programa
de inicialização; e (ii) RAM (Random Access Memory – Memória de Acesso Aleatório), que
permite escrita e leitura de dados e pode ser utilizada para armazenar dados, programas e sistemas
operacionais (CARTER, 2003; WEBER, 2004).
A memória de dados e a memória de instruções podem estar juntas em um mesmo espaço de
endereçamento ou separadas. Quando as memórias utilizam o mesmo espaço de endereçamento, a
arquitetura é referenciada como arquitetura de Princeton (ou de Von Neumann), conforme Figura 2
(a). Quando a memória de dados utiliza um espaço diferente da memória de instrução é referenciada
como arquitetura de Harvard (Figura 2 (b)).
A arquitetura de Princeton pode resultar em hardware mais simples, enquanto a arquitetura
de Harvard pode resultar em um desempenho melhor, pois permite o acesso simultâneo nas duas
memórias (PREDKO, 1998).
20
Figura 2. Arquitetura de Memória
Fonte: Adaptado de Vahid e Givargis (2002).
2.1.3 Processadores
“A tecnologia de processadores envolve a arquitetura do mecanismo computacional usado
para implementar uma funcionalidade desejada do sistema” (VAHID; GIVARGIS, 2002, p. 9).
Vahid e Givargis (2002) descrevem três tecnologias de processadores: (i) processador de
propósito geral; (ii) processador de propósito único; e (iii) processador de aplicação específica.
2.1.3.1 Processador de Propósito Geral
Um processador de propósito geral é projetado para atender uma variedade de aplicações e
para maximizar o numero de dispositivos vendidos (VAHID; GIVARGIS, 2002).
Também conhecidos como microprocessadores e CPU (Central Processing Unit – Unidade
Central de Processamento (UCP)), os processadores de propósito geral apresentam características
comuns como: (i) presença de uma memória de programa onde é armazenado um programa com
funcionalidade desejada; (ii) caminho de dados genérico o suficiente para manipular uma variedade
de computação; e (iii) possuem um banco de registradores grande e uma ou mais ULAs de
propósito geral.
21
2.1.3.2 Processador de Propósito Único
Um processador de propósito único, também conhecido como processador dedicado, é um
circuito digital projetado para executar um programa específico. A funcionalidade nesse tipo de
processador é implementada diretamente no hardware e representa exatamente a funcionalidade
desejada (VAHID; GIVARGIS, 2002; PEREIRA, 2008).
2.1.3.3 Processador de Aplicação Específica
Um processador de aplicação específica (ASIP - Application-Specific Instruction-set
Processor) é um meio termo entre os dois processadores descritos anteriormente. Estes
processadores são projetados para atender um conjunto de aplicações com características em
comum através do acréscimo de unidades funcionais para operações comuns (VAHID; GIVARGIS,
2002).
2.1.4 Microcontroladores
Souza (2003, p. 21) descreve o microcontrolador como “um ‘pequeno’ componente
eletrônico, dotado de uma ‘inteligência’ programável, utilizado no controle de processos lógicos”,
onde a operação do sistema baseia-se nas operações lógicas que devem ser executadas.
Toda a lógica de operação é estruturada na forma de um programa e gravada dentro do
microcontrolador, o que o torna programável. A ULA é responsável por todas as operações
matemáticas e lógicas que são executadas no microcontrolador (SOUZA, 2003).
Os componentes de um microcontrolador podem ser construídos a partir de uma única
pastilha de silício4 contendo todos os componentes necessários ao controle de um processo como
memória de programa, memória de dados, portas de entrada/saída, etc. (STALLINGS, 2005;
SOUZA, 2003). Para Souza (2003), esta é uma característica que diferencia microcontroladores de
microprocessadores, pois estes últimos, apesar de possuírem uma ULA mais poderosa, não possuem
todos os recursos em uma única pastilha.
4 Um circuito construído sobre uma pastilha de silício também é conhecido como Circuito Integrado (CI) ou “chip”.
22
2.2 PROCESSADORES BIP
A família de processadores BIP foi desenvolvida por pesquisadores do Laboratório de
Sistemas Embarcados e Distribuídos (LSED) da Universidade do Vale do Itajaí – UNIVALI com o
objetivo de desenvolver uma série de processadores de arquitetura simplificada que auxiliassem no
aprendizado de Arquitetura e Organização de Computadores por alunos de fases iniciais de cursos
de graduação em Computação. Outro objetivo do BIP é permitir relacionar os conteúdos de
programação com suas representações em hardware, provendo a base necessária para compreensão
das abstrações adotadas nas disciplinas da área de Algoritmos e Programação (MORANDI et al.,
2006).
Nesse contexto, ao buscar estabelecer uma relação entre a programação de alto nível e a sua
representação em hardware, podem ser mencionadas as relações entre: (i) declaração de variável e
alocação de memória; (ii) constantes e operandos imediatos; (iii) atribuição de variáveis e operações
de acesso a memória; e (iv) operações aritméticas e a utilização de unidades de soma/subtração
(MORANDI; RAABE; ZEFERINO, 2006).
Conforme Morandi et al. (2006), durante o desenvolvimento do BIP, foram definidas três
diretrizes de projeto:
• A arquitetura do processador deveria ser simples o suficiente para facilitar o
entendimento do seu funcionamento e a sua construção a partir dos conceitos estudados
na disciplina de circuitos digitais;
• A arquitetura deveria ser extensível; e
• As ferramentas de apoio desenvolvidas no contexto do projeto deveriam priorizar o uso
de estruturas de linguagem compreendidas no primeiro ano do curso.
De acordo com estas diretrizes, foram definidos três modelos de processador (MORANDI;
RAABE; ZEFERINO, 2006; PEREIRA, 2008):
• BIP I: com foco no suporte ao entendimento de conceitos como níveis de linguagem,
constantes, variáveis, representação de dados e de instruções, conjuntos de instruções,
programação em linguagem de montagem e geração de código em linguagem de
máquina; e
23
• BIP II: extensão do BIP I, com foco na inclusão de suporte aos conceitos de estruturas
de controle para desvios condicionais e incondicionais e laços de repetição.
• µBIP: estende a arquitetura das versões anteriores do BIP e acrescenta suporte a
instruções de lógica booleana, deslocamento lógico, manipulação de vetores, instruções
de controle, suporte a procedimentos e funcionalidades típicas de microcontroladores
como, por exemplo, pinos de E/S e temporizador programável.
Como o foco deste trabalho é auxiliar o entendimento de conceitos básicos aprendidos nas
fases iniciais do ensino de programação, é utilizado somente os modelos de arquitetura simplificada
dos processadores BIP I e BIP II.
2.2.1 BIP I
O BIP I utiliza uma arquitetura baseada na arquitetura RISC do microcontrolador PIC
(Programmable Intelligent Computer). Ele é uma máquina orientada a acumulador e não possui
banco de registradores. Todas as operações de transferência e aritmética envolvem o acumulador e,
em algumas operações aritméticas, é necessário buscar operandos posicionados na memória
(MORANDI et al., 2006).
A arquitetura do BIP I possui um conjunto de instruções com poucos modos de
endereçamento e todas as instruções são baseadas neste formato. Como pode ser visto na Tabela 1,
o formato de instrução esta dividido em dois campos: 5 bits para o código de operação, o que
permite implementar até 32 instruções; e 11 bits reservados para o operando, o que possibilita
representar até 2048 posições de endereçamento ou qualquer constante com valores entre -1024 até
+1023 (MORANDI; RAABE; ZEFERINO, 2006).
24
Tabela 1. Arquitetura do BIP I
Tamanho da palavra de dados 16 bits Tipo de dados Inteiro de 16 bits com sinal: –32768 a +32767 Tamanho da palavra de instrução 16 bits Formato de instrução
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Cód. Operação Operando
Modos de endereçamento Direto: o operando é um endereço da memória Imediato: o operando é uma constante
Registradores ACC: acumulador IR: registrador de instrução PC: contador de programa
Classes de instrução Transferência (acesso à memória): STO, LD, LDI Aritmética: ADD, ADDI, SUB e SUBI Controle: HLT
Fonte: Adaptado de Morandi et al. (2006).
A arquitetura do BIP I inclui três registradores: PC, IR e ACC. O contador de programa
(PC) aponta para o endereço da próxima instrução a ser executada. O registrador de instrução (IR –
Instruction Register) armazena a instrução que está em execução. O acumulador (ACC –
Accumulator) é utilizado para armazenamento de dados durante uma operação.
O conjunto de instruções do BIP I, conforme apresentado na Tabela 2, inclui uma instrução
de controle, três instruções de transferência (duas de acesso à memória) e quatro instruções de
aritmética. Em cada instrução, exceto na instrução Halt (HLT), o PC é incrementado em uma
unidade no final do ciclo de execução da instrução. Na tabela, o termo Memory[operand]
representa uma variável armazenada na posição operand da memória de dados.
Tabela 2. Conjunto de instruções do BIP I
Código da operação Instrução Operação Classe 00000 HLT Paralisa a execução Controle 00001 STO operand Memory[operand] ← ACC Transferência 00010 LD operand ACC ← Memory[operand] Transferência 00011 LDI operand ACC ← operand Transferência 00100 ADD operand ACC ← ACC + Memory[operand] Aritmética 00101 ADDI operand ACC ← ACC + operand Aritmética 00110 SUB operand ACC ← ACC – Memory[operand] Aritmética 00111 SUBI operand ACC ← ACC – operand Aritmética 01000 - 11111 Reservado para futuras gerações
Fonte: Adaptado de Morandi et al. (2006).
25
Como pode ser observado na Tabela 2, O BIP I realiza operações básicas de soma e
subtração com variáveis e constantes. Segundo MORANDI et al. (2006), apesar de limitada, esta
arquitetura possibilita apresentar a implementação em hardware de diversas abstrações estudadas
nas disciplinas da área de Algoritmos e Programação.
2.2.2 BIP II
Trata-se de uma extensão do BIP I e possui as mesmas características arquiteturais. Uma das
mudanças realizadas na extensão do BIP I para o BIP II foi a inclusão da classe de instruções de
desvio visando a implementação de desvios condicionais, incondicionais e laços de repetição
(MORANDI; RAABE; ZEFERINO, 2006). O BIP II possui de três a quatro registradores: PC,
ACC, STATUS e IR, conforme ilustrado na Tabela 3. Em uma das implementações apresentadas
para este processador, o registrador PC assume as funcionalidades do registrador IR.
Tabela 3. Arquitetura do BIP II
Tamanho da palavra de dados 16 bits Tipo de dados Inteiro de 16 bits com sinal: –32768 a +32767 Tamanho da palavra de instrução 16 bits Formato de instrução
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Cód. Operação Operando
Modos de endereçamento Direto: o operando é um endereço da memória Imediato: o operando é uma constante
Registradores ACC: acumulador IR: registrador de instrução PC: contador de programa STATUS: registrador de estado com dois flags (Z e N)
Classes de instrução Transferência (acesso à memória): STO, LD, LDI Aritmética: ADD, ADDI, SUB e SUBI Controle: HLT Desvio: BEQ, BNE, BGT, BGE, BLT, BLE e JMP
Fonte: Adaptado de Morandi, Raabe e Zeferino (2006).
Para suportar as instruções de comparação e desvio condicional foi acrescentado um
registrador de estado (STATUS). Toda instrução de comparação e desvio condicional deve ser
precedida por uma instrução de subtração (SUB ou SUBI). O registrador STATUS possui dois flags
que são ativados dependendo do resultado da operação anterior: (i) Z, que indica se o resultado da
última operação da ULA foi igual a zero ou não; e (ii) N, que indica se o último resultado da ULA
foi um número negativo ou não (MORANDI; RAABE; ZEFERINO, 2006).
26
A Tabela 4 apresenta o conjunto de instruções do processador BIP II. Na tabela é possível
observar as alterações nos registradores ACC (coluna 3) e PC (coluna 4) em cada instrução. Na
tabela, o termo Memory[operand] representa uma variável alocada em memória na posição
operand . Nas instruções de desvio, o termo operand representa o endereço para onde o PC
deverá apontar.
Tabela 4. Conjunto de instruções do BIP II
Código da operação
Instrução Operação e atualização do PC
00000 HLT Paralisa a execução PC ← PC
00001 STO operand Memory[operand] ← ACC PC ← PC + 1
00010 LD operand ACC ← Memory[operand] PC ← PC + 1
00011 LDI operand ACC ← operand PC ← PC + 1
00100 ADD operand ACC ← ACC + Memory[operand] PC ← PC + 1
00101 ADDI operand ACC ← ACC + operand PC ← PC + 1
00110 SUB operand ACC ← ACC – Memory[operand] PC ← PC + 1
00111 SUBI operand ACC ← ACC - operand PC ← PC + 1
01000 BEQ operand
Se (STATUS.Z=1) então PC ← endereço Senão PC ← PC + 1
01001 BNE operand
Se (STATUS.Z=0) então PC ← endereço Senão PC ← PC + 1
01010 BGT operand
Se (STATUS.Z=0) e (STATUS.N=0) então PC ← endereço Senão PC ← PC + 1
01011 BGE operand
Se (STATUS.N=0) então PC ← endereço Senão PC ← PC + 1
01100 BLT operand
Se (STATUS.N=1) então PC ← endereço Senão PC ← PC + 1
01101 BLE operand
Se (STATUS.Z=1) ou (STATUS.N=1) então PC ← endereço Senão PC ← PC + 1
01110 JMP operand PC ← endereço
01111-11111 Reservado para as futuras gerações
Fonte: Adaptado de Zeferino (2007).
27
Pereira (2008) apresenta uma descrição mais completa do conjunto de instruções dos
Processadores BIP. Parte desta documentação, referente às instruções suportadas pelos
processadores BIP I e BIP II é apresentada no Anexo I.
2.2.3 Organização dos Processadores BIP I e BIP II
Segundo Morandi, Raabe e Zeferino (2006), a organização do BIP I utiliza a estrutura
Harvard, com memórias separadas para dados e instruções. Conforme ilustrado na Figura 3, o
processador é dividido em dois blocos: (i) Controle, responsável por gerar sinais de controle para o
caminho de dados e atualização do PC; e (ii) Caminho de Dados, que inclui os circuitos necessários
para executar a instrução.
Figura 3. Organização do processador BIP I
Fonte: Adaptado de Zeferino (2007).
Essa organização é bastante simples e seus blocos constituintes podem ser descritos apenas
pela sua funcionalidade, o que atende o objetivo de facilitar o entendimento por parte de alunos de
fases iniciais da área de Arquitetura e Organização de Computadores (MORANDI; RAABE;
ZEFERINO, 2006).
28
A organização do BIP II, conforme mostra a Figura 4, estende a organização do BIP I,
incluindo o registrador STATUS e modificações no circuito de atualização do PC. Nas instruções
de desvio, a fonte de atualização do PC é definida em função do tipo de desvio e dos valores dos
flags N e Z do registrador STATUS (MORANDI; RAABE; ZEFERINO, 2006).
Figura 4. Organização do Processador BIP II
Fonte: Adaptado de Pereira (2008).
2.3 SIMULADORES DE ARQUITETURA
O objetivo desta subseção é apresentar um estudo comparativo de alguns simuladores de
arquitetura e organização de computadores, com foco naqueles desenvolvidos com propósito
educacional, a fim de levantar as características presentes em cada simulador.
2.3.1 NeanderWin
O NeanderWin é um sistema simulador de caráter educacional desenvolvido para a máquina
Neander-X. Este simulador estende o conjunto de instruções inicialmente proposto para a máquina
Neander e disponibiliza um ambiente integrado de desenvolvimento, onde é possível editar,
29
compilar e executar código de programas na linguagem de montagem do processador Neander-X
(BORGES; SILVA, 2006).
As instruções do Neander-X são compostas por um ou dois bytes. Nas instruções com
apenas um byte, os quatro bits mais significativos contem o código da instrução e os demais não são
utilizados. As instruções com dois bytes fazem referência a um dado imediato ou operando na
memória. Os quatro bits de mais baixa ordem do primeiro byte são reservados para futuras
expansões (BORGES; SILVA, 2006).
O Neander-X apresenta três Modos de endereçamento: (i) Imediato, onde o segundo byte da
instrução é o operando; (ii) Direto, em que o segundo byte representa o endereço de memória do
operando; e (iii) Indireto, onde o segundo byte da instrução contém o endereço de memória onde
está o endereço do operando.
Os recursos disponibilizados pelo simulador NeanderWin incluem:
• Editor de texto, onde é possível escrever e editar programas na linguagem de montagem
definida para o processador Neander-X;
• Montador, responsável por converter o assembly do Neander-X em linguagem de
máquina; e
• Simulador de arquitetura onde é possível visualizar o estado dos registradores principais
da CPU e a memória simulada.
O NeanderWin permite ainda a execução passo a passo e indica erros encontrados durante o
processo de simulação. Disponibiliza também arquivo de ajuda que descreve a funcionalidade dos
registradores utilizados.
A Figura 5 mostra a tela principal do sistema NeanderWin. Na parte superior estão os botões
usados em conjunto com o editor de texto. Logo abaixo, à esquerda, está o editor de textos e a
direita se situam os verificadores dos registradores principais da CPU e o visualizador da memória.
30
Figura 5. Tela Principal do Sistema NeanderWin
Fonte: Borges e Silva (2006).
2.3.2 Simularq
O Simularq é um simulador gráfico de arquitetura desenvolvido para fins didáticos. Seu
objetivo principal é fornecer uma ferramenta de apoio para o ensino de tópicos da disciplina de
Arquitetura de Computadores, facilitando o entendimento e o aprendizado do aluno, além de
permitir sua utilização em outras disciplinas como Compiladores e Sistemas Operacionais,
aproximando a teoria apresentada em sala de aula aos experimentos realizados em laboratório
(CANCIAN, 1997; CANCIAN, 2001; RAABE; VALLE FILHO; CANCIAN, 2001).
A arquitetura simulada consiste de uma máquina monoprocessada com três periféricos
(teclado, disco rígido e monitor), memória de endereçamento de 8K, temporizador e controle de
interrupções. A CPU consiste de uma unidade de processamento, uma unidade de controle, quatro
registradores adicionais e cerca de 30 instruções assembly. A memória ROM armazena dados de 23
bits e tem capacidade para 2048 microinstruções (CANCIAN, 1997).
31
A utilização do Simularq permite ao aluno criar novas instruções assembly ou alterar as
existentes, ampliando a capacidade do sistema. Apesar de não disponibilizar um editor de textos
próprio, o Simularq permite testar a execução de novos programas, pois trabalha com arquivos texto
que podem ser editados em qualquer outro editor (CANCIAN, 1997).
Para observar as variáveis de interesse durante a simulação do sistema podem ser definidos
pontos de parada, o que permite visualizar, por exemplo, os registradores da CPU e valores no
barramento. A Figura 6 apresenta uma tela do Simularq, representando a simulação de alguns
componentes do computador.
Figura 6. Tela Principal do Simularq
O Simularq representa os três principais componentes do computador: processador,
memória e dispositivos de entrada e saída, permitindo uma visão completa do computador
simulado. A arquitetura está dividida em cerca de treze telas distintas, cada uma apresentando parte
da arquitetura. É possível ainda, expandir cada componente a fim de observar em detalhes o nome
das conexões e o seu circuito eletrônico. A Figura 7 ilustra o detalhamento de um multiplexador
presente na arquitetura simulada (CANCIAN, 1997; RAABE; VALLE FILHO; CANCIAN, 2001).
32
Figura 7. Detalhe de um multiplexador simulado pelo Simularq
Fonte: Adaptado de Raabe, Valle Filho e Cancian (2001).
Segundo Cancian (1997), a utilização de janelas distintas para cada componente permite
isolar e visualizar somente as partes de interesse, abstraindo o restante. Porém, a grande quantidade
de janelas pode prejudicar o entendimento do programa, o que seria solucionado com uma análise
ergonômica e alterações na interface do sistema.
2.3.3 4AC
Moreira e Hajdu (2004) descrevem a implementação de um ambiente de apoio ao
aprendizado de Arquitetura de Computadores, denominada 4AC. As funcionalidades disponíveis
neste ambiente incluem: (i) conversor de bases; (ii) simplificação de expressões lógicas; e (iii)
simulador de instruções de máquina.
A utilização de um simulador de instruções permite a visualização do ciclo de instruções,
passo a passo, em nível de micro-instrução, ilustrando as operações realizadas internamente no
processador principal e seus barramentos, facilitando desta forma, seu entendimento. O conjunto de
instruções adotado oferece operações aritméticas e lógicas, desvios condicionais e incondicionais,
operações de leitura e escrita na memória, operações com pilha, operações de E/S e manipulação de
bits (MOREIRA; HAJDU, 2004). A Figura 8 demonstra a interface do sistema 4AC.
33
Figura 8. Tela Principal do 4AC
2.3.4 VLIW -DLX
O VLIW-DLX é um simulador gráfico de um processador VLIW5 (Very Long Instruction
Word), desenvolvido com o propósito de ser utilizado em cursos de graduação na área de
arquitetura de computadores (BEČVÁŘ; KAHÁNEK, 2007).
A arquitetura simulada consiste de cinco pipelines paralelos: (i) instruções aritméticas de
dados do tipo inteiro e instruções de controle; (ii) instruções aritméticas e de transferência (load);
(iii) instruções de transferência (load-store); (iv) instruções de ponto flutuante; e (v) multiplicação
em ponto flutuante. Esta arquitetura apresenta um banco de 128 registradores de propósito geral,
sendo 64 de dados do tipo inteiro e 64 de ponto flutuante (BEČVÁŘ; KAHÁNEK, 2007).
Os recursos oferecidos pelo simulador VLIW-DLX incluem: (i) editor de textos para
programação em linguagem assembly; (ii) compilador; (iii) execução passo a passo; (iv)
identificação de erros de compilação; (v) visualização dos valores atuais dos registradores; e (vi)
5 O modelo de arquitetura VLIW permite que um grupo de instruções seja executado ao mesmo tempo, visando reduzir o número de instruções executadas pelo processador e, consequentemente, o tempo de execução dos programas (BEČVÁŘ; KAHÁNEK, 2007)
34
visualização dos ciclos de instruções, que para melhor visualização e entendimento são
diferenciados por cores, que também identificam os blocos de instruções correspondentes
(BEČVÁŘ; KAHÁNEK, 2007). A interface do VLIW-DLX pode ser vista na Figura 9.
Figura 9. Tela Principal do VLIW-DLX
2.3.5 R10k
O R10k é um simulador de arquitetura superescalar baseado no processador MIPS
(Microprocessor without Interlocked Pipeline Stages) R10000. Foi desenvolvido de maneira a
facilitar o entendimento das estruturas internas e do comportamento do processador, auxiliando
desta forma o processo de ensino-aprendizagem de processadores superescalares6 (GONÇALVES
JUNIOR et al., 2007).
O simulador R10k utiliza um subconjunto de 29 instruções do MIPS R10000, entre
operações lógicas e aritméticas, desvios condicionais e incondicionais, transferência de dados e
acesso a memória, além de chamadas a sub-rotinas. A memória foi dividida em memória de dados e
memória de instruções com 256 posições, a fim de facilitar a visualização. Além do banco de
6 Um processador superescalar possui diversas unidades de execução, tornando-o capaz de buscar, executar e finalizar diversas instruções em paralelo.
35
registradores e das memórias, os valores dos registradores especiais também podem ser observados
na interface do programa (GONÇALVES JUNIOR et al., 2007).
A Figura 10 apresenta a tela inicial do sistema R10k.
Figura 10. Tela Principal do R10k
Fonte: Gonçalves Junior et al. (2007).
O simulador permite a execução passo a passo das instruções, além de ser possível
acompanhar os ciclos de clock, conforme eles são executados. Existe ainda a possibilidade de
modificar o programa no próprio simulador e, caso seja encontrado algum erro durante o processo
de compilação, o simulador exibe mensagens informando o usuário sobre o erro apresentado.
Para auxiliar a compreensão do funcionamento do simulador, esta disponível no sistema um
arquivo de ajuda. Neste arquivo, além do manual de funcionamento do simulador, são descritos o
formato e a função de cada instrução, bem como alguns fundamentos de arquiteturas superescalares
e informações sobre o MIPS R10000.
36
2.3.6 MipsIt
O MipsIt consiste de um conjunto de ferramentas que incluem um ambiente de
desenvolvimento, uma plataforma de hardware e uma série de simuladores. Foi desenvolvido com o
propósito de auxiliar o ensino de arquitetura e organização de computadores (BRORSSON, 2002).
Segundo Brorsson (2002), o ambiente MipsIt pode ser utilizado para o desenvolvimento de
programas capazes de serem executados em hardware específico ou simulados através dos
simuladores disponíveis na ferramenta. Esses programas são escritos em linguagem assembly ou em
conjunto com a linguagem C.
O simulador foi desenvolvido para ser flexível e permitir a simulação de programas em
diferentes microarquiteturas. Ele permite carregar um programa em memória e executá-lo passo a
passo, o que permite monitorar o conteúdo da memória e dos registradores durante sua execução. A
cada passo executado o gráfico exibido é modificado, atualizando o conteúdo dos registradores e
posicionando os sinais de controle de acordo com a instrução corrente. A Figura 11 mostra uma
arquitetura pipeline de cinco estágios simulada através do MipsIt (BRORSSON, 2002).
Figura 11. Simulação de uma arquitetura pipeline no MipsIt
Fonte: Brorsson (2002).
37
2.3.7 Comparação entre os Simuladores Analisados
A partir da utilização e do estudo de publicações e manuais dos simuladores descritos, foi
possível estabelecer uma comparação entre suas funcionalidades. A Tabela 5 apresenta um resumo
com as principais funcionalidades identificadas nos sistemas apresentados e as funcionalidades
presentes no ambiente Bipide.
Tabela 5. Funcionalidades dos sistemas analisados
Características 4AC MipsIt NeanderWin R10k Simularq VLIW -DLX Bipide
Desenvolvimento de programas em linguagem de alto nível
Não Sim Não Não Não Não Sim
Desenvolvimento de programas em linguagem assembly
Não Sim Sim Sim Sim Sim Não
Visualização da linguagem assembly
Não Sim Sim Sim Não
Identificado Sim Sim
Visualização da Memória
Sim Sim Sim Sim Sim Sim Sim
Visualização dos valores dos registradores
Sim Sim Sim Sim Sim Sim Sim
Execução Passo a Passo
Sim Sim Sim Sim Sim Sim Sim
Simulação da Organização
Não Sim Não Não Sim Não Sim
Identificação de erros de compilação
Não Identificado
Não Identificado
Sim Sim Não
Identificado Sim Sim
Alteração de valores em tempo de execução
Não Identificado
Não Não Sim Não
Identificado Não Não
Arquivos de Ajuda
Não Não Não Sim Sim Não Sim
38
2.4 COMPILADORES
Com o advento da computação surgiu a necessidade de se escrever sequências de códigos,
ou programas, para que os computadores efetuassem as computações desejadas. Inicialmente esses
programas foram escritos em linguagem de máquina, ou seja, códigos numéricos representando as
operações a serem executadas (LOUDEN, 2004).
A utilização desta linguagem mostrou-se entediante e com alto tempo de desenvolvimento,
sendo rapidamente substituída pela linguagem de montagem (assembly), onde as instruções e
endereços de memória adotam formas simbólicas. As linguagens de montagem, entretanto,
apresentam limitações, dentre os quais o fato de serem de difícil escrita, leitura e compreensão,
além de serem extremamente dependentes da máquina para a qual são escritas (LOUDEN, 2004).
O passo seguinte na tecnologia de programação foi escrever as operações de um programa
de forma concisa, semelhante a uma notação matemática ou linguagem natural, menos dependente
de uma máquina em particular, com um nível de abstração mais elevado e passível de tradução por
um programa em código executável. (LOUDEN, 2004; AHO et al., 2008; DELAMARO, 2004).
Esta linguagem é conhecida como linguagem de alto nível ou linguagem de terceira geração (AHO
et al., 2008).
Com a utilização de linguagens de alto nível obteve-se vantagens em relação às linguagens
de máquina e montagem, entre as quais se destacam: (i) adaptabilidade; (ii) portabilidade; (iii)
possibilidade de estruturação e orientação a objeto; (iv) simplicidade; e (v) facilidade de detecção
de erros (TERRY, 1996).
Louden (2004, p. 1) define compiladores como “programas de computador que traduzem de
uma linguagem para outra”. Um compilador recebe como entrada um programa escrito em
linguagem de programação, a linguagem fonte, e o traduz para um programa equivalente em outra
linguagem, a linguagem objeto (Figura 12). A linguagem fonte geralmente é uma linguagem de alto
nível, como C ou C++ e a linguagem objeto é um código escrito usando as instruções de máquina
do computador no qual ele será executado (linguagem de máquina) (LOUDEN, 2004).
39
Figura 12. Compilador
Fonte: Adaptado de Aho et al. (2008).
2.4.1 Fases de um Compilador
As subseções a seguir descrevem as quatro principais fases que tradicionalmente compõem
o processo de compilação: (i) análise léxica; (ii) análise sintática; (iii) análise semântica; e (iv)
geração de código.
2.4.1.1 Análise Léxica
A primeira etapa do processo de compilação é responsável por ler o fluxo de caracteres que
compõem o programa fonte e separar cada símbolo que tenha algum significado para a linguagem,
identificando a que tipo pertence e agrupando-os em sequências significativas denominadas
lexemas (AHO et al., 2008; DELAMARO, 2004).
Os símbolos identificados e seus atributos são armazenados em uma estrutura denominada
tabela de símbolos. Estes atributos oferecem informações como o espaço de memória alocado para
um nome, seu tipo e onde seu valor pode ser utilizado no programa (AHO et al., 2008).
A análise léxica deve também avisar quando um símbolo inválido é encontrado no programa
fonte e relacionar as mensagens de erro geradas pelo compilador com o programa fonte. Deve ainda
remover conteúdo insignificante para a linguagem como espaços em branco, quebras de linha,
tabulação e comentários (DELAMARO, 2004; AHO et al., 2008).
2.4.1.2 Análise Sintática
O analisador sintático é construído sobre uma gramática composta de regras que descrevem
as construções válidas para a linguagem. Segundo Delamaro (2004), esta etapa é responsável por
40
verificar a ordem em que os símbolos aparecem no programa fonte e determinar se essa sequência
forma um programa válido ou não.
Outra função do analisador sintático é a construção de uma estrutura em forma de árvore que
descreve as construções da linguagem reconhecida pelo analisador sintático. Nesta estrutura,
conhecida como árvore sintática ou árvore de derivação, cada nó interior representa uma operação e
os filhos do nó representam os argumentos desta operação (LOUDEN, 2004; AHO et al., 2008).
Assim, para a expressão aritmética 3*a + (b-2), a árvore sintática ficaria conforme mostra a Figura
13.
Figura 13. Árvore sintática da expressão 3*a + (b-2)
Fonte: Adaptado de Aho et al. (2008).
Os analisadores sintáticos costumam ser classificados em analisadores sintáticos
descendentes e ascendentes. Os analisadores descendentes começam a análise com o símbolo inicial
da gramática e constrói a árvore de cima para baixo (top-down); os analisadores ascendentes
começam com os símbolos terminais que formam as folhas e constroem a árvore de baixo para cima
(botton-up) (LOUDEN, 2004; AHO et al., 2008).
2.4.1.2.1 Analisadores LL(k)
Os analisadores LL(k) são analisadores preditivos7 que utilizam o método de análise
sintática descendente.
O primeiro “L” em LL(k) significa que o processamento é realizado da esquerda para direita
(Left-to-right); o segundo “L” se refere ao fato de o analisador acompanhar uma derivação mais à
7 Analisadores sintáticos preditivos tentam prever a construção seguinte na cadeia de entrada com base em uma ou mais marcas de verificação à frente.
41
esquerda para a cadeia de entrada (Leftmost). O k entre parênteses significa que são verificados k
símbolos adiante na entrada para prever a direção da análise. Quando apenas um símbolo à frente é
utilizado, a análise é classificada como LL(1) (LOUDEN, 2004; AHO et al., 2008).
Ao contrario da análise sintática descendente recursiva, a análise LL(k) utiliza uma pilha
explicita, em vez de ativações recursivas. Segundo Louden (2004, p. 152), “a representação dessa
pilha de forma padrão é útil para facilitar e agilizar a visualização das ações do analisador
sintático”.
2.4.1.3 Análise Semântica
Durante a análise semântica, são verificados se existem incoerências quanto ao significado
das construções utilizadas no programa fonte, como: (i) tipos de operandos incompatíveis com
operadores (verificação de tipo); (ii) variáveis não declaradas; (iii) redeclaração de variáveis; e (iv)
chamadas de funções com o número incorreto de parâmetros (DELAMARO, 2004).
Para a verificação de inconsistência no programa fonte o analisador semântico utiliza a
árvore sintática criada na etapa anterior como representação do programa e a tabela de símbolos, na
qual busca informações sobre as variáveis declaradas e o tipo de cada uma delas. Reúne ainda
informações adicionais sobre as variáveis, que são armazenadas para uso na etapa de geração de
código (AHO et al., 2008; DELAMARO, 2004).
2.4.1.4 Geração de Código
Após a verificação de que não existem erros sintáticos ou semânticos no programa fonte, o
compilador realiza a tarefa de geração de código do programa objeto. O gerador de código recebe
como entrada uma representação intermediária do programa fonte e o mapeia em uma linguagem
objeto, refletindo, mediante instruções de baixo nível, os comandos do programa fonte (AHO et al.,
2008; DELAMARO, 2004).
Nesta fase da compilação as propriedades da máquina para a qual o programa será criado
devem ser observadas como, por exemplo, a quais registradores serão atribuídas as variáveis do
programa, ou ainda a localização de memória para cada uma das variáveis utilizadas (LOUDEN,
2004).
42
De acordo com Delamaro (2004), também pode fazer parte do processo de geração de
código uma etapa de otimização do código, onde são aplicadas técnicas para otimizar algumas
características do programa objeto gerado como, por exemplo, o seu tamanho.
2.4.2 Ferramentas para Construção de Compiladores
O processo de desenvolvimento de um compilador pode ser facilitado pela utilização de
ambientes de desenvolvimento de software que oferecem recursos como, por exemplo, editores de
texto, depuradores, gerenciadores de versão e ferramentas de testes (AHO et al., 2008).
Além dessas ferramentas gerais de desenvolvimento, foram criadas ferramentas para auxiliar
na programação das diferentes fases do compilador. Essas ferramentas costumam utilizar
linguagens especializadas para especificar e implementar componentes específicos do compilador.
Segundo Aho et al. (2008, p. 8), “as ferramentas mais bem sucedidas são aquelas que ocultam os
detalhes de seus algoritmos e produzem componentes que podem ser facilmente integrados ao
restante do compilador”. Entre as ferramentas mais utilizadas na construção de compiladores estão
(AHO et al., 2008):
• Geradores de analisadores sintáticos: produzem reconhecedores sintáticos a partir da
descrição gramatical de uma linguagem de programação;
• Geradores de analisadores léxicos: produzem analisadores léxicos a partir de tokens de
uma linguagem em forma de expressão regular;
• Mecanismos de tradução dirigida por sintaxe: produzem um conjunto de rotinas que
percorrem uma árvore de derivação e geram código intermediário;
• Geradores de gerador de código: utilizam uma coleção de regras para traduzir cada
operação da linguagem intermediária em linguagem de máquina, produzindo um gerador
de código;
• Mecanismos de análise de fluxo de dados: facilitam a coleta de informações sobre como
os valores são transmitidos entre as diferentes partes de um programa;
• Conjunto de ferramentas para a construção de compiladores: oferecem um conjunto
integrado de rotinas para a construção das diversas fases de um compilador.
43
2.4.2.1 ANTLR
O ANTLR é uma ferramenta para a construção de compiladores, que pode ser utilizado para
a construção de gramáticas próprias, geração de componentes reconhecedores de linguagem,
tradutores de linguagens formais e geração de árvores gramaticais (PARR, 2007a; PARR, 2007b).
Para a geração do reconhecedor de linguagem é necessário um arquivo fonte contendo as
definições da gramática envolvida. Após o processamento desse arquivo a ferramenta gera o código
fonte do reconhecedor, que pode ser gerado em uma das linguagens de programação pré-definidas
pela ferramenta (Java, C++, C#, Python). Os reconhecedores gerados utilizam o algoritmo LL(k)
para reconhecer tokens em sequência de caracteres (analisador léxico), estruturas gramaticais em
sequências de tokens (parsers) ou árvores de sintaxe. (PARR, 2007a; KOLLROSS, 2007);
As definições de gramáticas aceitas pelo ANTLR são similares à de outras ferramentas com
o mesmo propósito, como o Yacc e o Bison.
2.5 Windows Presentation Foundation
O Windows Presentation Foundation (WPF) é uma tecnologia da Microsoft para
desenvolvimento de aplicativos e interfaces, acrescentando novos recursos ao .NET Framework8
(SONNINO; SONNINO, 2006). Sua utilização permite a construção de aplicações que possibilitam
uma melhor experiência do usuário9 devido à possibilidade destas aplicações possuírem uma
interface gráfica rica e interativa. Entre os recursos de apresentação e mídia disponibilizados pelo
WPF citam-se (SONNINO; SONNINO, 2006; COSTA, 2006):
• Leiautes avançados;
• Suporte a gráficos vetoriais e 3D;
• Reconhecimento de voz;
• Reconhecimento ótico de caracteres (OCR - Optical Character Recognition);
• Suporte a mídias como áudio e vídeo; e
8 .NET Framework é um componente essencial do Windows que visa uma plataforma única para desenvolvimento e execução de aplicações, onde qualquer código gerado pode ser executado em qualquer dispositivo que possua o .NET framework instalado (MICROSOFT CORPORATION, 2008a), . 9 Termo utilizado para representar a interação de um usuário com um sistema, focado basicamente na interface.
44
Para tornar a interface das aplicações ainda mais ricas, o WPF permite a definição de
animações através da criação de storyboards. Uma storyboard pode ser definida como um conjunto
de animações, onde cada animação altera uma propriedade especifica de um elemento.
2.5.1 XAML
O WPF utiliza uma linguagem declarativa para a criação de interfaces denominada XAML
(eXtensible Application Markup Language). Esta linguagem utiliza os mesmo conceitos da
linguagem XML (eXtensible Markup Language), onde cada entidade é chamada de elemento e
definida em um par de tags de abertura e de fechamento (por exemplo, <TextBox>
</TextBox>) .
A utilização de uma linguagem declarativa para a definição de interfaces gráficas apresenta
uma série de vantagens, tais como (COSTA, 2006; RIBES; ZEVE, 2006):
• Código legível e de fácil compreensão;
• Hierarquia entre os controles facilmente perceptível;
• Código da interface separada da lógica da aplicação; e
• Linguagens de marcação costumam ser mais facilmente processadas e interpretadas por
ferramentas de desenvolvimento.
A utilização de uma linguagem declarativa pode ainda diminuir a quantidade de código
escrito pelo desenvolvedor, possibilitando mais tempo para a análise e desenvolvimento da lógica
da aplicação (COSTA, 2006; MacVITTIE, 2006). O código fonte, escrito em C#, apresentado na
Figura 14 cria uma janela e adiciona um controle a ela, exibido na Figura 15(a).
System.Windows.Forms.Form mainWindows = new System. Windows.Forms.Form();
System.Windows.Forms.TextBox txtElement = new Syste m.Windows.Forms.TextBox();
txtElement.Text = "Hello World!";
txtElement.ForeColor = Color.DarkRed;
txtElement.Font = new System.Drawing.Font("Microsof t Sans Serif", 14);
mainWindows.Controls.Add(txtElement);
mainWindow.Show();
Figura 14. Código fonte na linguagem C# para exibir uma janela Windows
Fonte: Adaptado de Costa (2006).
45
A mesma janela (Figura 16(b)) pode ser definida utilizando-se a linguagem XAML, como
mostra o código da Figura 15.
<Window xmlns="http://schemas.microsoft.com/winfx/a valon/2005" >
<TextBox Foreground="DarkRed" FontSize="14" >
Hello World!
</TextBox>
</Window>
Figura 15. Código fonte na linguagem XAML para exibir uma janela Windows
Fonte: Adaptado de Costa (2006).
(a) (b)
Figura 16. Janelas criadas com as linguagens C# e WPF: (a) C#; (b) WPF
A linguagem XAML somente define os elementos de interface com o usuário, não sendo
capaz de conter nenhum tipo de lógica de aplicação. Para tratar os eventos de interação do usuário é
necessário utilizar uma linguagem de programação como, por exemplo, C# (WILLIAMS, 2008;
COSTA, 2006). Os controles visuais disparam eventos para a camada lógica da aplicação,
responsável por controlar a execução do programa, como ilustrado na Figura 17.
46
Figura 17. Camada de interface e lógica de aplicação em WPF
Fonte: Adaptado de Williams (2008).
Com esta abordagem, a interface de uma aplicação pode ser criada sem a necessidade de
conhecer a lógica da mesma. Da mesma forma, o programador pode se ocupar da lógica da
aplicação sem a necessidade de conhecer detalhes da interface que está sendo criada. Isso também
melhora a legibilidade do programa, devido ao fato de o código de interface e o código de negócio
estarem em arquivos diferentes (COSTA, 2006; MacVITTIE, 2006).
3 DESENVOLVIMENTO
No desenvolvimento deste trabalho, primeiramente definiu-se os requisitos funcionais e não
funcionais do projeto bem com as regras de negócio. Em seguida, com base na especificação do
projeto, foi desenvolvido um protótipo de interfaces e a definição da linguagem da gramática do
compilador. Em seguida iniciou-se a implementação do ambiente. Este Capítulo detalha a
especificação e desenvolvido do ambiente Bipide.
3.1 ESPECIFICAÇÃO
Esta seção apresenta a especificação do projeto Bipide. A seguir serão apresentados os
requisitos funcionais, não funcionais, regras de negócio e diagrama de Casos de Uso do projeto.
3.1.1 Requisitos Funcionais
• RF01: O sistema deverá permitir ao usuário escrever programas em linguagem Portugol.
• RF02: O sistema deverá permitir ao usuário compilar os programas escritos na
linguagem Portugol.
• RF03: O Sistema deverá indicar os erros encontrados no programa durante a
compilação.
• RF04: O sistema deverá permitir a execução do programa passo a passo.
• RF05: O sistema deverá gerar código assembly, equivalente ao programa Portugol
compilado, para os processadores BIP I e BIP II.
• RF06: O sistema deverá simular o funcionamento do programa sobre a arquitetura dos
processadores BIP I e BIP II.
• RF07: O sistema deverá apresentar funcionalidades típicas de ambientes de
desenvolvimento como: gerenciamento de arquivos, localizar, substituir, indentação e
destaque em palavras reservadas.
• RF08: O sistema deverá possuir uma janela de ajuda sensível ao contexto.
48
3.1.2 Requisitos Não Funcionais
• RNF01: O simulador de arquitetura deverá ser implementado utilizando-se a tecnologia
WPF.
• RNF02: A arquitetura simulada no sistema deverá ser correspondente às arquiteturas dos
processadores BIP I e BIP II.
• RNF03: O sistema deverá ser desenvolvido em linguagem C#, sobre a plataforma .NET.
3.1.3 Regras de Negócio
• RN01: Na ajuda do sistema, deverão ser apresentadas informações a respeito das
funcionalidades do sistema, da linguagem Portugol utilizada e sobre a arquitetura dos
processadores simulados.
• RN02: Durante a simulação do sistema deverá ser exibido os valores dos registradores
especiais e conteúdo da memória.
• RN03: Os programas compilados deverão ser escritos de acordo com a linguagem
Portugol definida para o sistema e descrita na ajuda do sistema.
3.1.4 Modelo de Casos de Uso
O modelo de casos de uso apresentado na Figura 18 representa o relacionamento do usuário
com as funcionalidades do sistema. A seguir são descritos os cenários de cada caso de uso.
49
Figura 18. Modelo de Casos de Uso
3.1.4.1 UC01. Cria Programa
Permite que o usuário crie um programa em linguagem Portugol.
Cenários
Cria Programa {Principal}
1. O sistema exibe o ambiente de desenvolvimento.
2. O usuário escreve o programa em linguagem Portugol.
3.1.4.2 UC02. Compila Programa
Permite que o usuário compile um programa.
Cenários
Compila Programa {Principal}
1. O usuário seleciona a opção compilar.
50
2. O sistema compila o programa escrito na ferramenta.
3. O sistema realiza a análise léxica, sintática e semântica do programa.
Erros {Exceção}
1. No passo 3, caso seja encontrado algum erro no programa, o sistema deverá exibir ao
usuário uma mensagem informando o erro ocorrido.
3.1.4.3 UC03. Simula Programa
Permite ao usuário simular o funcionamento do programa nos processadores BIP I e BIP II.
Cenários
Simula Programa {Principal}
1. O usuário seleciona a opção Simulação.
2. O sistema solicita que o usuário escolha a arquitetura simulada (BIP I ou BIP II).
3. O sistema exibe o programa sendo executado no processador escolhido.
Simula Programa Passo a Passo {Alternativo}
1. O sistema solicita que o usuário escolha a arquitetura simulada (BIP I ou BIP II).
2. O usuário seleciona a opção Simulação Passo a Passo.
3. O sistema exibe o programa sendo executado no processador escolhido, executando uma
linha do programa ou uma instrução assembly a cada passo da execução.
Programa não Suportado pela Arquitetura Escolhida {Exceção}
1. No passo 2, caso o programa apresente instruções não compatíveis com o processador
selecionado, o sistema exibirá ao usuário uma mensagem informativa.
51
3.1.4.4 UC04. Visualiza Ajuda
Permite ao usuário visualizar arquivos de ajuda sobre o sistema.
Cenários
Visualiza Ajuda Programa {Principal}
1. O usuário seleciona a opção Ajuda.
2. O sistema exibe informações referentes ao funcionamento do sistema e informações sobre
os processadores simulados.
3.2 DEFINIÇÃO DA LINGUAGEM
De acordo com as características arquiteturais dos processadores BIP I e BIP II, descritas
nas subseções 2.2.1 e 2.2.2 , definiu-se um subconjunto da linguagem Portugol que possa
representar as operações suportadas pelo hardware dos processadores BIP.
O programa escrito na linguagem Portugol utilizada deve ter uma estrutura semelhante ao
programa ilustrado na Figura 19. A sintaxe completa da linguagem é apresentada no Anexo II.
As subseções a seguir descrevem aspectos dessa linguagem.
Estrutura Programa
programa <nome_do_programa>
declarações
<definição_de_constantes>
<declaracao_de_variaveis>
inicio
<instrucoes_do_programa>
fim
programa soma
declaracoes
inteiro a, b, soma
inicio
a <- 3
b <- 2
soma <- a + b
fim
Figura 19. Estrutura do programa Portugol
52
3.2.1 Diretrizes para definição do subconjunto da linguagem Portugol
Uma gramática determina quais símbolos e de que forma eles podem ser agrupados ou
produzidos para que sejam reconhecidos pelos analisadores léxico, sintático e semântico.
As regras de uma gramática podem ser representadas através de uma regra gramatical em
BNF (Backus-Naur Form – Forma Backus-Naur). Esta notação costuma apresentar quatro
componentes principais (AHO et al., 2008):
1. Conjunto de Símbolos Terminais (tokens): símbolos elementares reconhecidos pela
gramática;
2. Conjunto de Não-terminais: cada não terminal representa um conjunto de cadeias de
terminais;
3. Conjunto de Produções: cada produção consiste em um não-terminal (lado esquerdo da
produção), um símbolo (normalmente uma seta) e uma sequência de terminais e/ou não-
terminais (lado direito da produção); e
4. Símbolo Inicial: um dos símbolos não terminais é definido como símbolo inicial da
gramática.
A Tabela 6 apresenta o conjunto de símbolos da linguagem Portugol utilizada neste projeto.
Foram disponibilizadas as estruturas básicas de desvio e repetição, além dos elementos necessários
para estruturar as soluções como um programa.
53
Tabela 6. Lista de símbolos da gramática Portugol
Portugol Descrição
programa Símbolo inicial da gramática
declaracoes Definição de bloco de declaração de variáveis
defina Definição de constantes
inicio Identifica o início do algoritmo
fim Identifica o fim do algoritmo
inteiro Tipo de dado numérico inteiro10
se ___ entao Desvio condicional
senao Negação do ‘SE’
fimse Fim de bloco de desvio condicional
enquanto ___ faca Laço de repetição com condição no inicio
fimenquanto Fim de bloco de laço condicional
repita ___ quando Laço de repetição com condição no fim
para __ ate __ passo __ Laço condicional com repetição incremental
fimpara Fim de bloco de laço condicional com repetição incremental
<- Operador de atribuição
(,) Parênteses
+, - Operadores aritméticos
>, <, <=, >=, !=, = Operadores relacionais
A definição completa da gramática Portugol definida para a ferramenta ANTLR é
apresentada no Apêndice A.
10 Os processadores BIP suportam apenas dados do tipo inteiro de 16 bits com sinal.
54
3.3 IMPLEMENTAÇÃO
Para a implementação do Bipide utilizou-se duas ferramentas de desenvolvimento de
software: Visual Studio 2008 (MICROSOFT CORPORATION, 2009b) e Expression Blend 2
(MICROSOFT CORPORATION, 2009a). Utilizou-se também a ferramenta ANTLRWorks11
(PARR, 2009) para a definição da gramática e geração dos analisadores do compilador.
O Visual Studio 2008 foi utilizado para a implementação da interface e das classes que
compõem o sistema em linguagem C#. Os elementos gráficos e animações que compõem o
simulador do processador BIP foram desenvolvidos através da ferramenta Expression Blend 2
A implementação do sistema dividiu-se em cinco etapas principais: (i) desenvolvimento da
interface de programação e simulação; (ii) definição das animações das instruções dos
processadores BIP; (iii) implementação do gerador de código; (iv) integração do gerador de código
com o ambiente de simulação; e (v) realização de testes. Sendo assim, as seções seguintes
apresentam as técnicas utilizadas em cada uma das etapas.
3.3.1 Implementação do compilador
Para a implementação do compilador, foi utilizada a ferramenta ANTLRWorks, através da
qual foi possível gerar o analisador léxico e sintático do compilador. Também foram definidas,
através do ANTLRWorks, as ações semânticas necessárias para a geração de código.
Ao final da análise do programa fonte, escrito em Portugol, é gerado um arquivo em
linguagem de montagem para os processadores BIP. Este código é dividido em duas seções: (i)
cabeçalho (.data ), onde podem ser declaradas as variáveis utilizadas no programa e (ii) código
(.text) , onde estão implementadas as instruções do programa.
A fim de tornar possível a compreensão do que foi desenvolvido, serão mostradas e
comentadas as principais ações semânticas utilizadas para a geração do código assembly.
11 O ANTLRWorks é um ambiente de desenvolvimento com interface gráfica de usuário para o desenvolvimento de gramáticas para o ANTLR.
55
3.3.1.1 Geração de código para declarações e definição de variáveis
A declaração de variáveis no código assembly gerado fica localizada dentro da seção
.data . Foi utilizada uma estrutura de dados do tipo lista com o objetivo de armazenar estas
variáveis para verificação no decorrer do programa. Esta verificação permite identificar variáveis
não declaradas, não utilizadas ou declaradas mais de uma vez.
A Tabela 7 mostra as ações semânticas para geração de código para declaração de variáveis,
onde as partes da gramática aparecem em negrito.
Tabela 7. Ações Semânticas para a geração de declaração e definição de variáveis
Ações Semânticas Portugol Assembly
1. dec_const : DEFINA ID VINT
2. { if (busca_tab($ID.text) == NAO_ACHOU)
3. insere_tab($ID.text, $VINT.text);}
4. ;
5. dec_var : INTEIRO lista_var {
6. if (busca_tab($lista_var.text) == NAO_ACHOU)
7. insere_tab($lista_var.text);}
8. ;
9. lista_var : ID (',' ID) * ;
DEFINA A 5
INTEIRO B
A : 4
B : 0
Na linha 2, o nome do identificador é procurado na lista de variáveis e caso não seja
encontrado, o identificador da variável é inserido nesta tabela juntamente com o seu valor (linha 3).
Nas linhas 6 e 7, o mesmo é feito para cada uma das variáveis declaradas, porém são armazenados
somente os nomes das variáveis com o valor inicial 0. Optou-se por tratar as definições de
constantes como variáveis inicializadas, ao invés de substituí-la pelo valor definido, a fim de manter
o seu identificador e facilitar sua visualização.
3.3.1.2 Geração de código para desvios condicionais
Para a realização do desvio condicional são resolvidas inicialmente as expressões do lado
esquerdo e direito do operador relacional. Os resultados dessas expressões são armazenados em
variáveis temporárias e posteriormente, o resultado da expressão do lado direito é subtraído do valor
resultante da expressão do lado esquerdo do operador (Tabela 8, linhas 3 e 4). Como visto na Seção
2.2.2, as instruções de desvio do BIP baseiam-se no registrador de Status que armazena informações
sobre o ultimo resultado do ACC, portanto, esta operação de subtração ocorre em todas as
56
operações de desvio condicional e de acordo com o valor resultante a instrução seguinte determina
se o desvio será realizado.
Tabela 8. Ações Semânticas para a geração de desvios condicionais
Ações Semânticas Portugol Assembly
1. cmd_se: SE expRelacional
2. {
3. add_instrucao("LD", resultado_Esq);
4. add_instrucao("SUB", resultado_Dir);
5. add_instrucao(opRelacional,"ENDIF1”);
6. rotulos.Push("ENDIF1");
7. }
8. ENTAO lista_cmdo FIMSE
9. {
10. add_instrucao(rotulos.Pop());
11. }
12. ;
Se (x > 8) então
x <- 0
fimse
LD x
STO $100
LDI 8
STO $101
LD $100
SUB $101
BLE
ENDIF1
LDI 0
STO x
ENDIF1:
A instrução de desvio é gerada de acordo com o operador relacional utilizado (Tabela 8,
linha 4). O nome do rótulo é colocado em uma pilha (Tabela 8, linha 5) para utilização ao final da
expressão (Tabela 8, linha 9).
O método add_instrucao , utilizado no código da Tabela 8 (linha 10), adiciona a
instrução em uma estrutura de dados, que será utilizada para a geração de código e posterior
utilização na simulação do programa. Esta estrutura é apresentada na seção 3.3.3.
3.3.1.3 Geração de código para laços de repetição
As ações semânticas apresentadas na Tabela 9 ilustram a geração de código para uma
instrução de laço de repetição do tipo Enquanto - Faça.
Ao início da expressão (linhas 3 e 4) é adicionado o rótulo indicando o início do laço de
repetição, este mesmo rótulo é armazenado em uma pilha e será utilizado ao final da expressão
(linha 15). Após resolver a expressão relacional, é adicionada uma instrução de desvio referente ao
operador relacional utilizado (linha 9), esta instrução fará o programa saltar para o final do laço
quando sua condição for falsa.
57
Tabela 9. Ações Semânticas para a geração de desvios condicionais
Ações Semânticas Portugol Assembly
1. cmd_enq_faca: ENQUANTO
2. {
3. add_instrucao ("INI_ENQ1");
4. rotulos.Push("INI_ENQ1");
5. }
6. expRelacional
7. {
8. ...
9. add_instrucao(opRelacional, FIM_ENQ1);
10. rotulos.Push("FIMENQ1);
11. }
12. FACA lista_cmdo
13. {
14. rotulo_fim = rotulos.Pop();
15. add_instrucao("JMP", rotulos.Pop());
16. add_instrucao(rotulo_fim);
17. }
18. FIMENQUANTO;
enquanto (x>8)
faca
x <- 0
fimenquanto
INI_ENQ1:
LD x
STO 100
LDI 8
STO 101
LD 100
SUB 101
BLE FIM_ENQ1
LDI 0
STO x
JMP INI_ENQ1
FIM_ENQ1:
3.3.1.4 Geração de código para tratamento de erros
O ANTLR oferece recursos que facilitam a identificação de erros durante o processo de
compilação. O ANTLR gera, automaticamente, reconhecedores que emitem mensagens de erro de
sintaxe na linguagem fonte compilada. As mensagens de erro incluem informações que facilitam a
localização do erro no programa e informam qual o erro ocorrido (PARR, 2007b).
A Figura 20 exibe uma mensagem de erro gerada pelo ANTLR. Na mensagem, o termo
line 1:2 indica que o erro ocorreu na primeira linha do programa e no segundo caracter desta
mesma linha. A sequência da mensagem indica que a entrada 'a' é inválida, pois era esperado o
caractere ' )' .
line 1:2 mismatched input 'a' expecting ')'
Figura 20. Mensagem de erro gerada pelo ANTLR
58
As mensagens de erro geradas podem ser tratadas e personalizadas através da
implementação (sobrescrita) de dois métodos do código gerado pelo ANTLR:
getErrorMessage() e getTokenErrorDisplay() .
A abordagem adotada para a captura, tratamento e tradução das mensagens de erro do
compilador desenvolvido, consiste na adição de duas ações semânticas (uma no início e outra no
final) em cada uma das principais regras gramaticais do compilador e da sobrescrita do método
getErrorMessage() .
Como pode ser visto na Figura 21, a ação implementada no inicio da regra (linha 2)
adiciona em uma pilha o nome do comando que está sendo analisado.
1. cmd_repita
2. @init { paraphrases.Push("REPITA"); }
3. @after { paraphrases.Pop(); }
4. REPITA cmdo+ QUANDO '(' exp ')';
Figura 21. Ações semânticas para inserção de nome do comando nas mensagens de erro
Durante sua execução, eventuais mensagens de erro serão capturadas através do método
getErrorMessage() (Figura 22), neste método as mensagens são traduzidas, formatadas e
concatenadas com o nome do comando que as gerou, o qual estava armazenado na pilha de
comandos. Ao final da regra (Figura 21, linha 3) o comando é retirando da pilha.
1. public override String GetErrorMessage(RecognitionE xception e, String[]
tokenNames){
2. String linha = e.Line.ToString();
3. String pos = e.Char.ToString();
4. String msg = e.Message;
5. msg = Traduz ( msg ); //traduz mensagem
6. msg = "Erro na linha " + linha + ": " + posicao + msg; //formata mensagem
7. msg = msg + paraphrase.Peek(); //adiciona com ando
8. printErro(msg); //exibe mensagem
9. }
Figura 22. Implementação do Método GetErrorMessage para tratamento de erros gerados
59
3.3.2 Implementação do simulador
Para a implementação do simulador do processador utilizou-se a ferramenta Expression
Blend 2. O Expression Blend é uma ferramenta de design destinada à criação de aplicações em
WPF para a plataforma Windows ou para a Web, através do Silverlight12 (MICROSOFT
CORPORATION, 2008c). Ele apresenta uma interface orientada por design para aplicações
baseadas na linguagem XAML e apresenta compatibilidade com a ferramenta Visual Studio 2008
(MICROSOFT CORPORATION, 2008b). A Figura 23 apresenta uma visão geral da interface do
Expression Blend 2.
Figura 23. Visão geral da ferramenta Expression Blend 2
Utilizou-se esta ferramenta – ao invés do próprio Visual Studio 2008 – devido às facilidades
oferecidas pela mesma para a criação de interfaces e componentes gráficos de interação com o
usuário. A Tabela 10 demonstra as principais características da ferramenta Expression Blend 2 em
relação ao Visual Studio 2008.
12 Silverlight é uma tecnologia para a construção de aplicativos ricos e interativos na internet.
60
Tabela 10. Características do Expression Blend 2 em relação ao Visual Studio 2008 Funcionalidade Expression Blend 2 Visual Studio 2008 Leiautes Dinâmico Dinâmico Estilos Editor Visual Não possui Modelos Editor Visual Não possui Edição de Código Editor Básico IntelliSense13 Recursos Editor Visual Edição no arquivo XAML Animação Editor Visual Edição no arquivo XAML Exportação de arquivo XAML Sim Sim
Fonte: Adaptado de Januszewski e Rodriguez (2007).
Através do Expression Blend é possível utilizar os controles padrões do Windows como
botões, menus e caixas de textos integrados com elementos gráficos, 3D e recursos de áudio e
vídeo, possibilitando a utilização de estilos personalizados. O Expression Blend permite também
animar propriedades individuais de objetos ao longo do tempo, o que possibilita a definição de
animações (MICROSOFT, 2008c; WILLIAMS, 2008).
A Figura 24 exibe trecho de uma animação definida no Expression Blend 2 para a simulação
de uma instrução.
Figura 24. Implementação de uma animação através do Expression Blend 2
13 Nome adotado pela Microsoft para definir sua implementação de completamento de código utilizado em ferramentas de desenvolvimento.
61
Na parte inferior da figura é apresentado o painel Interaction, onde estão dispostas as linha
de tempo que representam uma animação ao longo do tempo (storyboard). Nesta animação o
componente rOperando é movido de uma posição para outra (Motion Path). Esse movimento tem
duração de quatro segundos, iniciando dois segundo após o tempo relativo zero.
3.3.2.1 Definição das animações das instruções do processador
Esta seção apresenta a animação ocorrida durante a simulação de uma instrução no
processador, a fim de exemplificar como ocorrem as animações durante a simulação de um
programa.
A Figura 25 demonstra o início da simulação de uma instrução ADD 5. No canto inferior
esquerdo é exibida a memória de programa, onde a instrução sendo executada encontra-se destacada
(1). O operando e o caminho a ser percorrido por ele é destacado na cor verde (2), simbolizando que
este operando representa um endereço de memória. No lado esquerdo da figura, paralelamente à
animação da instrução, é exibida também a animação que representa a atualização do PC (3).
Figura 25. Início da animação de uma instrução ADD
Na Figura 26, a posição de memória indicada pelo operando da instrução ADD é destacado
na memória de dados (1). O valor armazenado no endereço 5 da memória de dados é carregado para
a ULA (2), onde será somado com o valor -1, que estava armazenado no acumulador. Conforme
demonstrado na Figura 26, os blocos que contém os valores 0 e 2 são apresentados em amarelo (2 e
3) e o caminho percorrido por eles é destacado na cor vermelha para demonstrar que estes valores
representam dados.
1
3
2
62
Figura 26. Sequência da animação de uma instrução ADD
Após ser realizada a soma dos operandos pela ULA, o resultado é novamente carregado para
o acumulador, como demonstrado na Figura 27 (1).
Figura 27. Final da animação de uma instrução ADD
Durante a simulação, os sinais de controle ativos também são destacados para representar
sua utilização (Figura 27 (2))
3.3.3 Integração do compilador e demais componentes do ambiente
Para o desenvolvimento da interface utilizou-se o componente TabStripp (G.C., 2009). Este
componente possibilita a criação de menus no estilo Ribbon14 para aplicações .NET e possui
14Estilo de interface que apresenta comandos organizados em um conjunto de abas que exibem painéis com os recursos mais relevantes para determinada tarefa. Segundo Microsoft Corporation (2009c), estas abas simplificam o acesso aos recursos da aplicação, pois estes são agrupados de maneira que correspondem diretamente as funções que serão desempenhadas.
1
2
2 3
1
63
elementos de interface que possibilitam a seleção de diferentes temas para a interface do sistema
que o utiliza.
Utilizou-se o editor FireEdit (THE CODE PROJECT, 2009), componente integrante do
projeto dotNetFireball (CODEPLEX, 2009), que visa o desenvolvimento de bibliotecas e
componentes para o desenvolvimento de aplicações. Este editor apresenta algumas funcionalidades
que auxiliam a escrita de programas, entre elas citam-se: (i) utilização de diferentes cores e
formatação de fonte para identificar palavras reservadas e símbolos da linguagem (syntax
highlighting); (ii) identificação de aberturas e fechamentos de parênteses; e (iii) possibilidade de
utilizar vários arquivos simultaneamente. Este editor utiliza a sintaxe de algumas linguagens de
programação como C e Java, e permite configurar novas sintaxes através de arquivos XML, onde
podem ser definidos novos símbolos, blocos de programa e a formatação da sintaxe exibida no
editor.
O ANTLR possibilita a geração de código em diferentes linguagens, entre elas o C#. Este
fato facilitou a utilização do compilador no ambiente Bipide, pois permitiu que as classes geradas
pelo ANTLR fossem adicionadas ao ambiente, podendo então ser instanciadas pelo mesmo. A
seleção da linguagem é definida no ANTLR através da inserção de uma diretiva colocada no inicio
da gramática. No caso do C# duas opções podem ser utilizadas: (i) language='CSharp' ; e (ii)
language='CSharp2' . A principal diferença identificada entre as duas opções está na
utilização de classes parciais15, suportadas preferencialmente na versão 2.
O ANTLR gera duas classes principais: Lexer e Parser . A classe Parser inclui as
ações semânticas definidas na gramática. Na integração do compilador com o ambiente Bipide, foi
adicionada à classe Parser uma classe parcial onde são implementadas as ações semânticas e o
tratamento de erros.
Para facilitar a utilização dos códigos fonte e assembly durante a simulação do programa, os
mesmos são armazenados em uma estrutura, como representado no diagrama de classes da Figura
28. Esta estrutura facilita a organização dos códigos exibidos no módulo de simulação, além de
15 O conceito de classe parcial utilizada no C# permite separar o código de uma classe em arquivos físicos diferentes. Durante a compilação todos os arquivos da classe parcial são agrupados, gerando uma única entidade.
64
permitir o controle sobre a execução do programa, pois possibilita relacionar as instruções Portugol
com as instruções assembly correspondentes geradas durante a compilação.
Figura 28. Visão simplificada das classes onde são armazenados os códigos do Programa
A classe InstrucaoASM armazena as instruções assembly do programa e os índices que
indicam a linha da instrução no arquivo gerado e sua posição na memória de programas do
processador.
Na classe InstruçãoPortugol são armazenadas as instruções Portugol, as quais tem
associadas a ela uma lista de instruções assembly. Esta classe indica ainda em que linha do
programa está a instrução e a indentação desta instrução dentro do programa.
A classe Codigo possui uma lista de instruções Portugol e métodos que possibilitam
adicionar e consultar as instruções presentes nas outras classes.
O simulador desenvolvido em WPF pôde ser integrado ao ambiente devido à
compatibilidade desta tecnologia com as aplicações .Net, viabilizando a utilização de controles
desenvolvidos em WPF em aplicações Windows Forms.
class Bipide Classes
Codigo
+ l istaPortugol : List
+ addInstrucaoASM(String, String, T ipo) : void+ addInstrucaoPortugol(String, int) : void+ getCodigoPortugol() : List<InstrucaoPortugol>+ getCodigoASM() : List<InstrucaoASM>+ getInstrucaoASM(int) : InstrucaoASM+ getInstrucaoPortugol(int) : InstrucaoPortugol
InstrucaoPortugol
+ instrucao: String+ instrucaoASM: List+ identacao: int+ indexArquivo: int
+ getInstrucaoPortugol() : String
InstrucaoASM
+ instrucao: String+ indexArquivo: int+ indexMemoria: int+ tipo: T ipo+ operando: String
+ getInstrucaoASM() : String
1..
0..*
1 1..*
65
3.3.4 Visão geral das funcionalidades e dos aspectos da interface gráfica
Para a disposição dos módulos dentro do ambiente utilizou-se o recurso de abas. Na parte
superior da interface são apresentados os painéis de opções do sistema, através dos quais o usuário
poderá interagir com o sistema e ter acesso as suas funcionalidades.
O sistema apresenta três módulos principais: (i) Programação, onde o usuário poderá
escrever e compilar programas; (ii) Simulação, onde poderão ser simulados os programas
desenvolvidos; e (iii) Ajuda, onde são apresentadas informações a respeito das funcionalidades do
sistema e sobre a arquitetura e organização dos processadores BIP.
3.3.4.1 Módulo de Programação
A Figura 29 apresenta a interface do módulo de programação. Os principais elementos da
interface foram numerados e serão explicados a seguir.
Figura 29. Interface do módulo de programação
1 2 3
4
5
66
1. Gerenciamento de Arquivo: oferece ao usuário as opções de gerenciamento de arquivo:
Novo, Abrir, Salvar, salvar como e Imprimir;
2. Edição: possibilita ao usuário editar os documentos abertos através das opções: Recortar,
Copiar, Colar, Selecionar tudo, Procurar, Desfazer e Refazer;
3. Compilar: apresenta ao usuário a opção de compilar um programa;
4. Editor: local onde usuário poderá escrever programas. Este editor apresenta algumas
características que podem facilitar o desenvolvimento de programas, como:
- Utilização de diferentes cores para identificar palavras reservadas e símbolos da
linguagem.
- Identificação do início e final de cada bloco de programa. Por exemplo, ao selecionar a
palavra ‘se’, será destacado também a palavra ‘fimse’ que representa o final deste bloco
de comando. Também são identificados as aberturas e fechamentos de parênteses.
- Possibilidade de contrair ou expandir os blocos do programa (collapse).
- Indicação dos números de linha.
- Possibilidade de abrir diferentes arquivos ao mesmo tempo, organizados dentro do
editor através de abas; e
5. Mensagens: exibe alertas e mensagens de erro ocorridas durante a compilação do
programa. Ao clicar sobre a descrição do erro, o cursor é posicionado na linha onde o
erro foi acusado.
3.3.4.2 Módulo de Simulação
A Figura 30 exibe a interface do módulo de simulação, onde os principais elementos foram
numerados e serão explicados a seguir.
67
Figura 30. Interface do módulo de simulação
1. Simulação: apresenta os botões que permitem ao usuário controlar a simulação do
programa e verificar sua execução passo a passo. Os botões para controle da simulação
são:
- Simular: inicia a simulação de um programa;
- Pausar: interrompe temporariamente a simulação do programa;
- Repetir: repete a última instrução simulada;
- Próximo: simula a próxima instrução do programa;
- Continuar: continua a simulação do programa até o seu final;
- Parar: interrompe a simulação do programa.
2. Velocidade: através desta opção, o usuário pode controlar a velocidade com que ocorre a
simulação do programa;
3 2 1
4 5
7
8
6
68
3. Simulador de instruções: o usuário poderá simular uma instrução específica do
processador, sem a necessidade de escrever um programa completo. Para isto, poderá ser
digitado o valor do operando no campo específico e pressionado o botão correspondente
à instrução que deverá ser simulada.
4. Programa Portugol: exibe o programa Portugol que está sendo simulado. Neste editor, a
linha do programa que está sendo simulada aparece destacada.
5. Programa assembly: exibe o código assembly gerado pelo compilador. Neste editor, a
linha do programa que está sendo simulada aparece destacada. É destacado também o
conjunto de instruções assembly que correspondem a uma linha do programa Portugol,
permitindo ao usuário verificar quais instruções assembly foram geradas para executar
uma instrução Portugol. No programa da Figura 30, foram geradas sete linhas de código
assembly, para executar a instrução Portugol correspondente.
6. Processador BIP: exibe a imagem da arquitetura do processador BIP I ou BIP II, onde
ocorrem as animações que representam a execução das instruções no processador, como
descrito na subseção 4.2.1. A fim de facilitar o entendimento do simulador, os principais
componentes do mesmo são nomeados e, com dois cliques, é exibida uma janela
informativa a respeito do componente.
7. Valores dos Registradores: exibe os valores dos registradores do processador durante a
simulação do programa.
8. Descrição: exibe o nome da instrução simulada e uma descrição da ação ocorrida, a fim
de auxiliar o usuário a compreender o que está ocorrendo no processador.
A interface do módulo de simulação foi concebida pensando-se na possibilidade do usuário
visualizar, ao mesmo tempo, os três elementos utilizados: linguagem alto-nível, linguagem
assembly e organização do processador. Isto permite que sejam realizadas comparações e
associações entre estes três elementos, colaborando para a redução da abstração apresentada nos
conceitos de programação. A Figura 31 ilustra uma relação que pode ser estabelecida, onde o
mesmo valor pode ser visto nos três elementos desta interface.
69
Figura 31. Relação de elementos na interface do módulo de simulação
O ambiente apresenta ainda algumas opções de configuração, através das quais o usuário
poderá:
1. Ocultar a descrição das ações do processador;
2. Ocultar o painel com os valores dos registradores;
3. Ocultar a animação da atualização do PC;
4. Alterar a cor da interface do programa;
3.3.4.3 Módulo de Ajuda
O principal objetivo do módulo de ajuda do Bipide é apresentar informações didáticas a
respeito da teoria que fundamenta a ferramenta. Como especificado no projeto da ferramenta, este
módulo deverá ainda apresenta explicar os principais elementos da interface do ambiente.
O módulo de ajuda apresenta duas opções principais:
1. Informações sobre Arquitetura e Organização de computadores e a respeito dos
processadores BIP; e
70
2. Informações referentes às funcionalidades do ambiente.
A Figura 32 exibe a interface do módulo de ajuda, exibindo um tópico a respeito dos
processadores BIP.
Figura 32. Interface do módulo de ajuda
Para auxiliar o entendimento do simulador, cada um dos principais componentes dos
processadores BIP exibe, através de um duplo clique, uma janela com informações a respeito deste
componente. Os elementos de interface como botões e campos de texto também apresentam ajuda
sensível ao contexto, exibida quando pressionada a tecla F1.
3.3.5 Verificação
3.3.5.1 Testes
Durante a implementação das ações semânticas do compilador, foi utilizado um conjunto de
aplicações Portugol para sua validação. Estes programas foram compilados pelo compilador
desenvolvido e os códigos assembly gerados foram analisados e comparados com os resultados
esperados.
2 1
71
A Tabela 11 apresenta um dos programas utilizados e o código assembly gerado. Este
programa foi utilizado para auxiliar a validação de uma instrução de laço de repetição.
Tabela 11. Programa utilizado para validar uma instrução de laço de repetição
Portugol Assembly programa _para declaracoes inteiro x inteiro y inicio y<-0 para x <- 1 ate 5 passo 1 y <- 1 + x fimpara
fim
.DATA X : 0 Y : 0
.TEXT LDI 0 STO y LDI 1 STO x LDI 5 STO 100 LDI 1 STO 101 LD x
PARA1: SUB 100 BGT FIMPARA1 LDI 1 ADD x STO y LD x ADD 101 STO x JMP PARA1
FIMPARA1:
O conjunto de todos os programas que serviram de teste para a validação do compilador é
apresentado no Apêndice C.
Para a validação do simulador foram utilizados testes unitários a fim de verificar a
simulação de cada instrução do processador. Foi utilizado um conjunto de instruções assembly,
adaptado de Pereira (2008), para verificar o estado esperado para os registradores e memórias. Após
serem simulados, os valores resultantes foram analisados e comparados com o obtido previamente
em Pereira (2008). Este mesmo conjunto de instruções já havia sido utilizado para validação da
arquitetura do microcontrolador µBIP. As instruções utilizadas e os resultados obtidos após a
simulação das mesmas são apresentados no Apêndice B.
Para teste final de integração da ferramenta, os códigos assembly resultantes da fase de
testes do compilador foram também simulados e tiveram seus resultados analisados.
Os resultados obtidos durante os testes se mostraram consistentes e corresponderam aos
resultados esperados. Vale salientar que os códigos assembly resultantes do processo de compilação
72
não passam por nenhuma otimização de código, o que resulta em um maior número de instruções
geradas. No entanto, isto não prejudica o resultado do trabalho, pois atende os objetivos didáticos
especificados.
3.3.5.2 Avaliação
Não foi possível realizar uma avaliação em sala de aula a fim de verificar os benefícios da
utilização do ambiente nas disciplinas de programação, como previsto no projeto inicial. Isso se
deve ao fato da ferramenta não ter sido concluída a tempo de ser utilizada no momento adequado,
dentro da grade curricular da disciplina (inicio do semestre).
No entanto, foi realizada uma experiência de utilização do ambiente por alunos da disciplina
de Algoritmos e Programação do primeiro período do curso de Ciência da Computação da
UNIVALI. Este experimento foi realizado no final do semestre letivo e teve como principal
objetivo avaliar a interface do ambiente, a fim de verificar possíveis melhorias a serem realizadas.
Os alunos tiveram acesso ao ambiente Bipide e, após sua utilização, responderam um
questionário composto por seis perguntas a respeito da interface do ambiente. O questionário
aplicado e os resultados obtidos são apresentados nos Apêndices D e E.
4 CONCLUSÕES
Neste trabalho foi apresentado o ambiente de desenvolvimento integrado Bipide. Este
ambiente foi planejado para uso em disciplinas introdutórias de Algoritmos e Programação e
permite relacionar conceitos de Arquitetura de Computadores com a lógica de programação.
Espera-se com isto contribuir para a redução da abstração envolvida no ensino da programação e
em conseqüência, facilitar o aprendizado por alunos destas disciplinas.
O ambiente desenvolvido é composto por: (i) um editor de textos destinado ao
desenvolvimento de programas em linguagem Portugol; (ii) um compilador que traduz a linguagem
Portugol para assembly dos processadores BIP; (iii) um simulador dos processadores BIP I e BIP II
capaz de simular as instruções destes processadores exibindo graficamente sua execução por meio
de animações; e (iv) um módulo de ajuda composto por informações teóricas relacionadas à
Arquitetura e Organização de computadores, processadores BIP e funcionalidades do sistema.
Com a realização deste trabalho pôde-se consolidar e aplicar uma série de conhecimentos
adquiridos durante o bacharelado em Ciência da Computação. Teve-se ainda a possibilidade de
conhecer tecnologias e ferramentas até então desconhecidas para este acadêmico.
A pesquisa bibliográfica realizada permitiu compreender e aprofundar conceitos em
Arquitetura e Organização de Computadores e Compiladores, duas áreas relacionadas a este projeto.
Também foram realizados estudos sobre a família de processadores BIP e tecnologias utilizadas
para o desenvolvimento do trabalho. Através da análise de ferramentas similares pode-se ter uma
idéia das características e funcionalidades destas ferramentas, as quais serviram para definir alguns
aspectos do ambiente Bipide, de forma que este apresente alguma contribuição enquanto ferramenta
educacional.
Durante a implementação do ambiente utilizou-se a tecnologia WPF e a ferramenta
Expression Blend 2. Ressalta-se a facilidade disponibilizada por estas tecnologias para o
desenvolvimento de aplicações que exigem muitos recursos de interface, como a utilização de
animações. Estas tecnologias integradas às demais ferramentas e componentes utilizados resultou
em uma interface gráfica capaz de proporcionar uma melhor experiência para o usuário, agregando
valor ao ambiente desenvolvido.
74
Destaca-se que os objetivos definidos para este trabalho foram alcançados e relatados neste
documento. São eles:
1) Consolidar conceitos sobre compiladores: na Seção 2.4 são apresentados os conceitos
que propiciaram o desenvolvimento do compilador utilizado no ambiente;
2) Consolidar conceitos de arquitetura e organização de computadores: o estudo realizado
resultou no texto apresentado na Seção 2.1 deste trabalho;
3) Estudar a arquitetura e o conjunto de instruções dos processadores BIP: a Seção 2.2
descreve os objetivos e características dos processadores BIP, os quais foram
considerados no desenvolvimento do trabalho;
4) Implementar e disponibilizar um ambiente de desenvolvido integrado para programação
em linguagem Portugol e visualização do assembly e do estado dos componentes dos
processadores BIP: este trabalho resultou no ambiente Bipide, cujo projeto e
desenvolvimento são descritos no Capítulo 3. O ambiente encontra-se pronto para ser
utilizado em experimentações em sala de aula;
5) Testar e Verificar o sistema desenvolvido: foram realizados testes a fim de verificar as
funcionalidades do ambiente. Também foi realizada uma avaliação com alunos da
disciplina de Algoritmos e Programação a fim de coletar informações sobre a satisfação
destes usuários com a ferramenta e possíveis melhorias a serem implementadas no
ambiente. Os procedimentos utilizados e os resultados obtidos são descritos na Seção
3.3.5 deste trabalho;
6) Documentar e divulgar o projeto: a documentação do projeto é composta pela redação
deste trabalho. Ainda serão redigidos artigos que deverão ser submetidos a eventos da
área.
Vale salientar que este trabalho é parte integrante de um projeto que visa promover a
integração interdisciplinar, permitindo que os processadores da família BIP possam ser utilizados
em diferentes fases e disciplinas de cursos de graduação e pós-graduação. Busca-se ainda elucidar
qual o impacto do uso de um modelo simplificado de computador na compreensão de conceitos
básicos ligados ao ensino inicial de algoritmos. Neste aspecto, o ambiente Bipide irá permitir
75
coletar evidências empíricas sobre a vantagem em reduzir o nível de abstração envolvido nesta
aprendizagem.
No decorrer deste trabalho foram identificadas diversas oportunidades de trabalhos co-
relacionados a este. Sugere-se: (i) suporte a arquitetura do processador µBIP; (ii) utilização de
diferentes linguagens de alto nível como C, Java, entre outras; (iii) suporte a diferentes formatos
numéricos como, por exemplo, hexadecimal; (iv) otimização do código assembly gerado; (v)
desenvolvimento de uma versão on-line para o ambiente; (vi) implementação e integração de novos
módulos que agreguem funcionalidades ao ambiente; e (vii) avaliação da utilização da ferramenta
em sala de aula.
REFERÊNCIAS BIBLIOGRÁFICAS
AHO, Alfred V. et al. Compiladores: princípios, técnicas e ferramentas. 2. ed. São Paulo: Pearson Addison-Wesley, 2008.
BEČVÁŘ, Miloš; KAHÁNEK, Stanislav. VLIW-DLX simulator for educational purposes. In: WORKSHOP ON COMPUTER ARCHITECTURE EDUCATION, 2007, San Diego, California. Proceedings… New York, NY: Acm, 2007. p. 8-13. Disponível em: <http://portal.acm.org/citation.cfm?id=1275633.1275636>. Acesso em: 13 set. 2008.
BORGES, José Antonio. S.; SILVA, Gabriel P. NeanderWin – Um simulador didático para uma arquitetura do tipo Acumulador. In: WORKSHOP SOBRE EDUCAÇÃO EM ARQUITETURA DE COMPUTADORES, 1., 2006, Ouro Preto. Proceedings… Porto Alegre: SBC, 2006.
BORUNDA, Patrick; BREWER, Chris; ERTEN, Cesim. GSPIM: graphical visualization tool for MIPS assembly programming and simulation. In: TECHNICAL SYMPOSIUM ON COMPUTER SCIENCE EDUCATION, 2006, Houston, Texas. Proceedings… New York, NY: Acm, 2006. p. 244-248. Disponível em: <http://doi.acm.org/10.1145/1121341.1121416>. Acesso em: 10 set. 2008.
BRORSSON, Mats. MipsIt: A Simulation and Development Environment Using Animation for Computer Architecture Education. In: WORKSHOP ON COMPUTER ARCHITECTURE EDUCATION, 2002, Anchorage, Alaska. Proceedings… New York, NY: Acm, 2002. Disponível em: <http://portal.acm.org/citation.cfm?id=1275462.1275479>. Acesso em: 13 set. 2008.
CANCIAN, Rafael. Aperfeiçoamento do sistema Simularq em vários níveis de abstração. In: CONGRESSO BRASILEIRO DE COMPUTAÇÃO, 1., 2001, Itajaí. Anais... Itajaí - SC: UNIVALI, 2001. p. 29-45.
CANCIAN, Rafael. Simularq: simulador de arquitetura de computador CISC da família Motorola 68000. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Universidade Federal de Santa Catarina, Florianópolis, 1997.
CARBONE A.; KAASBOLL, J. A survey of methods used to evaluate computer science teaching. In: CONFERENCE ON THE TEACHING OF COMPUTING, 6., 1998, Dublin. Proceedings… [S.I.: s.n.], 1998.
CARTER, Nicholas P. Teoria e problemas de arquitetura de computadores. Porto Alegre: Bookman, 2003.
CODEPLEX. Dotnetfireball. Disponível em: <http://dotnetfireball.codeplex.com/>. Acesso em: 06 jun. 2009.
COSTA, Marden Menezes. XIX : Ferramenta de Geração de Interface Gráfica XAML para Windows Presentation Foundation. 2006. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Universidade Federal de Pernambuco, Recife, 2006. Disponível em: <http://www.cin.ufpe.br/~tg/2005-2/mmc3.pdf>. Acesso em: 03 maio 2009.
DELAMARO, Márcio Eduardo. Como construir um compilador utilizando ferramentas Java. São Paulo: Novatec, 2004.
77
G.C., Juan Pablo. An easy way to add a Ribbon Panel Office 2007 style. Disponível em: <http://www.codeproject.com/KB/miscctrl/fireballcodeeditor.aspx>. Acesso em: 06 jun. 2009.
GONÇALVES JUNIOR, Nelson Antonio et al. R10k: Um simulador de arquitetura superescalar. In: WORKSHOP DE EDUCAÇÃO EM ARQUITETURA DE COMPUTADORES, 2007, Gramado. Anais... Porto Alegre: SBC, 2007.
GOOD, Judith; BRNA, Paul. Program comprehension and authentic measurement: a scheme for analyzing descriptions of programs. Journal of Human-Computer Studies, v.61, 2004.
HENNESSY, John L.; PATTERSON, David A. Arquitetura de computadores: uma abordagem quantitativa. Rio de Janeiro: Campus, 2003.
JANUSZEWSKI, Karsten; RODRIGUEZ, Jaime. The New Iteration: How XAML Transforms the Collaboration Between Designers and Developers in Windows Presentation Foundation. [S.l.]: Microsoft Corporation, 2007. Disponível em: <http://www.rhizohm.net/papers/the_new_iteration.pdf>. Acesso em: 03 maio 2009.
KHALIFE, Joseph T. Threshold for the introduction of Programming: Providing Learners with a Simple Computer Model. In: INTERNATIONAL CONFERENCE ON INFORMATION TECHNOLOGY INTERFACES, 2006. Proceedings… [S.l.: s.n.], 2006.
KOLLROSS, Diogo. Sins: um editor Xchart na forma de plugin para o ambiente Eclipse. 2007. 90f. Dissertação (Mestrado em Ciência da Computação) - Universidade Estadual de Campinas, Campinas, 2007. Disponível em: <www.geocities.com/diogok_br/tese/tese-v07.pdf>. Acesso em: 19 out. 2008.
LOUDEN, Kenneth C. Compiladores: princípios e práticas. São Paulo: Pioneira Thomson Learning, 2004.
MacVITTIE, Lory A. XAML in a Nutshell . Sebastopol: O'Reilly, 2006.
MENEZES, C. S.; NOBRE, A. M. Um ambiente cooperativo para apoio a cursos de introdução a programação. In: WORKSHOP DE EDUCAÇÃO EM COMPUTAÇÃO, 2002. Anais do XXII Congresso da Sociedade Brasileira de Computação. Porto Alegre: SBC, 2002.
MICROSOFT CORPORATION. .NET Framework Overview. [S.l.], 2008a. Disponível em: <http://www.microsoft.com/net/Overview.aspx>. Acesso em: 06 jun. 2009.
______. Microsoft Expression Blend 2: Perguntas freqüentes. [S.l.], 2008b. Disponível em: <http://www.microsoft.com/brasil/msdn/expression/products/FAQ.aspx?key=blend>. Acesso em: 10 maio 2009.
______. Microsoft Expression. [S.l.], 2009a. Disponível em: <http://www.microsoft.com/Expression/>. Acesso em: 06 jun. 2009.
______. Microsoft Visual Studio. [S.l.], 2009b. Disponível em: <http://www.microsoft.com/visualstudio/en-us/default.mspx>. Acesso em: 06 jun. 2009.
78
MICROSOFT CORPORATION. Recursos do Microsoft Expression Blend 2. [S.l.], 2008c. Disponível em: <http://www.microsoft.com/brasil/msdn/expression/features/Default.aspx?key=blend>. Acesso em: 10 maio 2009.
______. The Microsoft Office Fluent user interface overview. [S.l.], 2009c. Disponível em: <http://office.microsoft.com/en-us/products/HA101679411033.aspx>. Acesso em: 06 jun. 2009.
MIRANDA, Elisangela Maschio de. Uma ferramenta de apoio ao processo de aprendizagem de algoritmos. 2004. 128 f. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Santa Catarina. Disponível em: <http://www.tede.ufsc.br/teses/PGCC0627.pdf>. Acesso em: 21 out. 2008.
MORANDI, Diana et al. Um processador básico para o ensino de conceitos de arquitetura e organização de computadores. Hífen, Uruguaiana, v. 30, p. 73-80, 2006.
MORANDI, Diana; RAABE, André Luis Alice; ZEFERINO, Cesar Albenes. Processadores para Ensino de Conceitos Básicos de Arquitetura de Computadores. In: WORKSHOP DE EDUCAÇÃO EM ARQUITETURA DE COMPUTADORES, 1., 2006, Ouro Preto. Proceedings of the 18th International Symposium on Computer Architecture and High Performance Computing - Workshops. Porto Alegre: SBC, 2006. p. 17-24.
MOREIRA, Ricardo Sá Fortes; HAJDU, Gustavo. Ambiente de Apoio ao Aprendizado de Arquitetura de Computadores. In: WORKCOMP SUL, 1., 2004, Florianópolis. Anais... [S.l.: s.n.], 2004. Disponível em: <http://inf.unisul.br/~ines/workcomp/cd/pdfs/2903.pdf>. Acesso em: 10 out 2008.
MYATT, Adam. Pro NetBeans IDE 5.5 Enterprise Edition. New York: Apress, 2007.
PARR, Terence. ANTLR v3 Documentation. 2007. Disponível em: <http://www.antlr.org/wiki/display/ANTLR3/ANTLR+v3+documentation>. Acesso em: 15 out 2007a.
______. ANTLRWorks: The ANTLR GUI Development Environment. Disponível em: <http://www.antlr.org/works/index.html>. Acesso em: 06 jun. 2009.
______. The Definitive ANTLR Reference: Building Domain-Specific Languages. Dallas: The Pragmatic Bookshelf, 2007b.
PATTERSON, David A; HENNESSY, John L. Organização e projeto de computadores: a interface hardware/software. 2. ed. Rio de Janeiro: LTC, 2000.
PEREIRA, Maicon Carlos. µBIP: Microcontrolador Básico para o Ensino de Sistemas Embarcados. 2008. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) - Universidade do Vale do Itajaí, Itajaí, 2008.
PIMENTEL, Edson Pinheiro et al. Avaliação contínua da aprendizagem, das competências e habilidades em programação de computadores. In: WORKSHOP DE INFORMÁTICA NA ESCOLA, Anais do XXIII Congresso da Sociedade Brasileira de Computação. Porto Alegre: SBC, 2003.
79
PREDKO, Michael. Handbook of microcontrollers. New York: McGraw-Hill, 1998.
RAABE, André Luís Alice; VALLE FILHO, Adhemar Maria; CANCIAN, Rafael. Luiz. Uma proposta de integração transdisciplinar mediada pelo uso de um software educacional no Curso de Ciência da Computação. In: III Congreso Chileno de Educación Superior, 2001. XXI International Conference of the Chilean Computer Science Society, 2001. v. 1. p. 151-162. Disponível em: <http://siaiacad05.univali.br/~araabe/artigos/artigo_chile_2001.pdf>. Acesso em: 10 set 2008.
RIBES, Marcos Lemke; ZEVE, Carlos Mário Dal’col. Um Estudo de Interfaces Amigáveis na Web Utilizando XML. Práxis: Revista de Divulgação Científica, Guaíba, v. 3, n. 2, jan. 2006. Disponível em: <http://guaiba.ulbra.tche.br/praxis/artigos_2006_2/sistemas.pdf>. Acesso em: 10 maio 2009.
SONNINO, Bruno; SONNINO, Roberto. Introdução ao WPF. Disponível em: <http://msdn.microsoft.com/pt-br/library/cc564903.aspx>. Acesso em: 02 maio 2009.
SOUZA, David José de. Desbravando o PIC: ampliado e atualizado para PIC16F628A. 6 ed. São Paulo: Érica, 2003.
STALLINGS, William. Arquitetura e organização de computadores: projeto para o desempenho. 5 ed. São Paulo: Prentice Hall, 2005.
TERRY, P. D. Compilers and compiler generators: an introduction with C++. 1996. Disponivel em: <http://www.scifac.ru.ac.za/compilers/> Acesso em: 20 set. 2008.
THE CODE PROJECT. Fireball.CodeEditor. Disponível em: <http://www.codeproject.com/KB/miscctrl/fireballcodeeditor.aspx>. Acesso em: 06 jun. 2009.
VAHID, Frank, GIVARGIS, Tony. Embedded system design: a unified hardware/software introduction. [S.l.]: John Wiley & Sons, Inc., 2002.
WEBER, Raul Fernando. Fundamentos de arquitetura de computadores. 3. ed. Porto Alegre: Sagra Luzzatto, 2004.
WILLIAMS, Brennon. Microsoft Expression Blend Unleashed. Indianapolis: Pearson Education, 2008.
ZEFERINO, Cesar A. Especificação da Arquitetura e da Organização do Processador BIP. Itajaí, 2007. (Relatório Técnico).
APÊNDICES
A. GRAMÁTICA PORTUGOL DEFINIDA NO ANTLR
grammar portugol; options { language= 'CSharp2'; backtrack = true; memoize=true; } @namespace {Bipide} @header { using Bipide;} @members{ int x; int nomevar; } @rulecatch { catch (RecognitionException e) { throw e; } } PROGRAMA : 'programa' | 'PROGRAMA'; DECLARACOES : 'declaracoes' | 'DECLARACOES'; DEFINA : 'defina' | 'DEFINA'; INICIO : 'inicio' | 'INICIO'; FIM : 'fim' | 'FIM'; INTEIRO : 'inteiro'| 'INTEIRO'; SE : 'se'| 'SE'; ENTAO : 'entao'| 'ENTAO'; SENAO : 'senao'| 'SENAO'; FIMSE : 'fimse'| 'FIMSE'; ENQUANTO : 'enquanto'| 'ENQUANTO'; FACA : 'faca'| 'FACA'; FIMENQUANTO : 'fimenquanto' | 'FIMENQUANTO'; REPITA : 'repita' | 'REPITA'; QUANDO : 'quando' |'QUANDO'; PARA : 'para' | 'PARA'; ATE : 'ate' | 'ATE'; PASSO : 'passo' | 'PASSO'; FIMPARA : 'fimpara' | 'FIMPARA'; ID : (('a'..'z' | 'A'..'Z')('a'..'z'|'A'..'Z'| '0 '..'9'|'_')* ); VINT : '0'..'9' + ; WS : (' ' |'\t' |'\n' |'\r' )+ {$channel=HIDDEN; } ; COMENTARIO : '/*' .* '*/' {$channel=HIDDEN;}; COMENTARIOLINHA : '//' ~('\n'|'\r')* '\r'? '\n' {$c hannel=HIDDEN;}; programa : PROGRAMA ID dec INICIO lista_cmdo FIM; dec : DECLARACOES lista_decl | /* vazio */ ;
82
lista_decl : decl+; decl : dec_const | dec_var; dec_const : DEFINA ID VINT; dec_var : INTEIRO lista_var; lista_dec_var : dec_var+; lista_var : ID (',' ID )* ; lista_cmdo : cmdo+; cmdo : cmd_se | cmd_se_senao | cmd_enq_faca | cmd_faca | cmd_para | atribuicao; expRelacional : '(' exp ')'; cmd_se : SE expRelacional ENTAO lista_cmdo FIMSE; cmd_se_senao : SE expRelacional ENTAO lista_cmdo S ENAO lista_cmdo FIMSE ; cmd_faca : REPITA cmdo+ QUANDO expRelacional ; cmd_enq_faca : ENQUANTO expRelacional FACA lista_c mdo FIMENQUANTO; cmd_para : PARA id '<-' exp ATE exp PASSO valneg lista_cmdo FIMPARA; valneg : '-'? VINT; atribuicao : id '<-' exp; lista_id : id (',' id)+; lista_saida : (id|VINT) (',' (id|VINT))*; exp : expsoma (('>' | '<' | '>=' | '<=' | '=' | '!=') expsoma )* ; expsoma : expmul (('+' |'-') expmul)*; expmul : expmin (('*' | '/') expmin)*; expmin : ('-')? atom ; atom : VINT | id | '(' exp ')'; id : ID;
B. CONJUNTO DE INSTRUÇÕES UTILIZADAS PARA VALIDAÇÃO DO SIMULADOR
Neste apêndice são apresentados os programas utilizados para a realização de testes e
validação da simulação das instruções dos processadores BIP. A Tabela 12 apresenta estes
programas e os resultados apresentados pelos registradores especiais do processador após a
simulação de cada conjunto de instruções.
Tabela 12. Conjunto de programas utilizados para validação do simulador
Arquivo Instrução Sequência de instruções para o teste
Resultado obtido após a simulação das instruções
PC ACC Z N Memória add_1.s ADD ldi 1
sto 14 ldi 3 add 14
4 4 0 0 M[14]=1
addi_1.s ADDI ldi 3 addi 4
2 7 0 0
beq_1.s BEQ ldi 4 subi 4 beq __end ldi 85 __end:
4 0 1 0
beq_2.s BEQ ldi 5 subi 4 beq __end ldi 85 __end:
4 85 0 0
bge_1.s BGE ldi 4 subi 4 bge __end ldi 85 __end:
4 0 1 0
bge_2.s BGE ldi 5 subi 4 bge __end ldi 85 __end:
4 1 0 0
bge_3.s BGE ldi 4 subi 5 bge __end ldi 85 __end:
4 85 0 1
bgt_1.s BGT ldi 4 subi 3 bgt __end ldi 85 __end:
4 1 0 0
84
bgt_2.s BGT ldi 3 subi 3 bgt __end ldi 85 __end:
4 85 1 0
bgt_3.s BGT ldi 4 subi 5 bgt __end ldi 85 __end:
4 85 0 1
ble_1.s BLE ldi 4 subi 4 ble __end ldi 85 __end:
4 0 1 0
ble_2.s BLE ldi 3 subi 4 ble __end ldi 85 __end:
4 -1 0 1
ble_3.s BLE ldi 5 subi 4 ble _end ldi 85 __end:
4 85 0 0
btl_1.s BLT ldi 3 subi 4 blt __end ldi 85 __end:
4 -1 0 1
btl_2.s BLT ldi 3 subi 3 blt __end ldi 85 __end:
4 85 1 0
btl_3.s BLT ldi 5 subi 4 blt __end ldi 85 __end:
4 85 0 0
bne_1.s BNE ldi 4 subi 3 bne __end ldi 85 __end:
4 1 0 0
bne_2 .s BNE ldi 3 subi 3 bne _end ldi 85 __end:
4 85 1 0
ldi_1.s LDI ldi 85 1 85 0 0
85
jmp_ 1.s JMP ldi 4 jmp __end ldi 85 __end:
3 4 0 0
ld_1.s LD ldi 44 sto 15 ldi 85 sto 16 ld 15
5 44 0 0 M[15]=44 M[16]=85
C. PROGRAMAS PORTUGOL UTILIZADOS PARA VALIDAÇÃO DO COMPILADOR
Para validação do compilador, foi utilizado um conjunto de programas Portugol que foram
compilados e tiveram o código assembly gerado analisados. Estes programas são apresentados na
Tabela 13. Também são exibidos os valore resultantes após a simulação dos programas assembly
gerados.
Tabela 13. Conjunto de programas utilizados para validação do compilador
Portugol Código resultante da Compilação
Resultado obtido após a simulação das instruções Variáveis/Memória PC ACC Z N
programa prog declaracoes inteiro x inicio x <- 2 fim
.data x : 0 .text LDI 2 STO x HLT 0
X -> Mem[0] = 2 2 2
0 0
programa prog declaracoes inteiro x inicio x <- 2 + 2 fim
.data x : 0 .text LDI 2 ADDI 2 STO x HLT 0
X -> Mem[0] = 4 3
4 0 0
programa prog declaracoes defina x 1 inicio x <- x + 2 - (3 + 3) fim
.data x : 1 .text LD x ADDI 2 STO 100 LDI 3 ADDI 3 STO 101 LD 100 SUB 101 STO x HLT 0
X -> Mem[0] = -3 9
-3 0 1
programa prog declaracoes inteiro x inicio x<-1 se (2 = 2) entao x <- 30 fimse fim
.data x : 0 .text LDI 1 STO x LDI 2 STO 100 LDI 2 STO 101 LD 100 SUB 101 BNE FIMSE1 LDI 30 STO x FIMSE1: HLT 0
X -> Mem[0] = 30 11
30 1 0
87
programa prog declaracoes inteiro x inicio x<-1 se (2 != 2) entao x <- 30 fimse fim
.data x : 0 .text LDI 1 STO x LDI 2 STO 100 LDI 2 STO 101 LD 100 SUB 101 BEQ FIMSE1 LDI 30 STO x FIMSE1: HLT 0
X -> Mem[0] = 1 11
0 1 0
programa prog declaracoes inteiro x inicio x <- 1 se (2 < 4) entao x<-30 se ( 2 > 0) entao x <- 60 fimse fimse fim
.data x : 0 .text LDI 1 STO x LDI 2 STO 100 LDI 4 STO 101 LD 100 SUB 101 BGE FIMSE1 LDI 30 STO x LDI 2 STO 100 LDI 0 STO 101 LD 100 SUB 101 BLE FIMSE2 LDI 60 STO x FIMSE2: FIMSE1: HLT 0
X -> Mem[0] = 60 20
60 0 0
programa prog declaracoes inteiro x inicio x<-1 se (2 = 2) entao x<-30 senao x<-60 fimse fim
.data x : 0 .text LDI 1 STO x LDI 2 STO 100 LDI 2 STO 101 LD 100 SUB 101 BNE ELSE1 LDI 30 STO x JMP FIMSE1 ELSE1: LDI 60 STO x FIMSE1: HLT 0
X -> Mem[0] = 30 14 30 1 0
programa prog declaracoes inteiro x inicio x<-1
.data x : 0 .text LDI 1 STO x
X -> Mem[0] = 60 14
60 1 0
88
se (2 != 2) entao x<-30 senao x<-60 fimse fim
LDI 2 STO 100 LDI 2 STO 101 LD 100 SUB 101 BEQ ELSE1 LDI 30 STO x JMP FIMSE1 ELSE1: LDI 60 STO x FIMSE1: HLT 0
programa prog declaracoes inteiro x inicio x<-1 enquanto ( x < 5 ) faca x <- x + 1 fimenquanto fim
.data x : 0 .text LDI 1 STO x INI_ENQ1: LD x STO 100 LDI 5 STO 101 LD 100 SUB 101 BGE FIMFAÇA1 LD x ADDI 1 STO x JMP INI_ENQ1 FIMFAÇA1: HLT 0
X -> Mem[0] = 5 13 0 1 0
programa prog declaracoes inteiro x inicio x<- 1 repita x <- x + 1 quando (x <5) fim
.data x : 0 .text LDI 1 STO x FACA1: LD x ADDI 1 STO x LD x STO 100 LDI 5 STO 101 LD 100 SUB 101 BLT FACA1 HLT 0
X -> Mem[0] = 5 12
0 1 0
programa prog declaracoes inteiro x inteiro y inicio y<-0 para x <- 1ate 5 passo 1 y<- 1 + x fimpara fim
.data x : 0 y : 0 .text LDI 0 STO y LDI 1 STO x LDI 5 STO 100 LDI 1 STO 101 LD x PARA1: SUB 100 BGT FIMPARA1
X -> Mem[0] = 6 Y -> Mem[1] = 6
18 1 0 0
89
LDI 1 ADD x STO y LD x ADD 101 STO x JMP PARA1 FIMPARA1: HLT 0
programa fatorial declaracoes inteiro fat, temp, i, j, num inicio num <- 5 fat <- 1 temp<- 0 i <- 0 j <- 0 para i <- 2 ate num passo 1 temp <- fat para j <- 1 ate i-1 passo 1 fat <- fat + temp fimpara fimpara fim
.data fat : 0 temp : 0 i : 0 j : 0 num : 0 .text LDI 5 STO num LDI 1 STO fat LDI 0 STO temp LDI 0 STO i LDI 0 STO j LDI 2 STO i LD num STO 100 LDI 1 STO 101 LD i PARA1: SUB 100 BGT FIMPARA1 LD fat STO temp LDI 1 STO j LD i SUBI 1 STO 102 LDI 1 STO 103 LD j PARA2: SUB 102 BGT FIMPARA2 LD fat ADD temp STO fat LD j ADD 103 STO j JMP PARA2 FIMPARA2: LD i ADD 101 STO i JMP PARA1 FIMPARA1: HLT 0
fat -> Mem[0] = 120 temp -> Mem[1] = 24 i -> Mem[2] = 6 j -> Mem[3] = 5 num -> Mem[4] = 25
42 1 0 0
programa gcd declaracoes inteiro x inteiro y
.data x : 0 y : 0 a : 0
x -> Mem[0] = 2 y -> Mem[1] = 2 a -> Men[2] = 2 b -> Men[3] = 2
32 2 1 0
90
inteiro a inteiro b inteiro c inicio x <- 10 y <- 4 enquanto (x != y) faca se(x > y) entao x <- x-y; a <- x; senao y <- y-x; b <- y; fimse fimenquanto c <- x; fim
b : 0 c : 0 .text LDI 10 STO x LDI 4 STO y INI_ENQ1: LD x STO 100 LD y STO 101 LD 100 SUB 101 BEQ FIMFAÇA1 LD x STO 100 LD y STO 101 LD 100 SUB 101 BLE ELSE1 LD x SUB y STO x LD x STO a JMP FIMSE1 ELSE1: LD y SUB x STO y LD y STO b FIMSE1: JMP INI_ENQ1 FIMFAÇA1: LD x STO c HLT 0
c -> Men[4] = 2
D. QUESTIONÁRIO PARA AVALIAÇÃO DO AMBIENTE BIPIDE PELOS USUÁRIOS
Assinale zero no caso de respostas negativas, e de 1 a 10 de acordo com a sua opinião, sendo 10 o grau mais elevado:
1) Você acha que o seu nível de conhecimento foi compatível com as telas e vocabulário empregado no
sistema?
0 1 2 3 4 5 6 7 8 9 10
2) As mensagens de erro lhe auxiliaram de forma adequada?
0 1 2 3 4 5 6 7 8 9 10
3) O sistema lhe proporcionou feedback, ou seja, você conseguiu visualizar todas suas ações?
0 1 2 3 4 5 6 7 8 9 10
4) A estrutura dos painéis do menu lhe parece disposta de forma lógica por agrupamento de tipos de
opções?
0 1 2 3 4 5 6 7 8 9 10
5) Qual é o grau de satisfação que você atribui à utilização do sistema?
0 1 2 3 4 5 6 7 8 9 10
6) Aponte sugestões e críticas gerais para a melhoria do ambiente:
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
E. RESULTADOS DA AVALIAÇÃO
Quantidade de alunos que responderam o questionário: 21
1) Você acha que o seu nível de conhecimento foi compatível com as telas e vocabulário
empregado no sistema?
• 66,67% atribuíram notas entre 8 e 10.
2) As mensagens de erro lhe auxiliaram de forma adequada?
• 71,43% atribuíram notas entre 8 e 10.
93
3) O sistema lhe proporcionou feedback, ou seja, você conseguiu visualizar todas suas
ações?
• 80,95% atribuíram notas entre 8 e 10.
4) A estrutura dos painéis do menu lhe parece disposta de forma lógica por agrupamento de tipos
de opções?
• 90,48% atribuíram notas entre 8 e 10.
94
5) Qual é o grau de satisfação que você atribui à utilização do sistema?
• 80,95% atribuíram notas entre 8 e 10.
ANEXOS
I. CONJUNTO DE INSTRUÇÕES DO BIP I E BIP II
Este anexo apresenta uma descrição mais detalhada do conjunto de instrução dos
processadores BIP I e BIP II. As subseções a seguir apresentam o conjunto de instruções de cada
classe de instrução.
CLASSE: CONTROLE
HLT Halts
Sintaxe: HLT
Descrição: Desabilita a atualização do PC
Opcode: 00000
Status: Nenhum bit afetado
PC: Não é atualizado
Operação: Nenhuma operação é realizada
Exemplo: HLT
Antes da instrução: PC = 0x0100
Após a instrução: PC = 0x0100
CLASSE: ARMAZENAMENTO
STO Store
Sintaxe: STO operand
Descrição: Armazena o conteúdo do ACC em uma posição da memória indicada
pelo operand .
Opcode: 00001
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: Memory[operand] ← ACC
Exemplo: STO 0x0 002
Antes da instrução: ACC = 0x0005
MEM[2] = 0x0000
Após a instrução: ACC = 0x0005
MEM[2] = 0x0005
CLASSE: CARGA
LD Load
Sintaxe: LD operand
Descrição: Carrega um valor armazenado em uma posição de memória indicado
pelo operand para o registrador ACC .
Opcode: 00010
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: ACC ← Memory[operand]
Exemplo: LD 0x0002
Antes da instrução: ACC = 0x0000
MEM[2] = 0x0005
Após a instrução: ACC = 0x0005
MEM[2] = 0x0005
LDI Load Immediate
Sintaxe: LDI operand
Descrição: Carrega o valor de um operando imediato para o registrador ACC
Opcode: 00011
Status: Nenhum bit afetado
PC: PC ← PC + 1
Operação: ACC ← operand
Exemplo: LDI 0x0005
Antes da instrução: ACC = 0x0000
Após a instrução: ACC = 0x0005
CLASSE: ARITMÉTICA
ADD
Sintaxe: ADD operand
Descrição: O valor do registrador ACC é somado com o valor armazenado na
posição de memória indicado pelo campo operand e o resultado
armazenado no ACC .
Opcode: 00100
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC + Memory[operand]
Exemplo: ADD 0x0002
Antes da instrução: ACC = 0x0004
MEM[2] = 0x0003
Após a instrução: ACC = 0x0007
MEM[2] = 0x0003
ADDI Add Immediate
Sintaxe: ADDI operand
Descrição: O valor do registrador ACC é somado com o valor operando imediato
e o resultado armazenado no ACC .
Opcode: 00101
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC + operand
Exemplo: ADDI 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0006
SUB Subtract
Sintaxe: SUB operand
Descrição: O valor do registrador ACC é subtraído pelo valor armazenado na
posição de memória indicado pelo campo operand e o resultado
armazenado no ACC .
Opcode: 00110
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC - Memory[operand]
Exemplo: SUB 0x0002
Antes da instrução: ACC = 0x0004
MEM[2] = 0x0003
Após a instrução: ACC = 0x0001
MEM[2] = 0x0003
SUBI Subtract Immediate
Sintaxe: SUBI operand
Descrição: O valor do registrador ACC é subtraído pelo valor do operando
imediato e o resultado armazenado no ACC .
Opcode: 00111
Status: Z e N são afetados por esta operação
PC: PC ← PC + 1
Operação: ACC ← ACC - operand
Exemplo: SUBI 0x0002
Antes da instrução: ACC = 0x0004
Após a instrução: ACC = 0x0002
CLASSE: DESVIO
BEQ Branch Equal
Sintaxe: BEQ operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA foi zero.
Opcode: 01000
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BEQ 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0005
STATUS.Z = 1 STATUS.N = 0
Após a instrução: PC = 0x0002
BNE Branch Non-Equal
Sintaxe: BNE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido diferente de zero.
Opcode: 01001
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BNE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
BGT Branch Greater Than
Sintaxe: BGT operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido maior que zero.
Opcode: 01010
Status: Nenhum bit é afetado
PC: Se (STATUS.Z=0) e (STATUS.N=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BGT 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0004
STATUS.Z = 0 STATUS.N = 0
Após a instrução: PC = 0x0002
BGE Branch Greater Equal
Sintaxe: BGE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido maior ou igual zero.
Opcode: 01011
Status: Nenhum bit é afetado
PC: Se (STATUS.N=0) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BGE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0005
STATUS.Z = 1 STATUS.N = 0
Após a instrução: PC = 0x0002
BLT Branch Less Than
Sintaxe: BLT operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido menor que zero.
Opcode: 01100
Status: Nenhum bit é afetado
PC: Se (STATUS.N=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BLT 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
BLE Branch Greater Equal
Sintaxe: BLE operand
Descrição: Atualiza o valor do PC com o valor do campo operand caso o
resultado da operação anterior na ULA tenha sido menor ou igual a
zero.
Opcode: 01101
Status: Nenhum bit é afetado
PC: Se (STATUS.N=1) ou (STATUS.Z=1) então
PC ← endereço
Se não
PC ← PC + 1
Operação: Nenhuma Operação Realizada
Exemplo: LDI 0x0005
SUB 0x0008
BLE 0x0002
Antes da instrução: PC = 0x000A MEM[8] = 0x0006
STATUS.Z = 0 STATUS.N = 1
Após a instrução: PC = 0x0002
JMP Jump
Sintaxe: JMP operand
Descrição: Atualiza o valor do PC com o valor do campo operand, ou seja,
realiza um desvio incondicional.
Opcode: 01110
Status: Nenhum bit é afetado
PC: PC ← endereço
Operação: Nenhuma Operação Realizada
Exemplo: JMP 0x0002
Antes da instrução: PC = 0x000A
Após a instrução: PC = 0x0002
II. SINTAXE DO PORTUGUÊS ESTRUTURADO
1. Estrutura Geral de um Programa
Sintaxe:
programa <nome_do_programa>
declarações
<definição_de_constantes>
<declaração_de_variáveis>
inicio
<instruções_do_programa>
fim
2. Definição de Constantes
Sintaxe:
defina <nome_da_constante> <valor>
Exemplo:
defina N 5
defina X 3
3. Declaração de Variáveis
Sintaxe:
<tipo> <nome_ou_lista_de_nomes>
Exemplo:
inteiro valor
inteiro valor, total
4. Operadores
Símbolos:
Relacionais: >, <, >=, <=, =, !=
Aritméticos: +, -
Exemplo:
(2 + 5) > (3 + 1)
8 = (2 + 2 + 2)
5. Instruções do Programa
5.1 Atribuição
Sintaxe:
<nome_da_variável> <- <valor ou variável ou expres são>
Exemplo:
a <- 2
b <- x
c <- 2 + x
5.2 Desvio Condicional Simples
Sintaxe:
se (<condição>) então
<instruções>
fimse
Exemplo:
se (x > 2) então
X <- 1
fimse
5.3 Desvio Condicional Composto
Sintaxe:
se (<condição>) então
<instruções>
senao
<instruções>
fimse
Exemplo:
se (x > 2) então
X <- 1
senao
X <- 3
fimse
5.4 Laço de Repetição com Teste Lógico no Início
Sintaxe:
enquanto (<condição>) faca
<instruções>
fimenquanto
Exemplo:
enquanto (x < 5) faca
X <- x + 1
fimenquanto
5.5 Laço de Repetição com Teste Lógico no Final
Sintaxe:
repita
<instruções>
quando (<condição>)
Exemplo:
repita
X < x + 1
quando (x < 5)
5.6 Laço de Repetição com Variável de Controle
Sintaxe:
para <variável> <- <valor_inical> ate <valor_final> passo <valor>
<instruções>
fimpara
Exemplo:
para i <- 1 ate 50 passo 1
X <- i
fimpara