Compilador para linguagem reversível Janus

(1)

Universidade Federal Fluminense

Instituto de Computa¸

c˜

ao

Departamento de Ciˆ

encia da Computa¸

c˜

ao

Vin´ıcius de Carvalho Brum

COMPILADOR PARA LINGUAGEM

REVERS´IVEL JANUS

Niteroi-RJ

2017

(2)

ii VIN´ICIUS DE CARVALHO BRUM

COMPILADOR PARA LINGUAGEM REVERS´IVEL JANUS

Trabalho submetido ao Curso de

Bacharelado em Ciência da Computa¸cão da Universidade Federal Fluminense como requisito parcial para a obten¸cão do t´ıtulo de Bacharel em Ciência da Computa¸cão.

Orientador: Prof. Luis Antonio Brasil Kowada

Niteroi-RJ 2017

(3)

Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

B893 Brum, Vinícius de Carvalho

Compilador para linguagem reversível Janus / Vinícius de Carvalho Brum. – Niterói, RJ : [s.n.], 2017.

42 f.

Projeto Final (Bacharelado em Ciência da Computação) – Universidade Federal Fluminense, 2017.

Orientador: Luis Antonio Brasil Kowada.

1. Compilador (Programa de computador). 2. Linguagem reversível. I. Título.

CDD 005.453

(4)

(5)

iv

Dedico este trabalho aos meus pais e irm˜ao, pelo apoio incondicional em todos os momen-tos.

(6)

v

Agradecimentos

Agrade¸co aos meus pais, irmão por todo apoio que sempre me deram. Ao meu orientador, pela ajuda na confeçcão deste trabalho. Aos meus colegas e professores que ajudaram a caminhar na minha gradua¸cão. Aos professores Aline e Bruno pela presen¸ca na banca examinadora.

(7)

vi

Resumo

Uma linguagem de programa¸cão é revers´ıvel se todos os seus comandos podem ser executados na ordem reversa. Isto significa que um programa escrito em tal linguagem é capaz de ser revertido para qualquer ponto e ser executado novamente, toda mudan¸ca de estado de um programa pode ser desfeita. Este trabalho tem como propósito desenvolver um compilador para a linguagem revers´ıvel Janus. O compilador foi feito em Java, seus Analisadores Léxico e Sintático foram gerados a partir das bibliotecas JFlex e Java Cup. Palavras-chave: Compilador, Linguagem revers´ıvel

(8)

vii

Abstract

A command is reversible if it can be undone. A programming language is reversible if all of its commands are reversible and the control flow can be executed in inverse order. The goal of this work is develop a Compiler for Janus (a reversible programming language). This compiler was written in Java Language, using JFlex and Java Cup tools for generate Lexical and Syntactic Analyzers.

(9)

Sum´

ario

Resumo vi Abstract vii Lista de Tabelas xi 1 Introdu¸c˜ao 1 1.1 Compiladores . . . 1

1.2 Linguagem revers´ıvel Janus . . . 2

1.3 Objetivo . . . 2

1.4 Estrutura deste trabalho . . . 2

2 Compilador 4 2.1 Etapa de an´alise . . . 4

2.1.1 An´alise l´exica . . . 4

2.1.2 An´alise sint´atica . . . 7

2.1.3 An´alise semˆantica . . . 11

2.2 Etapa de s´ıntese do c´odigo . . . 12

2.2.1 Gera¸cão de código intermediário . . . 13

2.2.2 Otimiza¸c˜ao do c´odigo . . . 15

2.2.3 Gera¸c˜ao do c´odigo final . . . 16

3 A Linguagem Janus 19 3.1 Gram´atica . . . 20

3.2 Reverso de Instru¸c˜oes . . . 23

3.3 Estruturas de Controle . . . 24

3.3.1 Estrutura Condicional . . . 24

(10)

ix

3.3.2 Estrutura Iterativa . . . 25

4 Compilador para Linguagem Janus 26 4.1 Gerador do Analisador L´exico . . . 26

4.2 Gerador do Analisador Sint´atico . . . 26

4.3 Analisador Semˆantico . . . 27

4.3.1 Padr˜ao de projeto Visitor . . . 27

4.3.2 Tabela de s´ımbolos . . . 27

4.3.3 Verifica¸c˜ao de erros . . . 28

4.4 Gera¸c˜ao de c´odigo . . . 29

4.4.1 Representa¸c˜ao Intermedi´aria . . . 29

4.4.2 Assembly MIPS . . . 30

5 Conclus˜ao 31

(11)

Lista de Tabelas

2.1 Exemplos de tokens e lexemas . . . 5

2.2 Categorias e Tokens . . . 7

2.3 Regras de Produ¸c˜ao . . . 9

2.4 Passos do Algoritmo Empilha-Reduz . . . 10

2.5 Tipos de erros semˆanticos . . . 12

2.6 Nota¸c˜oes P´os-fixa e Infixa . . . 13

2.7 Instru¸c˜oes de Atribui¸c˜ao . . . 14

2.8 Instru¸c˜oes de Desvio . . . 14

2.9 Instru¸c˜oes de Invoca¸c˜ao de Rotina . . . 14

2.10 Instru¸c˜oes de Acesso Indexado . . . 14

2.11 Simplifica¸c˜ao alg´ebrica . . . 15

2.12 Elimina¸c˜ao de subexpress˜ao comum . . . 15

2.13 Propaga¸c˜ao de c´opia . . . 16

2.14 Elimina¸c˜ao de c´odigo morto . . . 16

2.15 Registradores MIPS . . . 17

2.16 Algumas instru¸c˜oes em Assembly MIPS . . . 18

3.1 Operadores aritm´eticos bin´arios . . . 21

3.2 Operadores l´ogicos bin´arios . . . 22

3.3 Operadores relacionais bin´arios . . . 22

3.4 Operadores un´arios . . . 22

3.5 Operadores de Modifica¸c˜ao e Swap . . . 23

3.6 Reverso de instru¸c˜oes . . . 23

3.7 Estrutura Condicional . . . 24

3.8 Estrutura Iterativa . . . 25

(12)

xi 4.1 Erros semˆanticos . . . 28 4.2 Instru¸c˜oes quadruplas . . . 29

(13)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Compiladores

O compilador é um software que lê um código-fonte escrito numa determinada linguagem de programa¸cão e o traduz para outro código que esteja escrito em outra linguagem ou em uma linguagem de máquina [4]. O caso mais comum é a conversão de um código em linguagem de programa¸cão de alto n´ıvel para um código em linguagem de baixo n´ıvel ou linguagem de máquina. O código produzido pelo processo de compila¸cão é chamado de código-objeto.

O compilador pode ser dividido em duas partes: a de análise e a de s´ıntese. A parte de análise é constitu´ıda pelas análises léxica, sintática e semântica e a parte de s´ıntese é formada pela gera¸cão de código intermediário, otimiza¸cão do código e a gera¸cão do c´ odigo-objeto. A parte de análise e a de s´ıntese também podem ser chamadas, respectivamente, de front-end e back-end. A compila¸cão come¸ca com o Analisador Léxico (também cha-mado de Scanner), que lê o código-fonte, eliminando comentários e espa¸cos desnecessários e separando e classificando os termos numa sequência de unidades significativas chamadas de tokens. Após esta fase, é a vez do Analisador Sintático (também chamado de Par-ser), que tem como objetivo avaliar se a sequência de tokens está organizada obedecendo uma gramática formal associada à linguagem. O processo de análise sintática produz uma árvore de acordo com a aplica¸cão desta gramática, denominada árvore sintática. E encerrando o processo de análise, o Analisador Semântico entra em a¸cão para garantir se as regras semânticas estão sendo respeitadas, como por exemplo, se as variáveis que estão sendo utilizadas foram declaradas, se os tipos de dados são compat´ıveis com a

(14)

2 ra¸cão, se não tem diferentes variáveis com o mesmo identificador e etc. Após a análise da corretude do código-fonte, é feita a gera¸cão do código-objeto da linguagem alvo, sendo que comumente, os compiladores geram um código intermediário antes disso. Há também uma etapa de otimiza¸cão, de forma que o programa possa ser executado mais rapidamente ou ocupe menos espa¸co. Este processo pode ser feito em qualquer etapa da compila¸cão, inclusive na etapa de análise, mas costuma ser aplicado no código intermediário ou no código-objeto [4].

1.2 Linguagem revers´ıvel Janus

A linguagem revers´ıvel Janus, proposta por Lutz e Derby [5] e descrita de forma mais completa por [7], é uma linguagem simples, porém poderosa o suficiente para de-senvolver algoritmos complexos [6] e suas constru¸cões podem servir como modelo para o desenvolvimento de outras linguagens revers´ıveis. Todas as instru¸cões aceitas por sua estrutura têm a sua versão reversa (instru¸cões capazes de recuperar um estado anterior do programa revers´ıvel) o que classifica esta linguagem como revers´ıvel, diferente das lin-guagens tradicionais que são uma combina¸cão de constru¸cões revers´ıveis e irrevers´ıveis. Plataformas revers´ıveis podem prover uma execu¸cão revers´ıvel para um programa irre-vers´ıvel, mas isso seria muito custoso (sobrecarga na memória e aumento do tempo de execu¸cão). Caso o mesmo programa fosse escrito numa linguagem revers´ıvel sua execu¸cão seria menos custosa [6].

1.3 Objetivo

Este trabalho tem como objetivo desenvolver um compilador para linguagem re-vers´ıvel Janus, que inclui a implementa¸cão de todas as etapas da fase de análise: análises léxica, sintática e semântica, e também, as etapas da fase de s´ıntese: gera¸cão de código intermediário e gera¸cão do código final.

1.4 Estrutura deste trabalho

No Cap´ıtulo 2 as etapas de análise e s´ıntese são explicadas detalhamente. As fun-¸cões, os erros e exemplos sobre as análises léxicas, sintática e semântica são apresentadas

(15)

3 na parte de análise. Os detalhes sobre gera¸cão do código intermediário, sua otimiza¸cão e a gera¸cão do código final são mostradas na parte de s´ıntese. No Cap´ıtulo 3 são apresentados a fundo aspectos importantes da linguagem Janus, desde a sua gramática até suas estru-turas e instru¸cões reversas. No Cap´ıtulo 4 são descritos detalhes sobre a implementa¸cão do compilador para a linguagem revers´ıvel Janus, desde a análise léxica até a gera¸cão de código. No Cap´ıtulo 5 são apresentadas as conclusões deste trabalho.

(16)

Cap´ıtulo 2

Compilador

Neste cap´ıtulo será apresentado o processo de compila¸cão que é dividido em duas fases: análise e s´ıntese. A fase de análise possui três etapas: análise léxica, análise sintática e análise semântica. Nas primeiras se¸cões, caracter´ısticas de cada uma das análises são descritas, como fun¸cões, erros e exemplos. Após as se¸cões de análise, temos as de s´ıntese que tem o foco na gera¸cão do código, nela são encontrados os tópicos: gera¸cão de código intermediário, otimiza¸cão do código e gera¸cão do código final.

2.1 Etapa de an´

alise

Nesta se¸cão serão apresentadas as etapas que compõem a primeira fase do processo de compila¸cão, partindo da análise léxica e terminando na análise semântica.

2.1.1 An´

alise l´

exica

Dentre as fases do processo de compila¸cão, o Analisador Léxico (ou Scanner) é a primeira fase. O seu objetivo é simples: ler os caracteres do arquivo-fonte, agrupando-os em unidades significativas de acordo com padrões pré-definidos e descartando caracteres que não são relevantes para a linguagem alvo, como por exemplo, comentários, espa¸cos, caracteres de fim de linha ou fim de arquivo entre outros. Esta sequência de caracte-res agrupados segundo algum padrão é chamada de lexema. Cada padrão determina uma categoria usada pelo Analisador Sintático. Por isso, o Analisador Léxico poderia trabalhar como uma sub-rotina ou co-rotina do Parser, passando para o mesmo o par hcategoria, lexemai, denominado token. Se o Analisador Léxico for executado antes do

(17)

5 Analisador Sintático, ele transforma o código-fonte numa sequência de tokens, para ser lida pelo Analisador Sintático. Alguns tokens estão associados a um único lexema. De acordo com a tabela 2.1, por exemplo, ‘+’ está associado à categoria PLUS, formando o token hPLUS, +i. Para outros tokens, há vários lexemas que satisfazem o padrão da categoria, por exemplo, ‘123’ e ‘234’ ambas sequências satisfazem a categoria num.

Categoria Padr˜ao Lexema Token

if Sequˆencia de caracteres for-mada por i,f

If, iF, IF, if hif , if i

id Sequência de caracteres e digitos numéricos que segue a expressão regular: [a-zA-Z][a-zA-Z0-9]*

A,Aa,aA,AA,aa,Aab,... hid, Ai, hid, Aai

for Sequˆencia de caracteres for-mada por f,o,r

For,FOr,FOR, foR, fOR, fOr, for, FoR

hfor, f ori

num Sequˆencia de d´ıgitos num´ e-ricos que segue a express˜ao regular: [0-9]+

1, 12, 123, 234,... hnum, 12i,

hnum, 234i

PLUS [+] + hPLUS, +i

Tabela 2.1: Exemplos de tokens e lexemas

Há sequências que satisfazem padrões de categorias diferentes. Por exemplo, a sequência ‘if’, na tabela 2.1 pode estar associada ao token hif , if i ou ao token hid, if i. Ou-tro tipo de ambiguidade na cria¸cão dos tokens é quanto ao término do lexema. Por exem-plo, a sequência de entrada ‘123’, pode ser classificada como {hnum, 123i} ou {hnum, 12i, hnum, 3i}. Para resolver estas ambiguidades, o Analisador Léxico precisa usar regras de escolha na produ¸cão dos tokens. Por exemplo, dar preferência a classificar um lexema como uma palavra reservada em vez de identificador (como é o caso do if), e tentar mon-tar o lexema com o maior tamanho dentre as poss´ıveis categorias (como é o caso do número 123).

(18)

6 2.1.1.1 Erros l´exicos

Ao tentar montar a sequência de tokens, há lexemas que podem não satisfazer nenhum padrão. Por exemplo, a sequência ‘123ab’ pode não corresponder a nenhuma categoria. Nesta situa¸cão, o Analisador Léxico informa o tipo de erro e onde este caractere se encontra.

Mas o Analisador Léxico não consegue encontrar erros de digita¸cão, como por exemplo: whyle(x == 3). O correto nesse caso seria ‘while’, mas como nesta etapa, cada sequência de caracteres é classificada independentemente dos outros lexemas, esta sequência ‘whyle’ formaria o token hid, whylei.

2.1.1.2 Exemplo de an´alise l´exica

Para ilustrar como funciona a análise léxica, mostramos um exemplo de programa (Algoritmo 1) e em seguida, como pode ser feita a análise léxica.

Algoritmo 1 Um exemplo de programa x = 10

while x 6= 0 do x = x − 1 end while

A entrada do Analisador L´exico ´e dividida em unidades e pode ser demonstrada no seguinte exemplo:

|x| |=| |10| \n |while| |x| |6=| |0| |do| \n |x| |=| |x| |-| |1| \n |end| |while| |<EOF>|

As cadeias de caracteres encontradas no código-fonte são avaliadas para verificar com qual padrão se encaixam. Caso não combine com nenhum padrão, a cadeia não é reconhecida e um erro ocorre. Na tabela 2.2 são apresentados os tokens de acordo com a sua categoria.

(19)

7

Categoria Padr˜ao Token

atrib “=” hatrib, =i

while “while” hwhile, whilei

do “do” hdo, doi

end “end” hend, endi

operadorDif “6=” hoperadorDif,6=i

operadorSub “-” hoperadorSub, −i

id [a-zA-Z][a-zA-Z0-9]* hid, xi

for “for” hfor, f ori

num [0-9]+ hnum, 10i,

hnum, 1i, hnum, 0i Tabela 2.2: Categorias e Tokens

2.1.2 An´

alise sint´

atica

A segunda fase do processo de compila¸cão é realizada pelo Analisador Sintático (ou Parser ). O papel deste analisador é: avaliar se a sequência de tokens recebida do Scanner pode ser gerada através da gramática formal da linguagem alvo e construir uma ´

arvore gramatical correspondente a esta sequˆencia.

A gramática possui um conjunto de regras que define a estrutura da linguagem. Estas regras são chamadas de regras de produ¸cão (ou apenas de produ¸cão) e são regras de reescrita que possibilitam a substitui¸cão de s´ımbolos para gerar novas sequências. Estas regras são compostas por dois tipos de s´ımbolos: os terminais, que são caracteres literais que não podem ser substitu´ıdos, e os não terminais, que podem ser substitu´ıdos. O uso destas regras gera cadeias de caracteres, este processo é denominado deriva¸cão. A deriva¸cão é uma opera¸cão de substitui¸cão de um s´ımbolo não terminal por s´ımbolos terminais e não terminais, os s´ımbolos que ocupam a posi¸cão do não terminal fazem parte de uma regra de produ¸cão que possui o s´ımbolo não terminal à esquerda e à direita os s´ımbolos que ele produz. A deriva¸cão que substitui os s´ımbolos da direita para a esquerda é denominada de deriva¸cão mais à direita e a que substitui da esquerda para a direita é deriva¸cão mais à esquerda.

(20)

8 Uma gramática é dita amb´ıgua caso uma cadeia de caracteres gerada através de suas regras possua mais de uma deriva¸cão mais à esquerda ou mais à direita. A árvore gramatical (ou árvore sintática) é uma representa¸cão gráfica para uma deriva¸cão, os seus nós internos são os s´ımbolos não terminais e as suas folhas os terminais. Numa gramática que não é amb´ıgua as sequências de caracteres geradas por ela possuem uma única árvore gramatical.

Existem vários poss´ıveis métodos de análise sintática, mas em geral segue uma abordagem Top-down ou Bottom-up. Um método Bottom-up tenta construir uma árvore gramatical para uma sequência de tokens come¸cando das folhas e finalizando na raiz. Nesse caso, uma sequência de tokens é decomposta até que o s´ımbolo inicial da gramática seja alcan¸cado, ou seja, seria como se todos os passos de uma deriva¸cão fossem desfeitos, esse processo é denominado redu¸cão. Para encontrar estas redu¸cões, o compilador dispõe do algoritmo empilha-reduz. Nele existem duas opera¸cões, uma responsável por empilhar um token e outra por desempilhar s´ımbolos terminais e empilhar não terminais, que são chamadas, respectivamente, de Avan¸car e Reduzir. A abordagem Top-down realiza uma deriva¸cão mais à esquerda de uma sequência de tokens a partir do s´ımbolo inicial da gramática. A árvore gramatical desta sequência é constru´ıda da raiz até as folhas.

2.1.2.1 Erros sint´aticos

Os erros nessa fase estão ligados às constru¸cões no código que burlam as regras que definem a estrutura da linguagem. Para ilustrar alguns erros, mostramos um exemplo de um programa (Algoritmo 2) e em seguida uma descri¸cão sobre seus erros.

Algoritmo 2 Um exemplo de programa com erros sint´aticos x = 10

if x = 1; then x == 10 end if

Suponha que a linguagem do Algoritmo 2 obrigue o uso do s´ımbolo “;” para marcar o fim de uma instru¸cão. O código acima possui três erros sintáticos: na primeira linha, a instru¸cão não possui o “;” (o correto seria “x = 10;”) , na estrutura condicional “x = 1;” não representa uma expressão lógica e no interior do bloco desta estrutura, não são admitidas expressões do tipo “x == 10” (este erro seria corrigido caso as posi¸cões das

(21)

9 instru¸cões fossem trocadas). O erro detectado no Algoritmo 2 foi encontrado através do processo de parser, que será ilustrado na se¸cão 2.1.2.2 em outro exemplo.

2.1.2.2 Exemplo de an´alise sint´atica

Para ilustrar como funciona a análise sintática usando a abordagem Bottom-up, duas tabelas especificando as regras de produ¸cão (Tabela 2.3) e os passos do algoritmo empilha-reduz (Tabela 2.4) e um desenho da árvore sintática (Figura 2.1) da sequência de tokens que foi reduzida são apresentados a seguir.

0 Goal → Expr

1 Expr → Expr + Term 2 Expr → Expr - Term 3 Expr → Term

4 Term → Term * Factor 5 Term → Term / Factor 6 Term → Factor

7 Factor → num 8 Factor → id 9 Factor → ( Expr )

Tabela 2.3: Regras de Produ¸c˜ao

A sequência de tokens utilizada na tabela 2.4 é x - 2 * y. A primeira coluna da tabela 2.4 representa a pilha onde os s´ımbolos são inseridos e também são removidos quando reduzidos a um s´ımbolo não terminal (neste caso, o s´ımbolo não terminal substitui os que foram removidos na pilha), na segunda coluna estão os s´ımbolos da sequência que ainda não foram analisados, a terceira coluna representa o handle que é um par h regra de produ¸cão, posi¸cão da subcadeia i que indica a posi¸cão da subcadeia na sequência de tokens e a regra de produ¸cão que será utilizada na redu¸cão dessa subcadeia e a quarta coluna representa a a¸cão que pode ser de avan¸co ou de redu¸cão.

(22)

10

Pilha Entrada Handle A¸c˜ao

$ id - num * id - avan¸ca

$id - num * id 8,1 reduz a 8

$Factor - num * id 6,1 reduz a 6

$Term - num * id 3,1 reduz a 3

$Expr - num * id - avan¸ca

$Expr - num * id 7,3 reduz a 7

$Expr - Factor * id 7,3 reduz a 6

$Expr - Term * id - avan¸ca

$Expr - Term * id 8,5 reduz a 8

$Expr - Term * Factor 4,5 reduz a 4

$Expr - Term 2,3 reduz a 2

$Expr 0,1 reduz a 0

$Goal - aceita

Tabela 2.4: Passos do Algoritmo Empilha-Reduz

Na figura 2.1 a árvore sintática da sequência de tokens desse exemplo é ilustrada. Como a abordagem é Bottom-up esta árvore foi constru´ıda das folhas até a sua raiz.

(23)

11

2.1.3 An´

alise semˆ

antica

A análise semântica é responsável pela verifica¸cão de caracter´ısticas relacionadas ao significado da instru¸cão. O Analisador Semântico faz uso da árvore sintática e da tabela de s´ımbolos para realizar a análise semântica.

Algumas regras são imposs´ıveis de serem representadas nas etapas anteriores de análise léxica e sintática. Exemplos destas regras são: toda variável deve ser declarada antes de ser utilizada, o operador deve estar relacionado a operandos de tipos compat´ıveis com a opera¸cão, entre outras.

2.1.3.1 Tabela de S´ımbolos

A tabela de s´ımbolos é uma estrutura de dados responsável por armazenar todos os dados de um determinado identificador. Na verifica¸cão semântica das declara¸cões de variáveis, fun¸cões e tipos, os nomes declarados são inseridos na tabela de s´ımbolos.

Essa tabela associa atributos aos nomes definidos pelo programador, como por exemplo, tipo, escopo, limites para vetores e números de parâmetros para fun¸cões. A consulta a esta tabela é realizada no momento da verifica¸cão do uso desses nomes.

2.1.3.2 Principais erros semˆanticos

Durante a análise semântica é verificado se o código está respeitando algumas regras semânticas. Algumas destas regras são:

Compatibilidade de tipos : O tipo de dado atribu´ıdo a uma determinada vari´avel deve ser compat´ıvel com o tipo da mesma.

Escopo dos identificadores : Variáveis e fun¸cões devem estar declaradas em locais que podem ser acessados onde esses identificadores estão sendo utilizados.

Unicidade de nomes de identificadores : Os identificadores devem ser únicos. Na tabela 2.5 temos exemplos para cada um dos três tipos de erros semânticos.

(24)

12

Tipo Erro

Compatibilidade de tipos int x; x = “teste”; Escopo dos identificadores int func(int y) {

int x = y; return x; } int main() { int z; z = x; }

Unicidade de identificadores int x = 3; int x = 4; int soma;

int func(int x, int y) { x = x + y;

return x; }

Tabela 2.5: Tipos de erros semˆanticos

Na Tabela 2.5 são apresentados trechos de código que desrespeitam as regras se-mânticas. O primeiro código apresenta um erro que desrespeita a regra de compatibilidade de tipos, pois tenta atribuir uma cadeia de caracteres a uma variável do tipo inteiro. O segundo código burla a regra de escopo dos identificadores, pois tenta usar uma variável definida fora do escopo de uma fun¸cão. E o terceiro código desrespeita a regra de unici-dade de identificadores, pois no código são definidas mais de uma variável com o mesmo identificador.

2.2 Etapa de s´ıntese do c´

odigo

Após a análise da corretude do código-fonte, a etapa de s´ıntese do código é alcan-¸cada. Esta etapa é dividida em três partes: gera¸cão do código intermediário, otimiza¸cão

(25)

13 do código e gera¸cão do código final.

2.2.1 Gera¸

c˜

ao de c´

odigo intermedi´

ario

A representa¸cão intermediária pode ser através do uso da nota¸cão pós-fixa, por uma árvore sintática ou por um código de três endere¸cos.

A nota¸cão pós-fixada é adotada na representa¸cão de expressões aritméticas e l´ ogi-cas. As expressões aritméticas escritas na forma convencional estão em nota¸cão infixada, pois os operadores ficam entre os operandos. Mas para o compilador gerar corretamente o código de máquina, as expressões são reorganizadas em nota¸cão pós-fixada, a qual cada operador aparece após seus operandos. A tabela 2.6 mostra a diferen¸ca entre as duas formas de representa¸cão de expressões aritméticas/lógicas.

Nota¸c˜ao Exemplo

Infixada A*B/C

P´os-fixada AB*C/

Tabela 2.6: Nota¸c˜oes P´os-fixa e Infixa

Como os operadores possuem diferentes ordens de prioridade, o uso da nota¸cão infixada não é o ideal para a representa¸cão de expressões, pois não define qual opera¸cão deve ser realizada antes das demais que estão numa mesma expressão.

A árvore sintática é uma outra forma de representa¸cão intermediária gerada na etapa da análise sintática como foi explicado na se¸cão anterior.

O código de três endere¸cos é uma representa¸cão mais próxima da estrutura da linguagem Assembly, o que facilita no momento da conversão para esta linguagem. Numa instru¸cão podem ser encontradas no máximo três variáveis: duas para operadores binários e uma para o resultado. Com isso, qualquer tipo de opera¸cão binária pode ser represen-tada. Os seus tipos básicos de instru¸cões são: expressões de atribui¸cão, desvios, invoca¸cão de rotinas e acesso indexado.

Existem três tipos de instru¸cões de atribui¸cão: opera¸cão binária, opera¸cão unária e cópia. Na tabela 2.7 exemplos das três opera¸cões são ilustrados.

(26)

14

Tipo Instru¸c˜ao

Opera¸cão Binária x := y op z Opera¸cão Unária x := op y

C´opia x := y

Tabela 2.7: Instru¸c˜oes de Atribui¸c˜ao

Existem dois tipos de instru¸c˜oes de desvio: desvio incondicional e o desvio condi-cional. Na tabela 2.8 temos exemplos dos dois tipos de desvios.

Tipo Instru¸c˜ao

Desvio condicional if x op y goto L Desvio Incondicional goto L

Tabela 2.8: Instru¸c˜oes de Desvio

A invoca¸cão de rotinas ocorre em duas etapas. Inicialmente, os argumentos do procedimento são registrados na instru¸cão param, após isso, a instru¸cão call completa o processo de invoca¸cão da rotina. Na tabela 2.9 as instru¸cões usadas na invoca¸cão de uma rotina são ilustradas.

Tipo Instru¸c˜ao

Registro de argumento param x

Invoca¸cão da rotina t1 := call nome, NUMPARAMS Tabela 2.9: Instru¸cões de Invoca¸cão de Rotina

Existem duas formas de representar o acesso indexado que est˜ao representadas na tabela 2.10.

Tipo Instru¸c˜ao

Acesso Indexado x := y[i] Acesso Indexado y[i] := x

(27)

15

2.2.2 Otimiza¸

c˜

ao do c´

odigo

Nessa etapa são detectadas instru¸cões ineficientes no código e são aplicadas es-tratégias espec´ıficas para cada situa¸cão encontrada nelas, assim, reduzindo a ineficiência do código. A seguir as estratégias: Simplifica¸cão algébrica, Elimina¸cão de subexpressão comum, Propaga¸cão de cópia e Elimina¸cão de código morto são definidas e exemplificadas. Na Simplifica¸cão algébrica, as instru¸cões podem ser removidas ou simplificadas. Aquelas instru¸cões cuja execu¸cão não afeta em nada o programa são removidas, além destas, existem instru¸cões cuja execu¸cão se torna mais eficiente caso o tipo de opera¸cão que ela deseja executar seja representada de uma forma que torne a sua execu¸cão menos custosa para o computador. A tabela 2.11 mostra um exemplo.

A¸c˜ao Instru¸c˜oes Efeito

Elimina¸cão x := x + 0 x := x * 1 {vazio} {vazio} Simplifica¸cão x := x * 0 y := y ** 2 x := x * 8 x := 0 y := y * y x := x << 3 Tabela 2.11: Simplifica¸cão algébrica

Na Elimina¸cão de subexpressão comum, algumas instru¸cões são simplificadas al-terando o lado direito delas que possuem opera¸cões que foram executadas anteriormente por outra. Esta altera¸cão é a troca da expressão, que representa a opera¸cão, pela variável que anteriormente recebeu o resultado da mesma opera¸cão, transformando esta instru¸cão em uma atribui¸cão simples. Mas, para que isso funcione corretamente, a variável que foi posta no lugar da expressão não pode ter alterado seu conteúdo. A tabela 2.12 mostra um exemplo.

Instru¸c˜oes Efeito x := y + z .. . w := y + z x := y + z .. . w := x

(28)

16 Na Propaga¸cão de cópia, caso exista uma instru¸cão do formato x := y, usos de x após esta instru¸cão podem ser substitu´ıdos por y. A tabela 2.13 mostra um exemplo.

Instru¸cões Efeito b := z + y a := b x := 2 * a b := z + y a := b x := 2 * b Tabela 2.13: Propaga¸cão de cópia

Na Elimina¸cão de código morto, uma instru¸cão que não aparece em qualquer ou-tro lugar no programa e não afeta no funcionamento do mesmo, está morta e pode ser removida. A tabela 2.14 mostra um exemplo.

Instru¸c˜oes Efeito b := z + y a := b x := 2 * a b := z + y {vazio} x := 2 * b

Tabela 2.14: Elimina¸c˜ao de c´odigo morto

Embora a ideia de possuir um código otimizado seja interessante, na prática, nem sempre é mais conveniente implementar o melhor otimizador poss´ıvel. Os motivos são: algumas modifica¸cões são dif´ıceis de implementar, algumas são custosas ao tempo de com-pila¸cão e algumas tem benef´ıcio pequeno e muitas sofrem dos três problemas anteriores. O objetivo, então, seria encontrar um otimizador que traga benef´ıcios com um custo baixo.

2.2.3 Gera¸

c˜

ao do c´

odigo final

Após a gera¸cão do código intermediário e a sua otimiza¸cão, chegamos a última etapa que é a gera¸cão do código final. Nesse projeto o código final é em Assembly MIPS, cada um dos seus 32 registradores são mostrados na tabela 2.15.

(29)

17

Nome Descri¸c˜ao

$zero Retorna o valor 0.

$at (Assembler Temporary) Reservado pelo assembler.

$v0-$v1 Valores das expressões de avalia¸cão e resultados de fun¸cão. $a0-$a3 Primeiros quatro parâmetros para subrotinas.

$t0-$t9 (Temporários) Temporários para quem chama as subrotinas. $s0-$s7 (Temporários) Temporários para subrotinas.

$k0-$k1 Reservados para uso do tratamento de interrup¸c˜ao.

$gp (Global Pointer)

$sp (Stack Pointer) Aponta para o topo da pilha

$s8-$fp (Saved Values/ Frame Pointer) Preservado na chamada de proce-dures.

$ra (Return Adress)

$f0 Recebe o retorno de floats em fun¸c˜oes. $f12/$f14 Usados para passar floats para fun¸c˜oes. ($f12,$f13)

($f14,$f15)

Usados em conjunto para passar doubles para fun¸c˜oes.

Tabela 2.15: Registradores MIPS

As instru¸cões são de 32 bits e as palavras tem 4 bytes. Um inteiro ocupa uma palavra na memória. Além disso, podem ser manipulados 32 registradores.

A tabela 2.16 mostra algumas instru¸c˜oes em Assembly MIPS e seus respectivos significados.

(30)

18

Tipo Instru¸c˜oes Significado

Aritmética add reg1, reg1, reg2 reg1 := reg1 + reg2 Aritmética sub reg1, reg1, reg2 reg1 := reg1 - reg2 Lógica and reg1, reg1, reg2 reg1 := reg1 && reg2

L´ogica or reg1, reg1, reg2 reg1 := reg1 || reg2

Movimenta¸c˜ao move reg1, reg2 reg1 := reg2

Desvio Incond. j label goto label

Desvio cond. beq reg1, reg2, label if reg1 = reg2 goto label Tabela 2.16: Algumas instru¸c˜oes em Assembly MIPS

O Algoritmo 3 ´e a implementa¸c˜ao do Algoritmo 1 em Assembly MIPS.

Algoritmo 3 Algoritmo 1 em Assembly MIPS .data x: .word 10 .text L0: lw $t0, x L1: beq $t0, $zero, L2 subi $t0, $t0, 1 j L1 L2: sw $t0, x

(31)

Cap´ıtulo 3

A Linguagem Janus

Uma linguagem de programa¸cão revers´ıvel produz código que pode ser interrompido em qualquer ponto, revertido para qualquer ponto e executado novamente. As linguagens tradicionais possuem uma mistura de constru¸cões revers´ıveis e irrevers´ıveis, ou seja, seus programas podem ou não ser revers´ıveis dependendo da constru¸cão utilizada em sua im-plementa¸cão. Um programa irrevers´ıvel pode ser executado reversivelmente com o uso de plataformas revers´ıveis, que simulariam tal execu¸cão, mas isso aumentaria o tempo de execu¸cão e sobrecarregaria a memória. Linguagens revers´ıveis possuem apenas constru-¸cões revers´ıveis o que eliminaria esta sobrecarga na memória e o aumento no tempo de execu¸cão devido a reversibilidade.

A linguagem Janus [5] é imperativa, estruturada e revers´ıvel. Por ser revers´ıvel, todas as altera¸cões realizadas sobre o estado de um programa podem ser desfeitas, as-sim voltando a um estado anterior. Janus é uma linguagem simples, porém poderosa o suficiente para desenvolver algoritmos complexos e suas constru¸cões podem servir como modelo para o desenvolvimento de outras linguagens revers´ıveis.

Todas as suas variáveis são globais e do tipo inteiro. Nenhum outro tipo de dados (como ponto flutuante ou string) é suportado. Embora isso simplifique a linguagem em rela¸cão a completude e reversibilidade, são necessários mais tipos para fins mais práticos em muitas aplica¸cões.

(32)

20

3.1 Gram´

atica

Uma gramática formal é um conjunto de regras de produ¸cão de cadeias em uma linguagem formal. A partir dessas regras, podemos verificar se uma sequência de caracteres oriunda de um código-fonte segue as regras da gramática da linguagem alvo. Gramáticas de linguagens formais podem ser representadas através de um código chamado EBNF que é composto por s´ımbolos terminais, não-terminais e regras de produ¸cão.

A seguir temos a gram´atica da linguagem Janus escrita na nota¸c˜ao EBNF.

Program ::= { ident [ ‘[’ num ‘]’ ] }*

{ ‘PROCEDURE’ ident Statements }* Statements ::= Ifstmt Statements

Ifstmt ::= ‘IF’ Expression

| [ ‘THEN’ Statements ] | [ ‘ELSE’ Statements ] | ‘FI’ Expression

Dostmt ::= ‘FROM’ Expression | [‘DO’ Statements] | [‘LOOP’ Statements] | ‘UNTIL’ Expression Callstmt ::= ‘CALL’ ident

| ‘UNCALL’ ident Readstmt ::= ‘READ’ ident Writestmt ::= ‘WRITE’ ident Lvalstmt ::= Lvalue Modstmt

(33)

21 Modstmt ::= ‘+=’ Expression | ‘-=’ Expression | ‘!=’ Expression Swapstmt ::= ‘:’ Lvalue Expression ::= Minexp

{ }* Indica zero ou mais repeti¸cões , [ ] indica zero ou uma repeti¸cão e os s´ımbolos terminais estão entre aspas simples.

Os identificadores, representados por ident na gramática, são formados por qual-quer sequência de letras que não constituem uma palavra reservada. Os números, repre-sentados por num na gramática, são formados por qualquer sequência de d´ıgitos decimais. Na linguagem Janus são encontrados os operadores binários e unários que esta-mos acostumados a ver nas linguagens tradicionais. A tabela 3.1 esta-mostra os operadores aritméticos binários da linguagem.

Nome S´ımbolo Soma + Subtra¸cão -Multiplica¸cão * Divisão / Resto \

(34)

22 A tabela 3.2 mostra os operadores l´ogicos bin´arios da linguagem.

Nome S´ımbolo

XOR !

OR |

AND &

Tabela 3.2: Operadores l´ogicos bin´arios

A tabela 3.3 mostra os operadores relacionais bin´arios da linguagem.

Nome S´ımbolo Menor que < Maior que > Igual = Diferente # Menor ou igual a <= Maior ou igual a >=

Tabela 3.3: Operadores relacionais bin´arios

Além dos operadores binários, também existem os unários que estão representados na tabela 3.4.

Nome S´ımbolo

NOT ~

Negativo

-Tabela 3.4: Operadores un´arios

Além dos operadores binários e unários, existem os operadores de modifica¸cão e o de Swap que são os únicos capazes de trocar valores de variáveis. Os operadores de modifica¸cão avaliam a expressão à direita e modificam a variável à esquerda de acordo com o operador. O operador += adiciona a expressão na variável, -= subtrai e != aplica a opera¸cão lógica XOR. O operador Swap troca os valores das variáveis à esquerda e à direita. Estes operadores estão representados na tabela 3.5.

(35)

23 Nome S´ımbolo Operadores de Modifica¸c˜ao += -= != Operador Swap :

Tabela 3.5: Operadores de Modifica¸c˜ao e Swap

3.2 Reverso de Instru¸

c˜

oes

Para que cada parte do programa possa ser executada de forma reversa, é necessário que cada instru¸cão possua sua equivalente na forma reversa. A tabela 3.6 mostra a instru¸cão e seu reverso.

Instru¸c˜ao Reverso

var != expression var != expression

a : b a : b

READ name WRITE name

WRITE name READ name

S1 S1−1 IF e1 THEN S1 ELSE S2 FI e2 IF e2 THEN S₁−1 ELSE S₂−1 FI e1 FROM e1 DO S1 LOOP S2 UNTIL e2 FROM e2 DO S₁−1 LOOP S₂−1 UNTIL e1

CALL procedureName UNCALL procedureName

var += expression var -= expression

var -= expression var += expression

(36)

24 Um procedimento pode ser executado no sentido progressivo através da instru-¸cão CALL e no sentido reverso pela instru¸cão UNCALL. A dire¸cão de execu¸cão de um procedimento pode ser alternada cada vez que UNCALL é usado.

A instru¸cão READ troca o valor de uma variável por um valor inserido pelo usuário e a instru¸cão WRITE mostra o valor de uma variável. Um procedimento que possua uma instru¸cão READ, quando executado no sentido reverso esta instru¸cão se torna uma instru¸cão WRITE e vice-versa.

3.3 Estruturas de Controle

A Linguagem Janus, assim como a maior parte das linguagens imperativas, possui estruturas de desvio condicional e de repeti¸c˜ao.

3.3.1 Estrutura Condicional

FORWARD REVERSE IF e1 THEN S1 ELSE S2 FI e2 IF e2 THEN S₁−1 ELSE S₂−1 FI e1

Tabela 3.7: Estrutura Condicional

A estrutura condicional da linguagem Janus mostrada na tabela 3.7 ´e semelhante `

as estruturas de linguagens convencionais, a única diferen¸ca é o acréscimo da expressão lógica no fim. A expressão lógica que está após FI e a que está após o IF devem ter o mesmo valor-verdade. Caso contrário, um erro ocorrerá e o programa será abortado. Quando a expressão lógica e1 for verdadeira, todos os comandos que fazem parte de S1, que estão após o THEN, são executados, ao terminar de executar a última instru¸cão nesse trecho, é verificado o valor-verdade da expressão lógica e2 que está após o FI e que deve ser igual ao valor-verdade de e1. As estruturas definidas como FORWARD e REVERSE, as quais foram representadas no código acima, definem o padrão seguido para reverter às modifica¸cões realizadas no estado do programa. Todos os comandos que fazem parte de

(37)

25 S1 e S2 são revertidos e sua nova versão é representada por S1−1 e S

−1

2 . Além disso, as expressões lógicas que estão após IF e FI são trocadas.

3.3.2 Estrutura Iterativa

FORWARD REVERSE FROM e1 DO S1 LOOP S2 UNTIL e2 FROM e2 DO S₁−1 LOOP S₂−1 UNTIL e1 Tabela 3.8: Estrutura Iterativa

A estrutura iterativa mostrada na tabela 3.8 tem um funcionamento diferente das demais estruturas encontradas em linguagens convencionais. Seu funcionamento ´e descrito da seguinte maneira:

1. Avalia a expressão lógica e1 de FROM. Se for verdadeira, avan¸ca para o segundo passo. Senão, aborta o programa.

2. Executa os comandos de S1 de DO e avan¸ca para o terceiro passo.

3. Avalia a expressão lógica e2 de UNTIL. Se for verdadeira, sai da estrutura iterativa. Senão, avan¸ca para o quarto passo.

4. Executa os comandos de S2 de LOOP e avan¸ca para o quinto passo.

5. Avalia novamente a expressão lógica e1 de FROM e verifica se o seu valor-verdade corresponde ao valor-verdade da expressão lógica e2 de UNTIL. Se for igual, retorna ao segundo passo. Senão, aborta o programa.

As modifica¸cões realizadas na estrutura REVERSE são semelhantes às que ocor-reram no caso da estrutura condicional. As expressões lógicas que estão após o FROM e o UNTIL são trocadas, isto é, a expressão e1 ficará após o UNTIL e a expressão e2 após o FROM. As instru¸cões que fazem parte de S1 e S2 também são alteradas, suas novas versões representadas por S₁−1 e S₂−1 estão no código REVERSE.

(38)

Cap´ıtulo 4

Compilador para Linguagem Janus

Conforme foi comentado anteriormente, o compilador foi feito em Java, na versão 1.8.0 131. Para construir o Analisador Léxico, foi usado o JFlex e para o Analisador Sintático foi utilizado o Java Cup, conforme será explicado nas próximas se¸cões. Nas se¸cões seguintes, são descritas as etapas de Análise Semântica e Gera¸cão de Código.

A implementa¸c˜ao deste compilador pode ser encontrada no link: https://github.com/vbrum/JanusCompiler .

4.1 Gerador do Analisador L´

exico

O Analisador Léxico foi constru´ıdo com o aux´ılio do JFlex [2], versão 1.6.1, que é uma biblioteca geradora de Analisador Léxico. Para constru´ı-lo recebe como entrada uma especifica¸cão de um conjunto de expressões regulares e a¸cões, que gera um programa, conhecido como Scanner, que lê a entrada, combina as entradas com as expressões regu-lares especificadas no arquivo que possui extensão lex, e executa as a¸cões correspondentes `

a express˜ao regular combinada.

4.2 Gerador do Analisador Sint´

atico

O Analisador Sintático foi gerado pela biblioteca Java Cup [1], versão 11a. A forma de lidar com o Java Cup é análoga a do JFlex. Um LALR Parser é gerado através dessa biblioteca a partir de informa¸cões encontradas num arquivo de extensão cup. Nesse arquivo podem ser inseridas várias informa¸cões relevantes para a cria¸cão do Parser, como

(39)

27 importa¸cões de classes, trechos de códigos implementados pelo usuário para incluir alguma funcionalidade, defini¸cão dos s´ımbolos terminais e não terminais, e, por fim, as regras de produ¸cão da linguagem e suas a¸cões semânticas.

Após a execu¸cão do arquivo cup, dois arquivos são gerados. A classe responsável pelo Parser e outra contendo os s´ımbolos terminais e contantes relacionadas a eles.

4.3 Analisador Semˆ

antico

Após a constru¸cão bem sucedida da árvore sintática, o processo de compila¸cão de um programa na linguagem Janus chega a uma nova etapa, a qual é responsável pela análise semântica do programa. A estrutura da árvore sintática é acessada diversas vezes nessa parte, cada acesso realizado tem como objetivo uma diferente funcionalidade da análise semântica.

4.3.1 Padr˜

ao de projeto Visitor

Na análise semântica a árvore sintática é acessada diversas vezes, mas cada vez com objetivos diferentes. Para tornar simples a implementa¸cão desse acesso, o padrão de projeto Visitor foi escolhido. Uma das vantagens deste padrão é a habilidade de adicionar novas opera¸cões a uma estrutura já existente.

O padrão de projeto Visitor faz uso de uma interface que possui todos os métodos de visita¸cão dos nós da árvore sintática. Com isso, as diferentes funcionalidades da análise semântica estão implementadas em classes que implementam esta interface. Cada nó da ´

arvore possui um m´etodo que aceita um determinado comportamento implementado na classe passada como seu argumento.

4.3.2 Tabela de s´ımbolos

A tabela de s´ımbolos foi constru´ıda com duas Hashtables, uma para Procedures-SymbolTable, classe que especifica os atributos de uma tabela de s´ımbolos para procedure, e outra para as variáveis. Tendo em vista que não existe variável local e os procedures não retornam nenhum tipo de dado, então a tabela de s´ımbolos de procedure só possui os seus identificadores. As variáveis possuem alguns atributos como nome, registrador e tipo da variável (temporária ou constante).

(40)

28 A tabela de s´ımbolos é constru´ıda a medida que os nós da árvore sintática são visitados. Essa constru¸cão é realizada através da classe BuildSymbolTableVisitor que implementa os métodos responsáveis por capturar informa¸cões dos nós da árvore e guarda-las na tabela de s´ımbolos.

4.3.3 Verifica¸

c˜

ao de erros

Existem três classes responsáveis pela verifica¸cão da poss´ıvel ocorrência de erros semânticos: BuildSymbolTableVisitor, UndefinedVariableVisitor e TypeCheckingVisitor. A tabela 4.1 mostra os erros detectáveis por cada uma dessas classes.

Classe Papel

BuildSymbolTableVisitor Construir a tabela de s´ım-bolos.

Verificar se as vari´aveis fo-ram definidas mais de uma vez.

UndefinedVariableVisitor Verificar se as vari´aveis que est˜ao sendo utilizadas foram definidas.

TypeCheckingVisitor Verificar se os valores atri-bu´ıdos às variáveis são com-pat´ıveis com os seus tipos. Verificar se as expressões nas condi¸cões do IfState-ment/DoStatement são bo-oleanas.

Tabela 4.1: Erros semˆanticos

Todas as classes responsáveis pela deteçcão de erros semânticos percorrem os nós da ´

arvore sintática, mas cada uma com uma estratégia especifica de deteçcão. Encontrando algum erro, o processo de compila¸cão é abortado e o erro é reportado.

(41)

29

4.4 Gera¸

c˜

ao de c´

odigo

Depois de passar pela análise semântica sem que tenha sido detectado algum erro semântico, a parte final do processo de compila¸cão é alcan¸cada, a gera¸cão de código. Esta etapa é dividida em três partes: Gera¸cão de código, otimiza¸cão do código gerado e gera¸cão do código Assembly MIPS.

4.4.1 Representa¸

c˜

ao Intermedi´

aria

Para representar o código intermediário, instru¸cões quadruplas foram definidas. Na tabela 4.2 detalhes sobre cada uma dessas instru¸cões são mostrados.

Opera¸cão IR Código de três endere¸cos

Assignment x := y op z

Unary Assignment x := op y

Copy x := y

Unconditional Jump goto Label

Conditional Jump iffalse x goto Label

Parameter param x

Call x := call f, NUMPARAMS

Indexed Assignment x := y[i] y[i] := x

Tabela 4.2: Instru¸c˜oes quadruplas

No processo de gera¸cão do código intermediário, labels e instru¸cões quadruplas são criadas ao percorrer a árvore sintática. As labels são relacionadas às instru¸cões, em alguns momentos, com aquelas que iniciam um bloco e em outros com as que finalizam um bloco. As que iniciam um bloco podem estar relacionadas a um novo procedure, ao bloco do else numa estrutura condicional ou aos blocos do do e do loop numa estrutura de repeti¸cão e que são alcan¸cáveis através do uso de instru¸cões do tipo Unconditional Jump ou Conditional Jump, e as que finalizam, são as que se localizam no fim dos blocos citados anteriomente e são importantes para o caso de não ter que executar as instru¸cões que estão num bloco espec´ıfico. As instru¸cões quadruplas criadas são armazenadas numa lista de instru¸cões que será utilizada no processo de conversão do código intermediário

(42)

30 para o código em Assembly, por isso, a ordem das instru¸cões nesta lista é de extrema importância.

Como citado antes, o código numa linguagem reversiva tem duas versões, a forward e a reverse. Então, após gerar o código intermediário da versão forward, é necessário fazer o mesmo para a outra versão. Os passos para tal opera¸cão são os mesmos, a única diferen¸ca é a ordem de apari¸cão das instru¸cões.

4.4.2 Assembly MIPS

Após a cria¸cão das instru¸cões intermediárias, o compilador chega a sua etapa final, o momento de conversão do código intermediário para o código em Assembly MIPS. Nesta etapa, as subrotinas, cada uma vinculada a um único tipo de instru¸cão intermediária, são as protagonistas, pois possuem o conjunto de instru¸cões em Assembly equivalente a instru¸cão a qual estão relacionadas.

O processo de conversão é realizado selecionando uma instru¸cão intermediária por vez, verificando se existe alguma label relacionada a esta instru¸cão, caso exista, é inclu´ıda no arquivo do código antes ou depois dela. Então, a rotina vinculada a instru¸cão selecio-nada é chamada para incluir o conjunto do código equivalente no arquivo. Este processo é repetido até que todas as instru¸cões sejam convertidas.

Como Assembly Mips possui poucos registradores temporários, então a manipula-¸cão destes deve ser realizada com cuidado, pois existem programas que utilizam muitas variáveis temporárias e, caso não existisse um controle dos registradores, não teria como realizar mais nenhuma opera¸cão por falta deles. Para que não ocorra esse tipo de pro-blema, todos os valores, inclusive das variáveis temporárias, são guardados em memória, assim deixando os registradores livres.

Por ser uma linguagem revers´ıvel, são gerados dois códigos para um mesmo pro-grama, um para a versão forward e outro para versão reverse. Todos os códigos gerados são concatenados no mesmo arquivo de extensão asm, juntamente com as fun¸cões pr´ e-definidas como write, read, exit e as exce¸cões.

O programa na linguagem Assembly MIPS ´e executado atrav´es do MARS Simulator [3].

(43)

Cap´ıtulo 5

Conclus˜

ao

Neste projeto, foi desenvolvido um compilador para a linguagem revers´ıvel Janus. Embora a linguagem seja revers´ıvel, caracter´ıstica n˜ao encontrada nas linguagens mais populares, foi seguido o modelo adotado em compiladores convencionais.

A constru¸cão dos Analisadores Léxico e Sintático foi facilitada através do uso das bibliotecas que tem o papel de gerá-los. As fases de análise semântica e gera¸cão de código tiveram as suas estruturas implementadas para que fossem geradas a tabela de s´ımbolos e o código final, esta última etapa foi a mais complicada, pois envolve a linguagem Assembly e detalhes que não são relevantes quando a linguagem é de mais alto n´ıvel, como a manipula¸cão de registradores. Além da dificuldade da cria¸cão deste compilador, a linguagem Janus traz consigo detalhes que dificultam seu entendimento, pois todas as suas instru¸cões e estruturas estão adaptadas para reversão, embora a lógica por trás destas estruturas seja semelhante a de linguagens convencionais, existem detalhes inclu´ıdos justamente para garantir a reversibilidade que podem dificultar a assimila¸cão.

Alguns motivos tornaram o desenvolvimento deste projeto um grande desafio, o conceito de reversibilidade, o tamanho do projeto e a variedade de conceitos da área da computa¸cão usados na sua cria¸cão. Diante de todas estas dificuldades, o objetivo foi alcan¸cado, o desenvolvimento do compilador para Janus em Java.

(44)

Referˆ

encias Bibliogr´

aficas

[1] CUP. http://www2.cs.tum.edu/projects/cup/. [2] JFlex. http://jflex.de/.

[3] Mars Simulator. http://courses.missouristate.edu/KenVollmar/mars/.

[4] Alfred V. Aho, Ravi Sethi e Jeffrey D. Ullman. Compiladores: Princ´ıpios, T´ecnicas e Ferramentas. LTC, 1995.

[5] Christopher Lutz e Howard Derby. Janus: a time-reversible language. Caltech class project, 1982.

[6] Kalyan S Perumalla. Introduction to reversible computing. CRC Press, 2013.

[7] Tetsuo Yokoyama e Robert Gl¨uck. A reversible programming language and its inverti-ble self-interpreter. Em Proceedings of the 2007 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation, pp. 144–153. ACM, 2007.