UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BIP IV: ESPECIFICAÇÃO E SUPORTE NA IDE BIPIDE Área de Compiladores por Paulo Roberto Machado Rech André Luis Alice Raabe, Dr. Orientador Cesar Albenes Zeferino, Dr. Co-orientador Itajaí (SC), junho de 2011

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BIP IV: ESPECIFICAÇÃO E SUPORTE NA IDE BIPIDE Área de Compiladores por Paulo Roberto Machado Rech 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é Luís Alice Raabe, Dr. Itajaí (SC), junho de 2011

3 SUMÁRIO LISTA DE ABREVIATURAS... iv LISTA DE FIGURAS... v LISTA DE TABELAS... vi RESUMO... vii ABSTRACT... viii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA PROCESSADORES BIP BIP I BIP II BIP III µbip SIMULADORES DE ARQUITETURA NeanderWin MipsIt ABACUS WinMIPS GNUSim Comparação entre Simuladores Analisados BIPIDE Compilador Simulador DESENVOLVIMENTO ESPECIFICAÇÃO DO BIP IV Arquitetura Organização ALTERAÇÕES NA IDE BIPIDE Operações de E/S Utilização de Vetores ii

4 3.2.3 Chamada de sub-rotinas Operações de Lógica Componentes da Organização dos Processadores na Simulação Módulo de Ajuda Testes CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS A GRAMÀTICA PORTUGOL B CONJUNTO DE INSTRUÇÕES do BIP IV B.1 CLASSE: CONTROLE B.2 CLASSE: ARMAZENAMENTO B.3 CLASSE: CARGA B.4 CLASSE: ARITMÉTICA B.5 CLASSE: LÓGICA BOOLEANA B.6 CLASSE: DESVIO B.7 CLASSE: DESLOCAMENTO LÓGICO B.8 CLASSE: MANIPULAÇÃO DE VETOR B.9 CLASSE: SUPORTE A PROCEDIMENTOS C CONJUNTO DE INSTRUÇÕES PARA TESTE UNITÁRIO D PROGRAMAS PORTUGOL UTILIZADOS PARA VALIDAÇÃO DO COMPILADOR E SINTAXE DA LINGUAGEM PORTUGOL iii

5 LISTA DE ABREVIATURAS ACC ANTLR AST BIP CPU E/S IDE INDR IR LIFO PIC PC SFR SP TCC TOS UF UFSC ULA UNIVALI WPF XAML XML µbip Accumulator ANother Tool for Language Recognition Abstract Syntax Tree Basic Instruction-set Processor Central Processing Unit Entrada/Saída Integrated Development Environment Index Register Instruction Register Last In First Out Programmable Intelligent Computer Program Counter Special Function Register Stack Pointer Trabalho de Conclusão de Curso Top of Stack Unidade Funcional Universidade Federal de Santa Catarina Unidade Lógica Aritmética Universidade do Vale do Itajaí Windows Presentation Foundation extensible Application Markup Language extensible Markup Language microbip iv

6 LISTA DE FIGURAS Figura 1. Organização do BIP I... 8 Figura 2. Organização do BIP II Figura 3. Organização da Unidade Funcional Figura 4. Organização do µbip Figura 5. Tela principal do sistema NeanderWin Figura 6. Janelas do MipsIt Figura 7. Tela principal do ABACUS Figura 8. Tela principal do WinMIPS Figura 9. Tela Principal do GNUSim Figura 10. Exemplo da gramática do Portugol no ANTLR Figura 11. Exemplos de ações semânticas do Bipide Figura 12. Simulador do Bipide Figura 13. Exemplo de código fonte da linguagem XAML Figura 14. Visão geral da ferramenta Expression Blend Figura 15. Organização da Memória de E/S Figura 16. Formato de Instruções do BIP IV Figura 17. Classes de Instruções dos processadores BIP Figura 18. Organização do módulo de manipulação de vetores Figura 19. Organização do BIP IV Figura 20. Fluxo de Implementação do Bipide Figura 21. Alterações na gramática de E/S Figura 22. Geração de código para E/S Figura 23. Interface de E/S Figura 24. Alterações na gramática para suporte a vetores Figura 25. Geração de Código para suporte a vetores Figura 26. Ações semânticas para geração de código para atribuições Figura 27. Alterações na Gramática para suporte a sub-rotinas Figura 28. Geração de código para sub-rotinas Figura 29. Alterações na gramática para suporte a operações lógicas Figura 30. Geração de código para operações de lógica Figura 31. Tratamento de precedência de operadores Figura 32. Componentes da Organização do processador no Simulador Figura 33. Programa utilizado para validar uma instrução de chamada de sub-rotina v

7 LISTA DE TABELAS Tabela 1. Arquitetura do BIP I... 6 Tabela 2. Conjunto de Instruções do BIP I... 7 Tabela 3. Arquitetura do BIP II... 9 Tabela 4. Instruções de desvio do BIP II... 9 Tabela 5. Instruções de Lógica do BIP III Tabela 6. Instruções agregadas ao µbip Tabela 7. Características dos sistemas analisados Tabela 8. Lista de Símbolos da Gramática Portugol Tabela 9. Conjunto de Instruções do BIP IV Tabela 10. Resumo da arquitetura do BIP IV Tabela 11. Instruções utilizadas nos testes em portugol Tabela 12. Conjunto de Instruções para teste Unitário vi

8 RESUMO RECH, Paulo R. M. BIP IV: Especificação e Suporte na IDE Bipide. Itajaí, f. 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í, Para permitir a redução da abstração de conceitos de lógica de programação nos primeiros semestres de cursos da área de computação, uma família de processadores denominada BIP - Basic Instruction-set Processor, e um ambiente de desenvolvimento integrado chamado Bipide foram desenvolvidos. Os processadores da família BIP, suportados pela ferramenta Bipide, têm algumas limitações não suportando interações, como entrada e saída ou subrotinas não permitindo a sua utilização em problemas mais complexos ou que necessitem de alguma interação. Neste contexto, este trabalho apresenta o desenvolvimento de um novo processador, integrante da família BIP, denominado BIP IV, que estende as características dos processadores BIP, agregando novas funcionalidades, aumentando a abrangência de sua utilização. Também foram implementadas modificações na IDE Bipide a fim de suportar o uso do processador BIP IV. O resultado alcançado permite maior interação ao aluno com a ferramenta, além do aprendizado de novas funcionalidades e seu uso na resolução de problemas mais complexos. A ferramenta ainda permite ao aluno compreender a representação das novas funcionalidades em linguagem de baixo nível e sua representação no hardware, através do simulador presente na IDE. Este trabalho apresenta uma revisão de conceitos associados à Arquitetura e Organização dos processadores BIP e conceitos aplicados no desenvolvimento da IDE Bipide, assim como descreve o projeto do processador BIP IV e seu suporte na ferramenta Bipide. Palavras-chave: Simuladores de Arquitetura de Computadores. Compiladores. Arquitetura e Organização de Computadores. vii

9 ABSTRACT To allow a reduction in the abstraction of concepts of programming logic in the first semester of courses in computing, a family of processors, called BIP - Basic Instruction-set Processor, and an integrated development environment, called Bipide were developed. The BIP processor family, supported by the tool Bipide, has some limitations, not supporting interactions, such as input and output, or subroutines, not allowing their use in complex problems or those with user interaction. In this context, this research presents the development of a new BIP processor family member called BIP IV, which extends its features increasing the scope of use. Modifications were also implemented in the IDE Bipide to support use of BIP IV processor. The result obtained allows the students more interaction with the tool, as well as new features learning and its use in solving complex problems. The tool also allows the student to understand the representation of the new features in low-level assembly language and its representation in the hardware through Bipide architecture simulator. This research also presents a review of concepts related to Architecture and Organization of processors BIP and concepts applied in the development of Bipide IDE, and describes the design of the processor BIP IV, his support in Bipide tool. Keywords: Simulation of Computer Architecture. Compilers. Computer Organization and Architecture. viii

10 1 INTRODUÇÃO Com o objetivo de auxiliar o aprendizado do aluno nos semestres iniciais dos cursos de Ciência da Computação, em Zeferino et al (2010) foi proposta uma abordagem interdisciplinar envolvendo conceitos de arquitetura de computadores e de seus desdobramentos nas disciplinas ligadas a aprendizagem de programação. Este enfoque parte do pressuposto que, ao reduzir a abstração envolvida na aprendizagem dos conceitos iniciais, auxilia a reduzir os problemas de aprendizagem, que segundo diversos autores como McCracken et al (2001) e Lister et al (2004), são freqüentes nos semestres iniciais. Para isso foi proposta uma família de processadores denominada BIP (Basic Instruction-set Processor), e em conjunto com ela uma ferramenta chamada Bipide (VIEIRA, 2009). A Família BIP foi concebida em níveis de complexidade de arquitetura e organização crescentes, sendo que o processador BIP I (MORANDI et al., 2006) possui oito instruções que possibilitam o controle, armazenamento em memória, carga no acumulador e instruções aritméticas. No BIP II (MORANDI; RAABE; ZEFERINO, 2006), foram acrescidas instruções para suporte a laços de repetição e desvios. No BIP III foi acrescido suporte para instruções de lógica e de operação binária. Já o µbip (PEREIRA; ZEFERINO, 2008) foi desenvolvido com o intuito de ensino de Sistemas Embarcados agregando periféricos e funcionalidades típicas de microcontroladores. A ferramenta Bipide, por sua vez, consiste em um ambiente de desenvolvimento integrado (IDE - Integrated Development Environment) que implementa instruções dos processadores BIP I e BIP II. Nela é possível a criação de pequenos algoritmos em portugol (pseudolinguagem utilizada para facilitar o ensino de algoritmos) e sua execução passo a passo. Também é ilustrado o código correspondente em linguagem assembly e o estado dos componentes da organização do processador. A interface do Bipide ainda contempla animações que ilustram o funcionamento dos componentes da organização do processador destacando o código em portugol sendo executado e também o código assembly correspondente (VIEIRA; RAABE; ZEFERINO, 2010). Esta abordagem didática tem sido utilizada ao longo de três semestres letivos e tem trazido resultados positivos conforme mencionado em Vieira, Raabe e Zeferino (2010).

11 1.1 PROBLEMATIZAÇÃO Formulação do Problema Tanto no BIP I quanto no BIP II e III não são possíveis interações como entrada e saída e chamadas de procedimentos, permitindo somente algoritmos mais simples. Este aspecto tem gerado limitações quanto ao uso da abordagem para o ensino de conceitos mais abrangentes da aprendizagem de programação, e em especial, desfavorecem a criação de programas em que o aluno pode interagir com seu algoritmo. Analisando a bibliografia de apoio a disciplina de algoritmos, percebe-se que bons livros (MANZANO; OLIVEIRA, 2005 e ZIVIANI, 2007) adotam problemas que necessitam interações como entrada e saída de dados. Baseado nisso, conclui-se que a interação, via entrada e saída de dados, é um componente importante para auxiliar a despertar mais interesse por parte do aluno. Além disso, a implementação de entrada e saída, chamadas de procedimentos permitem que sejam trabalhados problemas que demandem soluções com algoritmos mais complexos e modulares Solução Proposta Neste contexto, a solução proposta neste trabalho consiste na criação de um novo integrante da família BIP, o BIP IV, que incorpora instruções de entrada e saída e chamadas de procedimentos. Por fim, o projeto e desenvolvimento do suporte deste novo processador na ferramenta Bipide. Para atender as novas funcionalidades do BIP IV, várias alterações no ambiente Bipide foram necessárias, inclusive na estrutura da pseudolinguagem portugol. Entre os benefícios da implementação em questão estão: (i) maior interação do aluno com a ferramenta; (ii) aprendizagem de novas funcionalidades e seu funcionamento no processador; (iii) extensão do uso da ferramenta para disciplinas de semestres posteriores aos já aplicados, uma vez que permitirá algoritmos mais complexos; (iv) continuidade da pesquisa relacionada à abordagem didática interdisciplinar. 2

12 1.2 OBJETIVOS Objetivo Geral Conceber e especificar a arquitetura e organização do processador BIP IV, visando dar suporte a instruções de entrada e saída e chamadas de sub-rotinas Objetivos Específicos Caracterizar a arquitetura e o conjunto de instruções dos processadores da família BIP; Analisar simuladores de outros processadores com enfoque na interface de entrada e saída; Implementar as alterações necessárias na ferramenta Bipide para permitir suporte ao Bip III e BIP IV; e Avaliar as alterações realizadas na ferramenta Bipide. 1.3 Metodologia A metodologia adotada no desenvolvimento deste trabalho foi dividida em seis partes: Estudo: Nesta etapa foram realizados estudos a fim de adquirir conhecimento sobre os processadores BIP, simuladores de arquiteturas que permitam entrada e saída e dados sobre a implementação da ferramenta Bipide. Os recursos utilizados nesta etapa foram livros, artigos e documentações; Projeto: Nesta etapa foi realizada a especificação e o projeto da arquitetura e organização do processador BIP IV bem como a análise e projeto das alterações necessárias na ferramenta Bipide; 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: Nesta etapa foram implementadas as alterações na IDE Bipide baseada no projeto realizado; Avaliação: Nestas etapas foram realizados testes a fim de validar a ferramenta; e 3

13 Documentação: Consiste na redação deste trabalho e de um artigo científico. 1.4 Estrutura do trabalho Este documento está dividido em quatro capítulos. O Capítulo 1, Introdução, apresentou uma visão geral sobre o tema abordado no trabalho e seus objetivos. O Capítulo 2, Fundamentação Teórica, apresenta a revisão bibliográfica dos temas envolvidos no trabalho. O Capítulo 3, Desenvolvimento, apresenta o projeto e a implementação em questão. O último Capítulo apresenta as conclusões sobre o Trabalho. O documento também apresenta quatro apêndices que contemplam o conteúdo deste trabalho. 4

14 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 um levantamento das características dos processadores BIP. A seção 2.2 apresenta uma breve descrição sobre os simuladores de arquitetura estudados. Na seção 2.3 são apresentadas as características atuais do compilador e do simulador da ferramenta Bipide. 2.1 Processadores BIP Os processadores BIP foram desenvolvidos por pesquisadores do Laboratório de Sistemas Embarcados e Distribuídos da UNIVALI Universidade do Vale do Itajaí com o intuito de estabelecer uma relação entre a programação de alto nível e sua representação em hardware bem como auxiliar o aprendizado de Arquitetura e Organização de Computadores nas fases iniciais dos cursos de Graduação em Computação (VIEIRA; RAABE; ZEFERINO, 2010) BIP I O BIP I tem como foco dar suporte ao entendimento a conceitos básicos de programação, níveis de linguagem em representação de dados e instruções em linguagem de máquina (MORANDI; RAABE; ZEFERINO, 2006; PEREIRA, 2008) Arquitetura A arquitetura do processador BIP I é baseada na arquitetura do processador PIC (Programmable Intelligent Computer). Este processador é orientado a acumulador e não possui banco de registradores. Conforme a Tabela 1, o formato de instruções do processador BIP I é composto por dois campos: 5 bits para o código de operação; e 11 bits para o operando. (MORANDI, RAABE, ZEFERINO, 2006).

15 Tabela 1. Arquitetura do BIP I Tamanho da palavra de 16 bits dados Tipo de dados Inteiro de 16 bits com sinal: a Tamanho da palavra de 16 bits instruções Formato de instrução Registradores Classes de instrução Fonte: Adaptado de Morandi et al. (2006). ACC: acumulador IR: registrador de Instrução PC: contador de programa Transferência (acesso a memória): STO, LD e LDI Aritmética: ADD, ADDI, SUB e SUBI Controle HLT. A arquitetura do BIP I possui três registradores: PC (Program counter Contador de Programa), IR (Instruction Register Registrador de Instrução), e ACC (Accumulator - Acumulador). O registrador PC aponta para o endereço da próxima instrução. O registrador IR aponta para o endereço da instrução em execução. O registrador ACC é utilizado para armazenamento de dados durante uma operação (MORANDI; RAABE; ZEFERINO, 2006). O conjunto de instruções do BIP I, apresentado na Tabela 2, é composto por uma instrução de controle, três instruções de transferência e quatro instruções de aritmética. Exceto na instrução halt (HLT), o PC é incrementado em uma unidade no final do ciclo de execução da instrução. Abaixo uma breve descrição de cada uma das instruções: HLT: Desabilita a atualização do PC. Nenhum registrador é afetado e nenhuma operação é realizada. STO: Armazena o conteúdo do registrador ACC na posição de memória indicada por operand. LD: Carrega para o registrador ACC o conteúdo da posição de memória indicada por operand. LDI: Carrega uma constante indicada por operand para o registrador ACC. 6

16 ADD: Soma o conteúdo do registrador ACC com o conteúdo da posição de memória indicado por operand. O resultado da adição é armazenado no registrador ACC. ADDI: Soma o conteúdo do registrador ACC a uma constante indicada por operand e o armazena no ACC. SUB: Subtrai o conteúdo do registrador ACC pelo conteúdo da posição de memória indicado por operand. O resultado da subtração é armazenado no registrador ACC. SUBI: Subtrai o conteúdo do registrador ACC pela constante indicada por operand. O resultado é armazenado no ACC. Tabela 2. Conjunto de Instruções do BIP I Código da Instrução Operação Classe Operação HLT Paralisa a execução Controle STO operand Memory[operand] ACC Transferência LD operand ACC Memory[operand] Transferência LDI operand ACC operand Transferência ADD operand ACC ACC+Memory[operand] Aritmética ADDI operand ACC ACC+operand Aritmética SUB operand ACC ACC-Memory[operand] Aritmética SUBI operand ACC ACC-operand Aritmética Reservado para futuras gerações. Fonte: Adaptado de Morandi et al. (2006) Organização A organização do processador utiliza a estrutura Harvard, conforme a Figura 1, com memórias separadas para dados e instruções (MORANDI, RAABE, ZEFERINO, 2006). O processador é dividido em dois blocos sendo o Controle, responsável por gerar sinais para o caminho de dados e atualização do PC, e Caminho de dados, responsável por executar a instrução. 7

17 Figura 1. Organização do BIP I Fonte: Adaptado de Morandi et all (2006) BIP II Arquitetura O BIP II é extensão do BIP I e uma das mudanças realizadas foi a inclusão de instruções de desvio, tornando possível a implementação de desvios condicionais, incondicionais e laços repetição (MORANDI; RAABE; ZEFERINO, 2006). Para possibilitar o suporte a desvios um novo registrador chamado de STATUS foi agregado à arquitetura original do BIP I, conforme a Tabela 3. As operações aritméticas são responsáveis por atualizar o estado do registrador STATUS que por sua vez possui dois flags: (i) Z, que indica se o 8

18 estado da última operação na ULA (Unidade Lógica Aritmética) foi igual a zero ou não; e (ii) N, que indica se o resultado da ULA foi um número negativo ou não. Tabela 3. Arquitetura do BIP II Tamanho da palavra de 16 bits dados Tipo de dados Inteiro de 16 bits com sinal: a Tamanho da palavra de 16 bits instruções Formato de instrução Registradores Classes de instrução Fonte: Adaptado de Morandi, Raabe e Zeferino (2006). ACC: acumulador IR: registrador de Instrução (depende da implementação) PC: contador de programa STATUS: registrador de estado com dois flags (Z e N) Transferência (acesso a memória): STO, LD e LDI Aritmética: ADD, ADDI, SUB e SUBI Controle HLT. Desvio: BEQ, BNE, BGT, BGE, BLT, BLE e JMP As instruções HLT, STO, LD, LDI, ADD, ADDI, SUB e SUBI, presentes no BIP II, possuem as mesmas características do BIP I. As instruções de desvio agregadas ao BIP II, conforme a Tabela 4, são BEQ, BNE, BGT, BGE, BLT, BLE e JMP, onde JMP é uma instrução de desvio incondicional e as outras são de desvio condicional. Tabela 4. Instruções de desvio do BIP II Opcode Instrução Operação e atualização do PC BEQ operand BNE operand BGT operand BGE operand BLT operand BLE operand JMP operand PC endereço Reservado para as futuras gerações Fonte: Adaptado de Zeferino (2007). Se (STATUS.Z=1) então PC endereço Senão PC PC + 1 Se (STATUS.Z=0) então PC endereço Senão PC PC + 1 Se (STATUS.Z=0) e (STATUS.N=0) então PC endereço Senão PC PC + 1 Se (STATUS.N=0) então PC endereço Senão PC PC + 1 Se (STATUS.N=1) então PC endereço Senão PC PC + 1 Se (STATUS.Z=1) ou (STATUS.N=1) então PC endereço Senão PC PC + 1 9

19 Organização A organização do BIP II, ilustrada pela Figura 2, compreende uma extensão BIP I incluindo o registrador STATUS e modificações necessárias para a implementação de desvios no circuito de atualização do PC. A fonte da atualização do PC, neste caso, é definida em função do tipo de desvio e do estado do registrador STATUS. Dependendo da implementação do processador, o registrador IR pode ou não estar presente. Em sua implementação mais simples, ilustrada pela Figura 2, o registrador IR não é utilizado e o registrador PC aponta para a instrução corrente. Figura 2. Organização do BIP II Fonte: Adaptado de Pereira (2008) BIP III O BIP III estende o BIP II acrescentando instruções de lógica com foco no suporte à operação de lógica bit a bit. Sua arquitetura e organização não foram formalizadas em trabalhos anteriores relacionados à família BIP, pois não acrescentou grandes mudanças em relação ao BIP II. Dentre as mudanças na organização destaca-se a inclusão de uma unidade lógica e mudanças no decodificador para suportar as novas instruções. Conforme Pereira (2008), a junção da unidade 10

20 aritmética com a unidade lógica passa a se chamar Unidade Funcional assim como no µbip que será detalhado posteriormente. A organização da Unidade Funcional é ilustrada pela Figura 3. Operand1 Operand2 Operation +/- Shift Left Shift Right C Z N Result Figura 3. Organização da Unidade Funcional Fonte: Pereira (2007) Quanto à arquitetura somente houve a adição da classe de instruções de lógica booleana e deslocamento lógico conforme a Tabela 5. Tabela 5. Instruções de Lógica do BIP III Opcode Instrução Flags Operação e atualização do PC NOT Z,N ACC NOT(ACC) PC PC AND operand Z,N ACC ACC AND Memory[operand] PC PC ANDI operand Z,N ACC ACC AND operand PC PC OR operand Z,N ACC ACC OR Memory[operand] PC PC ORI operand Z,N ACC ACC OR operand PC PC XOR operand Z,N ACC ACC XOR Memory[operand] PC PC XORI operand Z,N ACC ACC XOR operand PC PC SLL operand Z,N ACC ACC << operand PC PC SRL operand Z,N ACC ACC >> operand PC PC + 1 Fonte: Adaptado de Pereira (2008). 11

21 2.1.4 µbip O µbip é um microcontrolador da família BIP com foco no ensino de sistemas embarcados em cursos de graduação e pós-graduação (PEREIRA, 2008) Arquitetura O µbip estende a arquitetura do BIP agregando um conjunto de instruções típicas de microcontroladores (PEREIRA, 2008). Além das instruções herdadas da família BIP, o µbip contempla instruções de manipulação de vetores, interrupções e chamadas de subrotinas. O µbip possui ainda o modo de endereçamento indireto, utilizado para manipulação de vetores. O µbip, assim como os demais processadores da família BIP, possui os seguintes registradores: (i) PC, que contém o endereço da instrução corrente (a partir do BIP II passou a exercer a função do registrador IR); (ii) ACC, que contém o resultado das operações realizadas; e (iii) STATUS, que contem informações sobre o resultado da operação na ULA; Para dar suporte à chamada de procedimentos e manipulação de vetores, os seguintes registradores foram incluídos: (i) INDR (Index Register), que contém o índice do vetor; e (ii) SP (Stack Pointer), que aponta para o topo da pilha (Top of Stack, ou ToS) de suporte a chamada de procedimentos. Quanto ocorre uma chamada de procedimento ou interrupção, o endereço da próxima instrução é armazenado no topo de uma estrutura de pilha. Além dos flags Z e N, já presentes no registrador STATUS no BIP II, o flag C está presente no µbip com a finalidade de indicar se ocorreu um carry-out ou borrow (excede os 16 bits, no caso dos processadores BIP) em instruções aritméticas (PEREIRA, 2008). A Tabela 6 ilustra as instruções acrescidas ao µbip onde STOV e LDV dão suporte à manipulação de vetores, CALL e RETURN à chamada de subrotinas e RETINT a suporte a interrupções. 12

22 Tabela 6. Instruções agregadas ao µbip Opcode Instrução Operação e atualização do PC STOV operand Memory[operand + INDR] ACC PC PC LDV operand ACC Memory[operand + INDR] PC PC RETURN PC ToS RETINT PC ToS CALL operand Fonte: Adaptado de Pereira (2008). PC operand ToS PC+1 Nas instruções de manipulação de vetores (STOV e LDV) deve-se armazenar o deslocamento no registrador INDR utilizando o comando STO $indr. O cálculo do endereço efetivo será a soma do conteúdo do registrador INDR com operand (PEREIRA, 2008). A instrução CALL realiza uma chamada de procedimento para o endereço indicado por operand. O endereço seguinte a instrução CALL é armazenado no topo da pilha de suporte a procedimentos. O retorno do procedimento é feito através da instrução RETURN (PEREIRA, 2008). A instrução RETINT é utilizada para retornar de uma interrupção. Ao utilizar esta instrução a execução é desviada para o endereço anterior à interrupção (PEREIRA, 2008) Organização A organização do µbip, conforme a Figura 4, além dos atributos já citados nos outros processadores BIP, acrescenta: (i) uma pilha para controle do suporte a procedimentos; (ii) uma unidade de manipulação de vetores; (iii) uma interface de acesso aos registradores de propósito especiais (SFR Special Function Register) utilizados nos periféricos integrados; e (iv) um controlador de interrupções. 13

23 Pilha Stack in Unidade de Controle CPU Extensão de Sinal Caminho de Dados Stack out WrEn Op Controle de Interrupções Intr 1 0 0x x001 + Decodificador Stack_wr Stack_op WrPC WrACC SelA SelB SelC is_vector WrData FU_Op SourcePC Opcode Z N C Z N C SelA WrACC ena ACC operando1 4 operando2 Unidade Funcional 1 0 SelB WrData SelC 1 0 SFRs addr_in data_in wren data_out ena PC Indr FU_Op addr_in Operação is_vector is_vector Manipulação de Vetores addr_out data_in ena STATUS N Z C WrData Addr Out_Data Wr Addr In_Data Out_Data Memória de Instruções Memória de Dados Figura 4. Organização do µbip Fonte: Pereira (2008). A pilha tem a finalidade de guardar o endereço seguinte à instrução call. Seu hardware é simples, composto de uma estrutura tipo LIFO (Last In First Out), um somador/subtrator e um registrador (SP - Stack Pointer) que indica o topo da pilha (PEREIRA, 2008). Para a manipulação de vetores o µbip utiliza um hardware composto de um registrador (INDR) e um somador. O acesso e a gravação ocorrem utilizando o valor do operando somado do valor do registrador INDR para definir a posição de memória (PEREIRA, 2008). Para E/S (Entrada/Saída) o µbip possui 16 pinos que podem ser configurados individualmente como entrada ou saída onde o registrador portx_dir determina a direção e o registrador portx_data é o registrado utilizado para armazenar o dado lido ou a escrever. A direção é definida pelo registrador portx_dir atribuindo 1 para entrada e 0 para saída para cada um dos 16 pinos. Lembrando que X representa o identificador da porta (PEREIRA, 2008). O µbip possui um temporizador configurável onde cada estouro do temporizador gera uma interrupção. As interrupções, além de serem ativadas pelo temporizador, podem ser por detecção de 14

24 borda do pino 0 da porta port0. Ao ocorrer uma interrupção a execução do programa desvia para o endereço 0x001 onde as rotinas de interrupção serão tratadas (PEREIRA, 2008). 2.2 Simuladores de Arquitetura Esta etapa visa analisar características de simuladores de arquitetura de processadores que permitam E/S. Utilizaram-se como referência inicial os simuladores de arquitetura analisados em Vieira (2009), porém alguns destes foram retirados da análise por não possuírem versões funcionais acessíveis como o Simularq ou por não contemplarem entrada e saída como o 4AC, VLIW-DLX e R10k e outros três simuladores foram incluídos: ABACUS, WinMIPS64 e GNUSim NeanderWin O NeanderWin é um simulador de caráter educacional desenvolvido para a máquina Neander-X onde é possível editar, compilar e executar códigos de programas em linguagem de montagem do processador Neander-X (BORGES; SILVA, 2006). Conforme Borges e Silva (2006), o Neander-X é uma extensão da máquina Neander original e sua arquitetura inclui entre outros detalhes: 1. Carga de dados imediatos no acumulador; 2. Modo indireto de endereçamento; e 3. Operações de E/S para dois dispositivos mapeados no simulador NeanderWin: um painel de chaves e um visor. 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 os dispositivos mapeados para entrada e saída, ilustrados por chaves e um visor seguido do editor de textos e a direita se situam os verificadores dos registradores principais da CPU (Central Processing Unit) e o visualizador da memória. 15

25 Figura 5. Tela principal do sistema NeanderWin Fonte: Borges e Silva (2006). As instruções de E/S do Neander-X são representadas por IN e OUT seguido de um operando. A instrução IN trás para o acumulador o valor lido em um dispositivo externo, indicando pelo operando, que no NeanderWin são chaves (endereço 0) e o status de dado disponível das chaves (endereço 1). Já a instrução OUT descarrega o conteúdo do acumulador em um dispositivo externo, representado no NeanderWin por um visor no endereço 0 (BORGES; SILVA, 2006) MipsIt O MipsIt é um conjunto de ferramentas formado por um ambiente de desenvolvimento, uma plataforma de hardware e uma série de simuladores desenvolvidos com o propósito de auxiliar o ensino de arquitetura e organização de computadores (BRORSSON, 2002). 16

26 No MipsIt é possível ter uma visão geral do funcionamento do processador, como registradores, sinais de interrupção, portas de E/S e memória. A Figura 6 mostra o MipsIt com algumas de suas janelas abertas. A entrada e saída no MipsIt é feita através de oito chaves binárias e oito leds que, conforme Brorsson (2002), são as mesmas implementadas em hardware. Figura 6. Janelas do MipsIt Fonte: Brorsson (2002) ABACUS O ABACUS (ZILLER, 1999) é um simulador do Microprocessador 8085 desenvolvido por pesquisadores da Universidade Federal de Santa Catarina (UFSC), sob a coordenação do Prof. Roberto M. Ziller. A Figura 7 ilustra a interface do simulador ABACUS. A interface dispõe de várias janelas onde são exibidas as instruções, conteúdo dos registradores, conteúdo da memória e portas de E/S. As portas de E/S são representadas por um conjunto de chaves e um conjunto de leds respectivamente. 17

27 Figura 7. Tela principal do ABACUS Fonte: Ziller (1999) WinMIPS64 O WinMIPS64 é um simulador de instrução do MIPS 64 bits e foi projetado como um substituto para o utilitário WinDLX (SCOTT, 2010). A interface do WinMIPS64 é composta de sete janelas: Pipeline, Code, Data, Registers, Statistics, Cycles e Terminal. O simulador suporta entrada e saída através dos registradores de controle, utilizado para configurar a porta, e de dados. A comunicação é realizada através de um terminal conforme ilustra a Figura 8. 18

28 Figura 8. Tela principal do WinMIPS64 Fonte: Scott (2010) GNUSim8085 O GNUSim8085 (GNUSim8085, 2003) é um simulador do processador Intel 8085 desenvolvido por Sridhar Ratnakumar em 2003 para os ambientes Linux e Windows. Na interface do GNUSim8085 é possível visualizar o conteúdo dos registradores, flags e memória. A ferramenta apresenta também campos para interação com portas de entrada e saída e memória conforme ilustra a Figura 9. 19

29 Figura 9. Tela Principal do GNUSim8085 Fonte: GNUSim8085 (2003) Comparação entre Simuladores Analisados A partir dos simuladores descritos foi possível identificar características referentes à interface de E/S. Outras funcionalidades analisadas em Vieira (2009), como simulação da organização e desenvolvimento de programas em linguagem de alto nível representam um grande diferencial para o ensino (BORGES; SILVA, 2006) e foram incluídas na comparação que é ilustrada na Tabela 7. Os simuladores estudados, em sua maioria, apresentam interfaces baseadas em controles simples, como representações de chaves e leds, e também visores ilustrando valores em decimal ou em hexadecimal. Estas interfaces permitem resolver problemas onde a entrada e saída são números, como um algoritmo simples que soma dois números, e problemas que simulem o controle de algum dispositivo acoplado ao processador que tenham a necessidade de ler ou escrever em determinados bits da porta. Baseado nisto, optamos por adotar como proposta para o Bipide uma interface baseada em chaves e leds e que tenha também a opção de edição e leitura em decimal. 20

30 Tabela 7. Características dos sistemas analisados Simulador Simulação da Desenvolvimento de programas Interface Organização em linguagem de alto nível NeanderWin Não Não Chaves e visor MipsIt Sim Sim Chaves e Leds ABACUS Não Não Chaves e Leds WinMIPS64 Não Não Terminal GNUSim8085 Não Não Campo Editável Proposta para o Bipide Sim Sim Chaves e Leds Observa-se que na comparação acima os sistemas Bipide e MipsIt apresentam as mesmas características. Porém, a simulação da organização do Bipide, permite ao usuário visualizar, através de animações, o funcionamento dos componentes do processador. Esta característica é um grande diferencial auxiliando o aprendizado. 2.3 Bipide A ferramenta Bipide é uma IDE que implementa instruções dos processadores BIP I e BIP II onde é possível a criação de algoritmos em portugol e sua execução passo a passo. A ferramenta permite visualizar o código correspondente em linguagem assembly e o estado dos componentes da organização do processador contando com animações que ilustram seu funcionamento (VIEIRA, 2009). Na implementação da interface gráfica e classes do Bipide foi utilizada a ferramenta de desenvolvimento Visual Studio 2008 (MICROSOFT CORPORATION, 2009) na linguagem C#. Para implementar as animações e elementos gráficos do simulador utilizou-se a ferramenta Expression Blend 2 (MICROSOFT CORPORATION, 2008a). A gramática e os analisadores do compilador foram definidos utilizando a linguagem ANTL3 e a IDE ANTLRWorks (PARR, 2009) Compilador Conforme Vieira (2009), o subconjunto da linguagem Portugol, suportado pelo Bipide, foi definido segundo as características arquiteturais dos processadores BIP I e BIP II, onde foram disponibilizadas estruturas básicas de desvio e repetição além dos elementos básicos da estrutura de um programa. 21

31 A Tabela 8 ilustra a lista de símbolos da gramática Portugol onde é possível observar que somente o tipo de dado inteiro é suportado assim como os operadores aritméticos de adição e subtração. Tabela 8. Lista de Símbolos da Gramática Portugol Portugol Programa Declaracoes Defina Inicio Fim Inteiro se entao Senao Fimse enquanto faca Fimenquanto repita quando para ate passo Fimpara Descrição Símbolo inicial da gramática Definição de bloco de declaração de variáveis Definição de constantes Identifica o início do algoritmo Identifica o fim do algoritimo Tipo de dado numérico inteiro Desvio condicional Negação do SE Fim do bloco de desvio condicional Laço de repetição com condição no início Fim de bloco de laço condicional Laço de repetição com condição no fim Laço condicional com repetição incremental Fim de bloco de laço condicional com repetição incremental <- Operador de atribuição (,) Parênteses +,- Operadores aritméticos >, <, >=, <=,!=, = Operadores relacionais Fonte: Adaptado de Vieira (2009). O compilador do Bipide gera, a partir do código em portugol, o código em linguagem de montagem para os processadores BIP dividido em duas seções: (i) cabeçalho (.data), contendo a declaração de variáveis; e (ii) código (.text), contendo as instruções do programa. Para construção do compilador do Bipide, foi utilizada a ferramenta ANTLR3 (ANother Tool for Language Recognition V.3 ), (ANTLR, 2007) onde foram gerados os analisadores léxico e sintático e definidas as ações semânticas para geração do código em linguagem de montagem e tratamento de erros. Utilizou-se também a IDE ANTLRWorks que é um ambiente de desenvolvimento de gramáticas para o ANTLR3. Segundo Vieira (2009), a utilização da IDE ANTLRWorks facilitou a integração do compilador no ambiente Bipide, já que permite a geração de código para C#, linguagem na qual o Bipide foi desenvolvido. 22

32 A Figura 10 ilustra o trecho de gramática correspondente aos comandos aceitos pelo portugol onde cmdo é composto por desvios, laços e atribuições e estes compostos por suas devidas estruturas. Note que nas linhas 8 e 9 os comandos para leia e escreva estão comentados, já que o Bipide em seu estado atual não os suporta. O Apêndice A contém a gramática completa da linguagem portugol incluindo as novas especificações que serão vistas posteriormente. Figura 10. Exemplo da gramática do Portugol no ANTLR Fonte: Adaptado de Vieira (2009) As ações semânticas na ANTLR são definidas na gramática adicionando o código fonte que será responsável pela ação. A Figura 11 mostra um trecho da gramática do portugol onde as partes da gramática aparecem em negrito seguido da ação semântica delimitada por chaves. Os símbolos terminais são representados por letras maiúsculas e os símbolos não terminais são representados por letras minúsculas. As ações ilustradas na Figura 11 são responsáveis por armazenar o código em portugol para posteriormente relacionar com a instrução ou instruções correspondentes em assembly. Figura 11. Exemplos de ações semânticas do Bipide Fonte: Adaptado de Vieira (2009). 23

33 2.3.2 Simulador Conforme Vieira (2009), o módulo de simulação do Bipide, ilustrado na Figura 12, permite a visualização simultânea da linguagem de alto nível, linguagem assembly e a organização do processador permitindo a redução da abstração apresentadas nos conceitos de programação. Figura 12. Simulador do Bipide Fonte: Vieira (2009) Para implementar as animações e elementos gráficos do simulador foram utilizadas a tecnologia WPF e a ferramenta Expression Blend 2 (VIEIRA, 2009). O WPF trata-se de uma tecnologia para desenvolvimento de aplicativos e interfaces, desenvolvida pela Microsoft. O WPF permite que a interface seja independente do código, podendo ser desenvolvida por um designer enquanto que o código por um programador especializado. A flexibilidade do WPF permite interfaces com recursos 3D, animações, gráficos vetoriais entre outros recursos (SONNINO; SONNINO, 2006). 24

34 Um programa em WPF é geralmente composto por um arquivo XML (extensible Markup Language) com características especiais chamado XAML (extended Aplication Markup Language) e um código para.net. No XAML os elementos assim como seus atributos são definidos usando tags. A Figura 13 ilustra um exemplo de código fonte na linguagem XAML onde é possível observar a definição de um componente Label e seus atributos. Este mesmo componente poderá ser utilizado da mesma maneira que um componente de uma aplicação Windows Forms utilizando um código para.net. Figura 13. Exemplo de código fonte da linguagem XAML Fonte: Sonnino, Sonnino (2006). O Expression Blend 2, por sua vez, é uma ferramenta de design para criação de aplicações em WPF que podem ser desenvolvidos para plataforma Windows ou Web (MICROSOFT CORPORATION, 2008b). A linguagem XAML permite que aplicações criadas com o Expression Blend 2 sejam compatíveis com o Visual Studio 2008 (MICROSOFT CORPORATION, 2008a). A Figura 14 apresenta uma visão geral da ferramenta Expression Blend 2 onde é possível observar parte da definição das animações do simulador do Bipide, o código em linguagem XAML e logo abaixo as linhas de tempo que representam animação ao longo do tempo o que facilita a criação de animações. As animações do simulador foram definidas em função das instruções dos processadores BIP. A execução de uma instrução resulta na execução de uma animação na organização do processador. 25

35 Figura 14. Visão geral da ferramenta Expression Blend 2 Fonte: Adaptado de Vieira (2009) 26

36 3 DESENVOLVIMENTO Esta seção tem por objetivo apresentar os requisitos e especificações do BIP IV e seu suporte na IDE Bipide. Também detalha a implementação das alterações na IDE Bipide. 3.1 Especificação do BIP IV Para contemplar os objetivos deste trabalho o BIP IV deve suportar E/S e chamada de subrotinas. Por isso, a especificação do BIP IV foi baseada em antecipar algumas instruções presentes no µbip e estender o BIP III. Além de E/S e chamada de procedimentos foi adotado suporte a operações lógicas, deslocamento bit a bit e manipulação de vetores Arquitetura BIP IV. Esta seção tem como objetivo descrever os atributos arquiteturais presentes no processador Tamanho da Palavra e tipo de Dados O tamanho da palavra de dados e de instruções do BIP IV, assim como nos outros processadores BIP, é de 16 bits. Somente o tipo Inteiro de 16 bits é suportado, comportando valores entre e Espaços de Endereçamento O espaço de endereçamento de memória de dados e instruções do BIP IV foi mantido em 11 bits sendo possível endereçar até 2K de instruções ou dados. Para suportar entrada e saída foi adotado o método de E/S mapeada em memória, assim como em Pereira (2008), não necessitando grandes modificações na arquitetura e na organização. Neste caso, 1K da memória de dados é reservado para os registradores de E/S, dividindo a memória ao meio e permitindo identificar pelo bit mais significativo se o acesso será à memória (0) ou à E/S (1). Esta divisão pode ser observada na Figura 15. Dos endereços reservados para E/S, apenas dois são utilizados. 27

37 1K Palavras 0x7FF... E/S LD 0x Opcode Operando... 0x400 0x3FF... 1K Palavras Memória de Dados... 0x000 LD 0x Opcode Operando Figura 15. Organização da Memória de E/S Fonte: Pereira (2008) Registradores O BIP IV possui os seguintes registradores: PC, que contém o endereço da instrução corrente; ACC que contém o resultado da UF (Unidade Funcional); STATUS que contém, nos flags Z e N, informações sobre o resultado da operação na ULA; INDR, que contém o índice a ser utilizado no suporte a vetores; SP, que aponta para o topo da pilha da chamada de procedimento; IN_PORT, mapeado em endereço de E/S, utilizado para entrada de dados; e OUT_PORT, também mapeados em endereço de E/S, utilizado para saída de dados. Os registradores INDR e SP são os mesmos adotados em Pereira (2008) Formato de Instruções O formato de instrução, ilustrado pela Figura 16, permaneceu composto por 5 bits para o código da instrução e 11 bits para o operando sendo o único formato suportado pelos processadores BIP Cód. Operação Operando Figura 16. Formato de Instruções do BIP IV 28

38 Modos de Endereçamento Os modos de endereçamento no BIP IV são os mesmos presentes no µbip, que além dos modos de endereçamento direto e imediato, possui o modo indireto. No modo direto o operando refere-se a um endereço efetivo da memória de dados. No modo imediato o operando é uma constante. Já no indireto, utilizado nas instruções STOV e LDV, o operando é um endereço base de um vetor o qual será somado ao registrador INDR determinando o endereço efetivo da memória de dados Conjunto de Instruções O conjunto de instruções do BIP IV, ilustrado pela Tabela 9, é uma extensão do conjunto de instruções presentes no BIP III, acrescidos de instruções presentes no µbip responsáveis pelo suporte a sub-rotinas e manipulação de vetores. Tabela 9. Conjunto de Instruções do BIP IV Opcode Instrução Operação e atualização do PC HLT Desabilita atualização do PC PC PC STO operand Memory[operand] ACC PC PC LD operand ACC Memory[operand] PC PC LDI operand ACC operand PC PC ADD operand ACC ACC + Memory[operand] PC PC ADDI operand ACC ACC + operand PC PC SUB operand ACC ACC Memory[operand] PC PC SUBI operand ACC ACC operand PC PC BEQ operand BNE operand BGT operand BGE operand BLT operand BLE operand Se (STATUS.Z=1) então PC operand Se não PC PC + 1 Se (STATUS.Z=0) então PC operand Se não PC PC + 1 Se (STATUS.Z=0) e (STATUS.N=0) então PC operand Se não PC PC + 1 Se (STATUS.N=0) então PC operand Se não PC PC + 1 Se (STATUS.N=1) então PC operand Se não PC PC + 1 Se (STATUS.Z=1) ou (STATUS.N=1) então PC operand 29

39 Se não PC PC JMP operand PC operand NOT ACC NOT(ACC) PC PC AND operand ACC ACC AND PC PC + 1 Memory[operand] ANDI operand ACC ACC AND operand PC PC OR operand ACC ACC OR PC PC + 1 Memory[operand] ORI operand ACC ACC OR operand PC PC XOR operand ACC ACC XOR Memory[operand] PC PC XORI operand ACC ACC XOR operand PC PC SLL operand ACC ACC << operand PC PC SRL operand ACC ACC >> operand PC PC STOV operand Memory[operand + INDR] ACC LDV operand ACC Memory[operand + INDR] PC PC + 1 PC PC RETURN PC ToS Não utilizada CALL operand PC operand ToS PC+1 A Tabela 9 contém o conjunto de instruções e suas respectivas ações e atualização PC. A instrução está implementada no µbip e é responsável pelo retorno de interrupções, porém não foi utilizada. Para manter a compatibilidade entre os processadores BIP IV e µbip, este mesmo código não foi utilizado para uma instrução com outra finalidade. O conjunto de instruções é formado por 28 instruções. Como o opcode composto por 5 bits permite até 32 instruções, restam 4 instruções, sendo 3 para novas instruções e 1 delas está implementada como retorno de interrupção em Pereira (2008). A Figura 17 mostra as classes de instruções dos processadores BIP sendo possível observar também, em qual processador cada classe de instrução está presente. Lembrando que as instruções agregadas ao BIP IV foram herdadas do processador µbip. Uma descrição mais completa do conjunto de instruções do BIP IV é apresentada no Apêndice B. 30

40 Figura 17. Classes de Instruções dos processadores BIP Ressalta-se que o suporte a procedimento foi baseado na solução utilizada em Pereira (2008), onde há uma pilha implementada em hardware dedicada para armazenar o endereço da instrução seguinte a chamada de procedimento. 31

41 Resumo da arquitetura do BIP IV A Tabela 10 ilustra o resumo da arquitetura do BIP IV. Tabela 10. Resumo da arquitetura do BIP IV Tamanho da palavra de dados 16 bits Tipos de dados Inteiro de 16 bits com sinal a Tamanho da palavra de instrução 16 bits Formato de instrução Cód. Operação Operando Modos de endereçamento Registradores Classes de instrução Direto: o operando é um endereço da memória Imediato: o operando é uma constante Indireto: o campo Operando é um endereço base de um vetor que é somado ao INDR para o cálculo de um endereço efetivo da memória de dados ACC: acumulador PC: contador de programa STATUS: registrador de Status INDR: registrador de índice SP: apontador do topo da pilha Armazenamento: STO Carga: LD e LDI Aritmética: ADD, ADDI, SUB e SUBI Lógica booleana: AND, OR, XOR, ANDI, ORI, XORI e NOT Controle: HLT Desvio: BEQ, BNE, BGT, BGE, BLT, BLE e JMP Deslocamento Lógico : SLL e SRL Manipulação de vetor: LDV e STOV Suporte a procedimentos : RETURN e CALL Organização A organização do BIP IV foi baseada na organização do processador BIP III com a adição de alguns componentes presentes no µbip para suportar manipulação de vetores e chamada de subrotinas além dos pinos de E/S (registradores IN_PORT e OUT_PORT). Estes componentes compreendem uma pilha de suporte a procedimentos, onde será salvo o endereço de memória da instrução seguinte à chamada da sub-rotina e uma unidade de manipulação de vetores. O módulo de manipulação de vetores é composto por um registrador (INDR) e um somador. Este módulo é responsável por calcular o endereço efetivo de memória através da soma do operando nas instruções LDV e STOV com o conteúdo do registrador INDR. A Figura 18 mostra a organização do módulo de manipulação de vetores, onde os pinos wr_indr e data_in são responsáveis pela gravação do registrador INDR, e o pino select, é responsável por definir se a saída será a soma da entrada operand com o conteúdo do registrador INDR ou apenas operand (PEREIRA,2008). 32

42 select operand wr_indr data_in ena INDR sel addr Figura 18. Organização do módulo de manipulação de vetores Fonte: Pereira (2008) A Figura 19 ilustra a organização do BIP IV onde é possível observar os componentes agregados ao processador, como a pilha (representada como Stack) e a unidade de manipulação de vetores (representada por Vector Access), além dos controles adicionados ao decodificador de instruções. 33

43 PILHA Stack in Extensão de Sinal Stack out WrEn x001 + Decodificador Stack_wr Stack_op WrPC WrACC SelA SelB SelC is_vector WrData FU_Op SourcePC Opcode Z N Z N 2 SelA WrACC ena 1 ACC 0 1 operand1 operand2 Unidade Funcional 0 SelB WrData addr_in data_in wren E/S ena PC FU_Op Operation is_vector addr_in is_vector_in Manipulação de Vetores addr_out data_in ena STATUS N Z SelC 0 1 data_out WrData Addr Out_Data Wr Addr In_Data Out_Data Memória de Programa Memória de Dados Figura 19. Organização do BIP IV 3.2 Alterações na IDE Bipide Para contemplar o objetivo deste trabalho, a IDE Bipide foi alterada de modo a suportar os seguintes requisitos: (i) fornecer suporte a operações de E/S; (ii) fornecer suporte a utilização de vetores; (iii) fornecer suporte a chamada de sub-rotinas com passagem de parâmetros; e (iv) fornecer suporte a operações de lógica. As principais alterações no Bipide foram relacionadas basicamente a mudanças na gramática do portugol, geração do código em assembly e mudanças no simulador. A sintaxe da linguagem portugol está disponível no Apêndice E.Em decorrência das alterações na gramática, novas verificações nas ações semânticas foram implementadas e serão descritas ao longo desta Seção. A Figura 20 ilustra a estrutura básica na qual o Bipide foi desenvolvido. 34

44 Gramática + ações semânticas ANTLR Analisadores do compilador Código Fonte em C# Classes e Interface Visual Studio Bipide Expression Blend XAML (Animações do Simulador) Figura 20. Fluxo de Implementação do Bipide O simulador do Bipide, em sua versão anterior, permitia escolher entre os processadores BIP I e BIP II, refletindo em mudanças nas instruções disponíveis, ilustrações e animações do processador. A fim de manter esta idéia, o simulador foi alterado de modo a permitir escolher, além do BIP I e BIP II, os processadores BIP III e BIP IV Operações de E/S O ambiente Bipide foi modificado a fim de suportar comandos de E/S ao simular o processador BIP IV. Estas modificações incluem a gramática do portugol, geração de código assembly e mudanças no simulador Mudanças na Gramática de Portugol A gramática portugol definida neste projeto suporta comandos do tipo leia e escreva. Estes comandos permitem um ou mais argumentos como parâmetro conforme a Figura 21. Para isso, foram incluídos dois símbolos terminais (tokens), chamados leia e escreva, e mais duas derivações para o não-terminal cmdo conforme mostra a Figura 21. LEIA : 'leia' 'LEIA'; ESCREVA: 'escreva' 'ESCREVA'; cmdo : cmd_se cmd_se_senao cmd_enq_faca cmd_faca cmd_para cmd_leia cmd_escreva 35

45 atribuicao cmd_return cmd_call ; cmd_leia : LEIA '(' lista_id ')' ; cmd_escreva lista_id : ESCREVA '(' lista_saida ')'; : id (',' id)*; lista_saida : exp (',' exp)*; Figura 21. Alterações na gramática de E/S Geração de Código Assembly Como as operações de E/S são mapeadas em endereço de memória, foram utilizadas instruções de transferência (armazenamento e carga) onde os operandos são os registradores $in_port (para entrada) e $out_port (para saída). A Figura 22 apresenta um código exemplo em portugol e seu respectivo código em assembly. A geração de código ficou semelhante a uma atribuição, não gerando grande complexidade de implementação. Portugol procedimento principal() declaracoes inteiro a,b inicio leia (a,b) a <- a + b escreva (a) fim Figura 22. Geração de código para E/S Descrição.DATA A : 0 B : 0.TEXT _principal: LD $in_port ;lê o endereço de entrada STO A ;grava em a LD $in_port ;lê o endereço de entrada STO B ;grava em b LD A ADD B STO A LD A ;carrega a STO $out_port ;grava no edereço de saída HLT Mudanças no Simulador No caso do BIP IV, o simulador apresenta uma interface de leds como periférico de saída e chaves binárias como periférico de entrada. Estes periféricos representam os valores das posições mapeadas em memória para esta finalidade. Esta solução, utilizando leds e chaves, foi adotada em alguns simuladores estudados como NeanderWin, MipsIt e ABACUS e a utilizamos por refletir em um nível de abstração médio na qual fica transparente ao utilizador o real funcionamento do 36

46 hardware. Além das chaves e leds, é possível a edição e leitura em decimal assim como citado na comparação entres os simuladores estudados. A Figura 23 apresenta a interface de E/S do simulador do Bipide. Figura 23. Interface de E/S No caso da leitura, como não há como saber quando os dados estão prontos para leitura, uma opção de breakpoint (ponto de parada) automática foi disponibilizada no simulador para estas operações. Com um programa em execução e com a opção de breakpoint habilitada, o simulador para a execução antes da instrução de entrada, permitindo que o utilizador informe um valor através das chaves da interface de E/S ou digitando. Para a execução da simulação foram necessários ajustes no tratamento de instruções de transferência (LD e STO) a fim de suportar acesso aos registradores $in_port e $out_port, que estão localizados nos endereços 1024 e 1025 respectivamente. Também foram implementadas duas novas animações que ilustram o acesso aos registradores Utilização de Vetores Para suportar a utilização de vetores, foram necessárias alterações na gramática do Portugol, no analisador semântico, na geração de código assembly e no simulador, conforme detalhado a seguir. Cabe lembrar que o suporte a vetores estará disponível somente ao simular o BIP IV Mudanças na Gramática do Portugol As mudanças na gramática compreendem declarações de vetores e seu uso em expressões e comandos. A Figura 24 ilustra as alterações efetuadas na declaração de variáveis, atribuição e uso de vetores em expressões. Estas alterações permitem códigos em portugol semelhantes ao ilustrado pela Figura ID : (('a'..'z' 'A'..'Z') ('a'..'z' 'A'..'Z' '0'..'9' '_' )* );... 37

47 dec_var : INTEIRO lista_var ; lista_var : ID ('['VINT']')? (','ID ('['VINT']')?)* ;... atribuicao : id ('['exp']')? '<-' exp ;... atom : VINT ID ID ('['exp04']') '('! exp04 ')'! ID '('explist')' ID '('')' ;... Figura 24. Alterações na gramática para suporte a vetores Geração de Código Assembly Para a manipulação de vetores no BIP IV, são utilizadas as instruções STOV, para armazenamento, e LDV para carga. Estas instruções dependem do valor contido no registrador INDR para obter o valor efetivo da memória de dados a ser acessado. Para armazenar um valor no registrador INDR é utilizada a instrução STO seguido do endereço de acesso ao registrador representado por INDR. A Figura 25 mostra um pequeno algoritmo em portugol compilado pela ferramenta, com seu respectivo código assembly. Ao final da execução, o conteúdo de cada posição do vetor b será igual ao seu índice. Portugol procedimento principal() declaracoes inteiro a,b[5] inicio a <- 0 enquanto (a < 5) faca b[a] <- a escreva(b[a]) a<-a+1 fimenquanto fim.data a : 0 b : 0,0,0,0,0.text _PRINCIPAL: LDI 0 STO a INI_ENQ1: LD a STO 1000 LDI 5 STO 1001 LD 1000 SUB 1001 BGE FIMFACA1 LD a Assembly 38

48 Figura 25. Geração de Código para suporte a vetores STO 1000 LD a STO 1001 LD 1000 STO $indr LD 1001 STOV b LD a STO $indr LDV b STO $out_port LD a ADDI 1 STO a JMP INI_ENQ1 FIMFACA1: HLT 0 Note que o índice de um vetor do lado esquerdo da atribuição é armazenado em uma variável temporária para posteriormente ser gravado no registrador $indr a fim de permitir sua utilização na expressão do lado direito da atribuição. A Figura 26 ilustra o código responsável pela geração de código para atribuições, onde é possível observar o tratamento no caso de vetores. { { paraphrases.push("erro no comando Atribuição"); string strinst = "STO"; this.desempilhacontexto(); //desempilha as variáveis de controle if (atribuicaovetor){ strinst = "STOV"; string nomevar = GetVarTemp(); string indice = temporarios.pop(); this.addinstrucao("sto", nomevar); this.addinstrucao("ld", indice); this.addinstrucao("sto", "\$indr"); this.addinstrucao("ld", nomevar); atribuicaovetor = false; } paraphrases.pop(); this.addinstrucao(strinst, pilha.pop()); this.setinstrucaoportugol($atribuicao.text); } : id ({this.atribuicaovetor = true; this.addinstrucaoportugol(); }'['exp']'{ string nomevar = GetVarTemp(); temporarios.push(nomevar); this.addinstrucao("sto", nomevar); })? { if (!this.atribuicaovetor) this.addinstrucaoportugol(); this.empilhacontexto(); //armazena as variáveis de controle em uma pilha pilha.push($id.text); } '<-' exp ; Figura 26. Ações semânticas para geração de código para atribuições 39

49 Mudanças no Simulador Além dos componentes organizacionais do BIP III e BIP IV, o simulador foi alterado a fim de permitir a visualização do registrador INDR (no caso do BIP IV) e permitir a visualização da memória seqüencial alocada para o vetor no depurador. Também foram feitas animações quanto ao caminho de dados e controle do decodificador de instruções, como já implementados para os processadores BIP I e BIP II. Em caso de a posição a ser acessada em um vetor, durante uma simulação, violar o espaço definido em sua declaração, uma mensagem é exibida e a simulação é interrompida. Esta verificação é feita nas instruções LDV e STOV Chamada de sub-rotinas Para implementação de chamada de sub-rotinas, de suporte ao BIP IV, houve mudanças na gramática portugol, na geração do código assembly e no simulador Mudanças na Gramática do Portugol Anteriormente, a gramática portugol era composta por um único escopo identificado com o símbolo inicial programa. Para possibilitar o suporte a sub-rotinas, a gramática foi modificada para permitir mais de um escopo no programa sendo um principal. As sub-rotinas podem ser procedimentos ou funções e deverão suportar passagem de parâmetro. Na fase de projeto foi cogitado suporte a passagem de parâmetros por referência. Porém, após análise, foi constatado que sua utilização seria inviável, pelo fato de os processadores BIP não possuírem instruções que permitam utilização de ponteiros. A solução adotada na fase de projeto, na qual as variáveis passadas por referências seriam recuperadas após a chamada da sub-rotina, causaria o mesmo efeito, porém didaticamente, causaria uma falsa impressão de como seria a passagem de parâmetros por referência. A declaração de procedimentos tem como símbolo inicial o token procedimento. As funções iniciam com o símbolo inteiro (único tipo suportado pelos processadores BIP) já existente na gramática. A chamada das sub-rotinas é feita pelo seu identificador seguido pelos parâmetros entre parênteses e, no caso das funções, podem ser utilizadas em expressões, atribuições e comandos de Saída. 40

50 Para retornar da sub-rotina, foi adicionado o comando RETORNAR, que, no caso de uma função, poderá ser seguido de uma expressão, variável, constante ou até mesmo uma função. Na Figura 27 é possível observar as alterações que foram necessárias para o suporte a sub-rotinas. PROCEDIMENTO: 'procedimento' 'PROCEDIMENTO'; programa : escopo+; escopo : (PROCEDIMENTO INTEIRO) ID (('(' lista_param ')') ('(' ')')) dec INICIO lista_cmdo FIM ; cmdo : cmd_se cmd_se_senao cmd_enq_faca cmd_faca cmd_para cmd_leia escreva atribuicao cmd_return cmd_call ; parametro : INTEIRO id; lista_param : parametro (',' parametro)*; cmd_return : RETORNAR exp; parametro_chamada : exp; parametros_chamada : '(' parametro_chamada (',' parametro_chamada )* ')'; lista_param_chamada : '('')' parametros_chamada; cmd_call: ID '(' lista_param_chamada ')'; atom : VINT ID ID '('! exp04 ')'! ID '('explist')' ID '('')' ; Figura 27. Alterações na Gramática para suporte a sub-rotinas Geração de Código Assembly O suporte a sub-rotinas no BIP IV é feito através das instruções CALL, utilizada para chamar uma sub-rotina, e RETURN, utilizada para retornar à instrução posterior a chamada, cujo endereço estará armazenado na pilha de suporte a procedimentos. 41

51 Como as variáveis podem ter o mesmo nome em escopos diferentes, a geração do código das variáveis, com exceção do escopo principal, é composta do nome do procedimento e da variável, como é possível observar na Figura 28 onde é ilustrado um programa compilado pela ferramenta. Os procedimentos e funções são separados em blocos identificados por rótulos, onde a primeira instrução da seção.text é um desvio incondicional para o rótulo correspondente ao procedimento ou função principal conforme mostra a Figura 28. O retorno da função é feito através do registrador ACC sendo apenas necessário carregar o valor a ser retornado utilizando as instruções LD ou LDI. Após a execução do comando RETURN a execução do programa desviará para a instrução imediatamente posterior à chamada da sub-rotina. Portugol inteiro soma(inteiro a,inteiro b) declaracoes inteiro r inicio r <- a+b retornar r fim //principal procedimento principal() declaracoes inteiro a, b, x inicio leia (a,b) x <- soma(a,b) fim Figura 28. Geração de código para sub-rotinas Assembly.data soma_r : 0 soma_a : 0 soma_b : 0 a : 0 b : 0 x : 0.text JMP _PRINCIPAL _SOMA: LD SOMA_a ADD SOMA_b STO SOMA_r LD SOMA_r RETURN 0 _PRINCIPAL: LD $in_port STO a LD $in_port STO b LD a STO SOMA_a LD b STO SOMA_b CALL _SOMA STO x HLT 0 Procedimentos e funções são inseridos em uma tabela de símbolos para que seja possível verificar erros em declarações. No caso do uso de funções ou procedimentos, as mesmas devem estar declaradas, ou seja, seu código de declaração deverá estar anterior a sua utilização. O 42

52 compilador, também impede que procedimentos, por não retornarem valor sejam utilizados em expressões ou comandos derivados de expressões. O código fonte em portugol deve, obrigatoriamente, conter um procedimento ou função principal de nome principal e este não deve conter parâmetros. Como a gramática dá suporte a parâmetros, estes também são incluídos na tabela de símbolos. O compilador obriga também que uma função tenha um comando de retorno. Procedimentos podem conter o comando de retorno, porém este somente irá interromper sua execução não retornando nenhum valor. Devido às limitações da estrutura de suporte a procedimentos no BIP IV, herdada do µbip, não é permitido recursividade. A pilha grava somente o endereço de instruções o que obriga o uso de variáveis globais não permitindo recursividade. Também pelo motivo do uso de variáveis globais, não é permitido que a chamada de uma função seja utilizada como parâmetro para a mesma função (Ex: a soma(soma(2,3),4). Durante a implementação das alterações foram detectados problemas relacionados ao uso de variáveis temporárias (posições de memória temporárias utilizadas em instruções onde é necessário guardar o valor contido no acumulador). Estas posições de memória são definidas na geração de código assembly, e em testes realizados, ocorreram casos em que endereços temporários de memória eram compartilhados entre escopos diferentes comprometendo os dados. Para contornar a situação, a alocação desta memória temporária foi modificada a fim de impedir que endereços sejam compartilhados entre escopos diferentes. A modificação foi baseada em elevar o inicio das variáveis temporárias (definido previamente em 1000) ao final de cada bloco (escopo) conforme a utilização Mudanças no Simulador As alterações no simulador, quanto à chamada de sub-rotinas, foram alteradas a fim permitir a visualização do conteúdo do registrador SP (topo da pilha) e também apresentar animações referentes ao caminho de dados e sinais de controle do decodificador de instruções. 43

53 3.2.4 Operações de Lógica Para a implementação de operações de lógicas, de suporte ao BIP III e conseqüentemente ao BIP IV, foram necessárias pequenas mudanças na gramática portugol, geração de código assembly e simulador Mudanças na Gramática do Portugol As operações de lógica foram incluídas nas produções referentes as expressões conforme suas prioridades em relação às operações já existentes. Os operadores definidos para operações com lógica são: (i)! como operador NOT; (ii) ^ como operador XOR; (iii) como operador OR; (iv) & como operador AND; (v) << como operador de deslocamento à esquerda; e (vi) >> como operador de deslocamento à direita. Para o suporte às operações lógicas no portugol, apenas a produção exp foi modificada incluindo um nível de hierarquia de operadores conforme ilustra a Figura 29. A prioridade segue a seqüência da menor para a maior a partir do não terminal exp04 até o exp01. exp04 : exp03 : exp02 : exp01 : exp03 (( '&'^ ' '^ '\^'^) exp03)*; exp02 (( '<<'^ '>>'^) VINT)*; exp01 (( '+'^ '-'^) exp01)*; ('-' atom) -> ^('-' VOID atom) ('!' atom) -> ^('!' VOID atom) atom; explist: exp04 (','exp04)* -> ^(PARAM exp04)+; atom : VINT ID ID ('['exp04']') -> ^(VETOR ID exp04) '('! exp04 ')'! 44

54 ID '('explist')' -> ^(CALL ID explist) ID '('')' -> ^(CALL ID VOID) ; Figura 29. Alterações na gramática para suporte a operações lógicas Geração de código assembly Para a geração de código assembly foram utilizadas as instruções de lógica, presentes no BIP III e BIP IV, apresentadas na Tabela 9 neste Capítulo. A Figura 30 mostra um código em portugol com várias instruções de lógica e seus respectivos códigos em assembly gerados pela ferramenta. Portugol procedimento principal() declaracoes inteiro a, b, x inicio x <- a 1; x <- a & b; x <- a ^ b; x <- a << 2; x <- a >> 3; x <-!a; fim Figura 30. Geração de código para operações de lógica.data a : 0 b : 0 x : 0.text _PRINCIPAL: LD a ORI 1 STO x LD a AND b STO x LD a XOR b STO x LD a SLL 2 STO x LD a SRL 3 STO x LD a NOT 0 STO x HLT 0 Assembly Durante o desenvolvimento, observou-se que a abordagem utilizada até então para a geração de código não permitiria o tratamento de precedência de operadores, uma vez que não era necessária. Neste caso, a geração de código para expressões foi feita através de uma AST (Abstract Syntax Tree), gerada pelo ANTLR (ANTLR, 2007). Uma AST é uma estrutura que além de representar o código fonte, permite tratar prioridades como, neste caso, a precedência de 45

55 operadores. Esta árvore então é processada e seu respectivo código assembly é gerado. Na Figura 29 é possível observar o símbolo ^ que é responsável por criar um novo nó na árvore, e o símbolo -> responsável por permitir a modificação da geração da árvore. Na Figura 31 é possível observar os processos realizados para geração de código assembly de expressões. A primeira coluna representa a instrução em portugol. A segunda coluna representa a árvore, em formato texto, onde o primeiro símbolo dentro de um parêntese representa um nó e os restantes representam folhas ou outros nós. A terceira coluna, por sua vez, representa um código intermediário gerada para facilitar a geração do código assembly apresentado na quarta coluna. O símbolo # foi utilizado, em conjunto com um controle interno do uso do acumulador, para identificar operandos que estão em posições temporárias de memória ou no acumulador. Deve-se observar que no código assembly na Figura 31 é usado o endereço de memória 1000 para que a operação de subtração seja executada na seqüência correta uma vez que a operação de negação foi executada anteriormente. Portugol Árvore (em formato texto) a<-2-!3 (- 2 (! VOID 3)) Instruções intermediárias para geração de código! VOID 3-2 # Figura 31. Tratamento de precedência de operadores Assembly LDI 3 NOT 0 STO 1000 LDI 2 SUB 1000 STO a HLT Mudanças no Simulador As mudanças no simulador foram baseadas na interpretação das instruções e apenas uma animação nova para a instrução NOT que não possui operando agindo no valor contido no acumulador. Para o restante das instruções, foram reaproveitadas as animações utilizadas nas instruções de aritmética. O componente que ilustra a unidade de aritmética, utilizada nos processadores BIP I e BIP II, foi mantido inalterado, uma vez que também pode ser utilizada para representar uma unidade de aritmética e lógica Componentes da Organização dos Processadores na Simulação Assim como no BIP I e BIP II, a comutação da organização dos processadores é baseada em ocultar ou exibir componentes presentes em cada processador. Na Figura 31 é possível observar a 46

56 interface onde é exibida a organização do processador exibindo os componentes do BIP IV onde os itens numerados representam respectivamente: (i) pilha de suporte a procedimentos; (ii) unidade de manipulação de vetores; (iii) bloco de registradores de E/S; e (iv) componente responsável por definir se o acesso será a memória ou aos registradores de E/S. Figura 32. Componentes da Organização do processador no Simulador Lembrando que no simulador, como já explicado na seção anterior, não há alteração da ilustração do componente ULA. Por isso, na ilustração da organização, não há diferenças entre o BIP II e BIP III Módulo de Ajuda O módulo de ajuda presente na ferramenta foi atualizado a fim de comportar as novas definições referentes à linguagem portugol, arquitetura e organização dos novos processadores suportados Testes Na fase de projeto, foi cogitado o uso de instruções (testbench) disponibilizadas na página do Dalton Project (THE DALTON PROJECT TEAM, 2001). Porém observou-se que muitas destas instruções eram baseadas em cálculos com ponto flutuante ou de baixo nível, não sendo possível 47