Compiladores: P ASCAL jr

(1)

Compiladores: P ASCAL

jr

Rog´erio Eduardo da Silva, M.Sc.

2005/2

(2)

Sum´

ario

1 Introdu¸c˜ao 1

1.1 Evolu¸c˜ao das Linguagens de Programa¸c˜ao . . . 1

1.2 Introdu¸cão à Compila¸cão . . . 2

1.2.1 Fases da Compila¸c˜ao . . . 3

1.3 Ferramentas para Gera¸c˜ao de Compiladores . . . 6

2 Um Compilador Simples de uma Passagem 7 2.1 Defini¸c˜ao da Sintaxe . . . 7

2.2 An´alise Gramatical . . . 8

2.2.1 Exerc´ıcios Propostos . . . 9

2.3 Caracter´ısticas da linguagem P ASCALjr . . . 10

3 Análise Léxica 13 3.1 O Papel do Analisador Léxico . . . 13

3.2 Buferiza¸c˜ao de Entrada . . . 14

3.3 Gram´aticas e Linguagens Regulares . . . 15

3.4 Especifica¸c˜ao e Reconhecimento de Tokens . . . 17

3.4.1 Trabalho Pr´atico #1 . . . 19

4 Análise Sintática 21 4.1 O Papel do Analisador Sintático . . . 21

4.2 An´alise Sint´atica Ascendente - BOTTOM UP . . . 23

4.2.1 Algoritmo “Empilhar-e-Reduzir” . . . 23

4.3 An´alise Sint´atica Descendente - TOP DOWN . . . 24

4.3.1 An´alise Sint´atica Preditiva . . . 25

4.4 Reconhecedor de Gram´aticas Preditivas Descendentes . . . 27

4.4.1 Algoritmo para Constru¸c˜ao da Tabela de An´alise . . . 29

4.4.2 Projeto de uma Gram´atica para um Analisador Sint´atico Preditivo Ascendente . . . 30

4.4.3 Projeto de uma Gram´atica para um Analisador Sint´atico Preditivo Descendente . . . 31

(3)

5 An´alise Semˆantica 41

5.1 Tradu¸c˜ao Dirigida pela Sintaxe . . . 41

5.1.1 Defini¸c˜oes L-Atribu´ıdas . . . 43

5.1.2 Verifica¸c˜oes de Contexto . . . 44

5.2 Tabela de S´ımbolos . . . 46

5.2.1 Atributos dos Nomes dos Identificadores . . . 47

5.2.2 Hashing . . . 47

5.3 Projeto das Regras Semˆanticas . . . 50

5.3.1 Trabalho Pr´atico #3 . . . 56

6 Gera¸cão de Código Intermediário 59 6.1 Linguagens Intermediárias . . . 59

6.1.1 Representa¸c˜oes Gr´aficas . . . 59

6.1.2 Nota¸cão Pós (e Pré) Fixadas . . . 60

6.1.3 C´odigo de Trˆes-Endere¸cos . . . 61

6.2 BackPatching (Retrocorre¸c˜ao) . . . 64

7 Otimiza¸cão de Código 67 7.1 Otimiza¸cão Peephole . . . 67

7.2 Otimiza¸c˜ao de Blocos Sequenciais atrav´es de grafos . . . 68

7.2.1 Algoritmo para Construir o GAD de um bloco . . . 69

7.2.2 Algoritmo para Ordena¸c˜ao de um GAD . . . 70

8 Gera¸cão de Código Objeto 71 8.1 Máquina Objeto . . . 72

8.1.1 Regras para Gera¸c˜ao de C´odigo Objeto . . . 76

(4)

Lista de Figuras

1.1 Processo de Compila¸c˜ao . . . 2

1.2 Fases da Compila¸c˜ao . . . 3

1.3 Arvore resultante da an´alise de um comando de atribui¸c˜ao em PASCAL . .´ 4

2.1 Representa¸cão da árvore gramatical da produ¸cão A→XYZ . . . . 8

2.2 Ambig¨uidade Gramatical . . . 8

3.1 O papel do analisador l´exico . . . 13

3.2 Buffer de entrada para um analisador l´exico . . . 15

3.3 Autˆomato finito de reconhecimento de n´umeros inteiros e reais . . . 17

3.4 AFD de reconhecimento de identificadores simples . . . 18

3.5 AFD de reconhecimento de strings . . . 18

4.1 Exemplo de ´Arvore Sint´atica . . . 22

4.2 Deriva¸cão à Esquerda e à Direita . . . 22

4.3 An´alise descendente com backtracking . . . 25

4.4 Exemplos de Recursão à Esquerda e à Direita . . . 27

4.5 Funcionamento de um Analisador Sint´atico Descendente . . . 28

5.1 Exemplo de ´Arvore Decorada para a Express˜ao 3*5+4 . . . 42

5.2 Grafo de Dependˆencias . . . 43

5.3 Tipos Simples e Construtor de Tipos . . . 44

5.4 Hashing com Encadeamento . . . 49

6.1 Exemplo de Representa¸c˜ao Gr´afica de Operadores para a=b*c+b*2 . . . . 60

6.2 Backpatching para express˜oes l´ogicas . . . 65

(5)

Cap´ıtulo 1

Introdu¸c˜

ao

Entende-se por linguagem como uma forma eficiente de comunica¸cão entre pessoas. Na verdade a linguagem é um conjunto de palavras usadas, segundo certas regras, para a forma¸cão de frases compreens´ıveis por ambos os interlocutores (falantes).

Quando um dos interlocutores é o computador, se faz necessário o uso de uma lingua-gem especial denominada lingualingua-gem de programa¸cão que permite a comunica¸cão entre homem e máquina através da defini¸cão de comandos.

Uma L. P. é ser dita de baixo n´ıvel, se esta somente aceitar comandos na própria linguagem da máquina (0’s e 1’s) que é de dif´ıcil aplica¸cão. Já as linguagens ditas de alto n´ıvel, são representadas por a¸cões próximas ao problema a ser resolvido que são, posteriormente, traduzidas para a linguagem de máquina, através de um agente especial denominado compilador ou interpretador.

Concluindo: compilador é um programa capaz de traduzir um certo programa fonte (escrito em uma linguagem fonte) para outro programa objeto (escrito em uma linguagem objeto) geralmente a própria linguagem de máquina.

1.1 Evolu¸c˜

ao das Linguagens de Programa¸c˜

ao

Cronologicamente, as L. P.’s s˜ao classificadas em cinco gera¸c˜oes: (1a_{) linguagens de}

máquina; (2a_{) linguagens simbólicas (Assembly); (3}a_{) linguagens orientadas ao usuário;}

(4a_{) linguagens orientadas `a aplica¸c˜ao e (5}a_{) linguagens de conhecimento.}

As duas primeiras s˜ao consideradas linguagens de baixo n´ıvel, enquanto que as demais de alto n´ıvel.

Os primeiros computadores só podiam ser programados através da sua própria lingua-gem de máquina (código binário), onde cada opera¸cão possu´ıa sua representa¸cão binária que era passada à máquina através de circuitos elétricos. Esse processo, além de extrema-mente dif´ıcil e cansativo, era altaextrema-mente sujeito a erros devido a sua grande complexidade de execu¸cão.

A seguir, como uma primeira tentativa de simplifica¸cão, surgem as linguagens simbóli-cas ou de montagem (Assembly). Agora, extensas seqüências binárias são substitu´ıdas por

mnemônicos que são “palavras especiais” que representam certas a¸cões básicas. Exemplo

MOV, JMP, etc. Os mnemônicos precisavam ser traduzidos para a linguagem de máquina antes da sua execu¸cão.

(6)

A 3a _{gera¸c˜ao surgiu na d´ecada de 60, com as linguagens procedimentais como}

FOR-TRAN, PASCAL e ALGOL e declarativas como LISP e PROLOG. Nas linguagens pro-cedimentais, um programa especifica uma seqüência de passos a serem seguidos para a solu¸cão do problema. Já as linguagens declarativas são subdivididas em funcionais e lógicas. A programa¸cão funcional se baseia na teoria das fun¸cões recursivas, enquanto que, as linguagens lógicas se baseiam em proposi¸cões da lógica de predicados (fatos e regras).

Devido ao fato de programas escritos em linguagens de 3a _{gera¸c˜ao serem muito}

ex-tensos e de dif´ıcil manuten¸cão, surgiram as linguagens de aplica¸cão (4a _{gera¸cão), onde o}

desenvolvedor deixa de se preocupar com “atividades secundárias” e trata apenas da co-difica¸cão do problema (foco do programador deixa de ser a coco-difica¸cão para ser a análise do problema). Aspectos como: interface de entrada e sa´ıda, relatórios, etc. são resol-vidos pela própria linguagem através de um banco de dados e dicionários associados às aplica¸cões desenvolvidas.

A 5a _{gera¸c˜ao das linguagens de programa¸c˜ao atua em problemas altamente}

comple-xos onde a representa¸cão de conhecimento se faz necessária para sua solu¸cão, como os problemas enfrentados pela inteligência artificial. A linguagem PROLOG é aceita como pertencente a esta gera¸cão.

1.2 Introdu¸c˜

ao `

a Compila¸c˜

ao

Conforme já dito, um compilador nada mais é do que um programa tradutor responsável por converter uma certa linguagem fonte em outra linguagem objeto (ver Figura 1.1). Usualmente a linguagem objeto é a própria linguagem de máquina, mas não necessaria-mente.

Programa

Fonte COMPILADOR ProgramaObjeto Mensagem

de Erro

Figura 1.1: Processo de Compila¸c˜ao

Existem dois tipos básicos de tradutores: os compiladores e os interpretadores. Os primeiros fazem uma análise completa sobre o programa fonte, caso não encontre erros faz a tradu¸cão de todo o código fonte para a linguagem objeto que será posteriormente executado em uma máquina capaz de fazê-lo. Já os interpretadores não têm essa preo-cupa¸cão hol´ıstica (análise completa) sobre o programa fonte. Um interpretador traduz um comando fonte por vez e o executa em uma máquina virtual (programa que simula o funcionamento de um computador) sem a necessidade da cria¸cão do programa objeto.

Interpretadores são mais simples de serem implementados, porém, compiladores geram execu¸cões mais rápidas de programas, pois não há a perda de tempo de tradu¸cões virtuais a cada nova instru¸cão executada.

(7)

1.2.1 Fases da Compila¸c˜

ao

O processo de compila¸cão pode ser dividido em dois grupos de etapas: as etapas de análise e as etapas de s´ıntese. Na análise, o programa fonte é percorrido em busca de erros de programa¸cão (inconsistências com a linguagem fonte), já na etapa de s´ıntese (após a verifica¸cão da corretude do programa de origem), efetua-se a tradu¸cão, propriamente dita, do código fonte para a linguagem objeto em questão. A figura 1.2 abaixo ilustra todo o processo: Tabela de Símbolos Análise Léxica Análise Sintática Análise Semântica

Geração de Código Intermediário

Otimização de Código Geração de Código Objeto

Manipulador de Erros ANÁLISE SÍNTESE Programa Fonte Programa Objeto

Figura 1.2: Fases da Compila¸c˜ao

A análise léxica ou scanning é a primeira etapa do processo de compila¸cão. Ela

é responsável por analisar linearmente os caracteres do programa fonte e agrupá-los em unidades léxicas denominadas tokens. O token é o elemento mais básico da programa¸cão; ele é representado por um conjunto de caracteres que apresentam um significado claro para o programa. Exemplo: Para o seguinte código em PASCAL:

Media := Nota1 + Nota2 * 2 Os caracteres poderiam ser agrupados da seguinte forma: 1. O identificador “Media” 2. O s´ımbolo de atribui¸cão “:=” 3. O identificador “Nota1” 4. O sinal de adi¸cão “+” 5. O identificador “Nota2” 6. O sinal de multiplica¸cão “*”

(8)

7. O n´umero “2”

Os espa¸cos em branco presentes na senten¸ca s˜ao ignorados durante a an´alise.

O resultado da análise léxica é uma lista contendo todos os tokens encontrados no programa fonte. Essa lista léxica é então o elemento de entrada para a análise sintática

ou análise gramatical (parsing ), onde é verificado se os tokens podem ser agrupados em senten¸cas válidas (comandos, expressões, etc.) da linguagem fonte. Normalmente, esses agrupamentos são realizados através da constru¸cão de uma árvore sintática conforme é apresentado na figura 1.3:

Comando de Atribuição Identificador Símbolo de

Atribuição Expressão

Expressão _AritméticoOperador Expressão

Media :=

Nota1 +

Nota2 * 2

Figura 1.3: Árvore resultante da análise de um comando de atribui¸cão em PASCAL A estrutura hierárquica de um programa é usualmente expressa por regras recursivas. Por exemplo, poder´ıamos ter as seguintes regras como parte defini¸cão de expressões:

1. Qualquer identificador é uma expressão 2. Qualquer número é uma expressão

3. Se expressão1 e expressão2 são expressões válidas, então expressão1 “op. aritmético”

expressão2 também é

A estrutura utilizada para a representa¸cão dessas regras é a gramática livre de contexto (GLC), normalmente apresentada na Forma Normal de Backus (BNF).

Exemplo:

hcomandoi ::= hwhilei | hatribuic¸˜aoi | . . .

hwhilei ::= while hexpr booli do hcomandoi hatribuic¸˜aoi ::= identificador := hexpr aritmi

hexpr booli ::= hexpr aritmi op.L´ogico hexpr aritmi

hexpr aritmi ::= hexpr aritmi op.Aritm htermoi | htermoi htermoi ::= n´umero | identificador

Após a análise sintática, tem-se a certeza de que o programa está escrito corretamente (respeita as regras gramaticais da linguagem fonte), porém, será que o programa escrito faz algum sentido? Ou seja, executa de forma apropriada?

(9)

A análise semântica tem por objetivo validar os comandos e expressões através de análises como compatibilidade de tipos e escopo de identificadores. Esta etapa analisa, por exemplo, se um identificador declarado como variável é usado como tal, ou se uma expressão atribu´ıda a uma variável retorna um tipo compat´ıvel com o qual foi declarada a variável (em algumas linguagens, uma variável inteira não pode receber uma expressão real).

Até aqui foi realizada a etapa de análise do programa fonte, ou seja, a procura por erros de programa¸cão. Caso nenhum erro seja encontrado, o processo de compila¸cão passa então para a etapa de s´ıntese, ou seja, a constru¸cão do programa objeto.

A gera¸cão do código intermediário é a primeira fase da constru¸cão do programa objeto. O que ela faz é a representa¸cão do programa fonte em uma linguagem inter-mediária simplificada (máquina abstrata), o que permite a realiza¸cão da próxima etapa mais facilmente.

A próxima etapa é a otimiza¸cão de código, que tem por objetivo tentar modificar o código intermediário no intuito de melhorar a velocidade de execu¸cão, bem como a utiliza¸cão do espa¸co de memória, fazendo com isso, um uso mais racional dos recursos da máquina.

A última etapa do processo de compila¸cão é a gera¸cão de código objeto propria-mente dita. Esta fase tem como objetivos: produ¸cão de código objeto, reserva de memória para constantes e variáveis, sele¸cão de registradores, etc. É a fase mais dif´ıcil, pois re-quer uma sele¸cão cuidadosa das instru¸cões e dos registradores da máquina alvo a fim de produzir código objeto eficiente.

Exemplo de gera¸cão de código para o código fonte: While I < 100 do I := J + I

Código Intermediário Otimiza¸cão Código Objeto L0: if I<100 goto L1 L0: if I ≥ 100 goto L2 L0: MOV AX, I goto L2 I := J+I CMP AX, 100

goto L0 JGE L2 MOV AX, J MOV BX, I ADD BX MOV I, AX JMP L0 L1: Temp := J+I L2: . . . L2: . . . I := Temp goto L0 L2: . . .

Além dessas fases, há também os módulos de gerenciamento de tabelas e mani-pula¸cão de erros.

O gerenciamento de tabelas consiste de um conjunto de tabelas e rotinas associadas que são utilizadas por quase todas as fases do tradutor. A principal estrutura deste módulo é a Tabela de S´ımbolos, que é responsável por armazenar informa¸cões acerca dos identificadores do programa sob análise, como por exemplo: declara¸cão das variáveis, procedimentos e sub-rotinas, lista de parâmetros, etc..

(10)

Os dados a serem armazenados dependem do projeto do tradutor, mas os mais co-muns são: identificador, classe (variável, parâmetro, procedimento, etc.), tipo, endere¸co, tamanho.

A tabela de s´ımbolos deve ser estruturada de uma forma que permita rápida inser¸cão e extra¸cão de informa¸cões, porém deve ser tão compacta quanto poss´ıvel.

O módulo de manipula¸cão de erros tem por objetivo “tratar os erros” que são de-tectados em todas as fases de análise do programa fonte e deve dispor de mecanismos (recupera¸cão de erros) que permitam que o processo de análise prossiga mesmo que erros tenham sido detectados.

1.3 Ferramentas para Gera¸c˜

ao de Compiladores

Existem diversas ferramentas para auxiliar a constru¸c˜ao de compiladores chamadas de

geradores de compiladores ou sistemas de escritas de tradutores. A seguir s˜ao apresentados

alguns exemplos:

Geradores de Analisadores Gramaticais responsáveis por desenvolver analisadores sintáticos, normalmente a partir de entrada baseada numa gramática livre de con-texto.

Geradores de Analisadores Léxicos geram automaticamente analisadores léxicos a partir de uma especifica¸cão baseada em expressões regulares.

Dispositivos de tradu¸cão dirigida pela sintaxe produzem cole¸cões de rotinas que percorrem uma árvore gramatical, gerando código intermediário.

Geradores automáticos de código tal ferramenta toma uma cole¸cão de regras que definem a tradu¸cão de cada opera¸cão da linguagem intermediária para linguagem alvo. Tais regras precisam incluir detalhamento suficiente para que possamos lidar com os diferentes métodos de acesso poss´ıveis para os dados.

Dispositivos de fluxo de dados Ferramentas que auxiliam na etapa de otimiza¸c˜ao de c´odigo.

Não é de escopo desta disciplina o estudo de ferramentas de implementa¸cão de com-piladores, mais detalhes podem ser obtidos na bibliografia de apoio.

(11)

Cap´ıtulo 2

Um Compilador Simples de uma

Passagem

2.1 Defini¸c˜

ao da Sintaxe

A especifica¸cão da sintaxe de uma linguagem de programa¸cão pode ser obtida através de uma gramática livre de contexto.

Exemplo: Seja o comando condicional da forma:

IF Express˜ao THEN Comando ELSE Comando

se Expr denotar a constru¸cão de uma expressão e Cmd denotar um comando (ou enun-ciado), pode-se usar as regras de produ¸cão de uma GLC1 _{para representar tal estrutura}

da seguinte forma:

< Cmd >⇒ IF < Expr > THEN < Cmd > ELSE < Cmd >

as palavras-chave como IF, THEN e ELSE representam os s´ımbolos terminais, enquanto que os termos Cmd e Expr, representam os n˜ao-terminais.

Exemplo de uma GLC simples para definir expressões aritméticas baseadas apenas em adi¸cão e subtra¸cão:

< Lista > ⇒ < Lista > + < Digito > < Lista > ⇒ < Lista > − < Digito > < Lista > ⇒ < Digito >

< Digito > ⇒ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

onde os s´ımbolos 0 a 9 e + ou - são os elementos terminais, enquanto que Lista e Digito representam os não-terminais. Convencionalmente, o primeiro não-terminal representa o axioma da gramática. Expressões exemplo: 1+1, 3-6+9, 1+2+3+4+5+6

(12)

2.2 An´

alise Gramatical

A análise gramatical é feita através de deriva¸cões de cadeias a partir do axioma da gramática. Se um não-terminal A possui uma produ¸cão A ⇒ XYZ então, uma árvore gramatical pode ter um nó rotulado de A com 3 filhos X, Y e Z da esquerda para a direita, conforme a figura 2.1.

A

X

Y

Z

Figura 2.1: Representa¸cão da árvore gramatical da produ¸cão A→XYZ

Formalmente, segundo uma GLC, a ´arvore gramatical resultante apresenta as seguintes propriedades:

• A raiz ´e rotulada pelo s´ımbolo de partida (axioma); • Cada folha ´e rotulada por um terminal ou por ε;

• Cada nó interno é rotulado por um elemento não-terminal;

• Se A ⇒ X1X2. . . Xné uma produ¸cão então, algum nó interno da árvore será rotulado

por A sendo X1X2. . . Xn os r´otulos dos filhos desse n´o.

Ambiguidade

Uma gramática pode ter mais de uma árvore gramatical gerando uma dada cadeia, neste caso, ela é dita ser amb´ıgua. Ambos os exemplos da figura 2.2 geram a senten¸ca 9-5+2.

Cadeia

₊

Cadeia

_-

Cadeia

9

5

2 Cadeia

Cadeia

+

Cadeia

-9

5

2

(13)

Associatividade de Operadores

Convencionalmente, 9+5+2 é equivalente à (9+5)+2, pois, ao analisarmos o operando 5 precisamos decidir qual opera¸cão será realizada primeiro. Pela conven¸cão da matemática a adi¸cão é associativa à esquerda, sendo assim o resultado (9+5)+2 é obtido. Na maioria das linguagens de programa¸cão, as quatro opera¸cões básicas (adi¸cão, subtra¸cão, multiplica¸cão e divisão) são associativas à esquerda.

A exponencia¸cão é um exemplo de operador associativo à direita (em Fortran) 5**2**3 é equivalente a 5**(2**3). Outro exemplo é o operador de atribui¸cão, onde a expressão a=b=c (em linguagem C) é tratada como a=(b=c).

Precedˆencia de Operadores

Considere a expressão 9+5∗2. Existem duas interpreta¸cões poss´ıveis: (9+5)∗2 e 9+(5∗2). Quando mais de um tipo de operadores estiverem presentes em uma expressão é necessário se definir a ordem de precedência entre eles.

Na aritmética, os operadores ∗ e / tem precedência mais alta do que + e -; assim, na expressão anterior o operador de multiplica¸cão é capturado antes da adi¸cão.

2.2.1 Exerc´ıcios Propostos

1. Prova, através da constru¸cão da árvore de deriva¸cão, que os exemplos anteriores são válidos para a gramática de expressões aritméticas vista.

2. Considere a gram´atica livre de contexto: S → SS+ | SS∗ | a

(a) Mostre que a cadeia aa+a∗ pode ser gerada por esta gram´atica. (b) Construa a ´arvore gramatical para esta cadeia.

(c) Qual é a linguagem gerada por esta gramática? Justifique sua resposta. 3. Quais são as linguagens geradas pelas seguintes gramáticas?

(a) S → 0S1 | 01 (b) S → +SS | -SS | a

(c) S → S(S)S | ε (d) S → aSbS | bSaS | ε

(e) S → a | S+S | SS | S* | (S)

4. Construa uma gramática livre de contexto para os números romanos (1 a 10). 5. Construa uma G.L.C. para as expressões aritméticas de inteiros e identificadores

(14)

2.3 Caracter´ısticas da linguagem P ASCAL

jr

1. N˜ao ´e caso sensitivo (‘A’ = ‘a’)

2. Suporta os tipos: integer, real, char, string e boolean 3. Comandos:

• Atribui¸c˜ao com operadores: “:=”, “+=”, “-=”, “*=”, “/=”, “++”, “- -” • Entrada com o comando read( )

• Sa´ıda com os comandos write( ) e writeln() • Condicional com o comando if - then - else • Repeti¸c˜oes:

– Pr´e teste com o comando while - do – P´os teste com o comando repeat - until – Contada com o comando for - to - do

• Sub-rotinas atrav´es dos comando procedure e function.

– Retorno de fun¸c˜oes com o comando result

– Nome de identificador de subrotinas inicia obrigatoriamente com “ ” (ex.: Tela)

4. Constantes caracteres delimitados por (‘ ’) e constantes strings por (“ ”) 5. Operadores relacionais: “=”, “>=”, “<=”, “>”, “<”, “<>”

6. Operadores lógicos “and”, “or”, “xor” (ou exclusivo), “not” 7. Operadores aritméticos: “+”, “-”, “*”, “/”, “**” (potencia¸cão) 8. Suporta operadores ternários: Expr “?” valor1 “:” valor2 9. Precedência de operadores:

(a) “=”, “+=”, “-=”, “*=”, “/=”, “++”, “- -” (b) “and”, “or”, “xor”

(c) “=”, “>=”, “<=”, “>”, “<”, “<>” (d) “not” (e) “+”, “-” (f) “*”, “/” (g) “**” (h) “(” “)” (i) “-” 10. S´ımbolos especiais: “,”, “:”, “;”, “(”, “)”, “.”

(15)

11. Bloco de comandos delimitados por “begin” e “end” 12. Coment´ario de linha com operador “//”

13. Coment´ario de bloco com os delimitadores “{” e “}”

14. Lista de Palavras Reservadas: var, const, while, do, for, read, write, writeln, if, then, else, true, false, integer, real, char, string, boolean, result, procedure, function,and,or,xor,not,to,repeat,until,program,downto

Exemplos de programas a serem reconhecidos pela linguagem P ASCALjr:

{

PILOTO.TXT

Exemplo completo de programa na linguagem PASCALjr Desenvolvido por Rogerio Eduardo da Silva

Agosto, 2005 }

Program Piloto;

// declara¸c~oes de variaveis e constantes globais

var: integer cont; real Nota1, Nota2, Media_das_medias, med; const: integer total = 10;

// Subrotina de preenchimento de tela procedure _Tela()

begin

writeln("******** ENTRADA DE DADOS ***************"); writeln("Digite os valores da entrada:");

end;

// Calculo da media aritmetica entre duas notas func real _Media(real a , b)

var: real media; begin

media := (a+b)/2.0; result := media; end;

// Inicio do Programa Principal begin

Media_das_medias := 0; for cont=0 to total do begin

_Tela();

read(Nota1, Nota2);

med := _Media(Nota1, Nota2); Media_das_medias += med;

(16)

write("Media = ",med); end;

write("Media Geral = ",Media_das_medias/total); end.

2.3.1 Exerc´ıcios Propostos

Usando a linguagem P ASCALjrfa¸ca:

1. Um programa para c´alculo do fatorial de N.

(17)

Cap´ıtulo 3

An´

alise L´

exica

3.1 O Papel do Analisador L´

exico

A análise léxica é a primeira fase de um compilador e tem por objetivo fazer a leitura do programa fonte, caracter a caracter, e traduzi-lo para uma seqüência de s´ımbolos léxicos denominados tokens, os quais são utilizados pelo analisador sintático. Exemplos de tokens são os identificadores, palavras reservadas, operadores da linguagem, etc.

A intera¸cão entre análise léxica e sintática é normalmente implementada fazendo-se com que o analisador léxico seja uma sub-rotina ou co-rotina do parser (ver figura 3.1). Ao receber do parser um comando do tipo “obter próximo token”, o analisador léxico lê os caracteres de entrada até que possa identificar o próximo token.

Programa Fonte Analisador Léxico Analisador Sintático Tabela de Símbolos Token Obter Próximo Token

Figura 3.1: O papel do analisador l´exico

Um analisador léxico clássico pode ser entendido como um sistema de estados fini-tos e, portanto, utiliza-se um autômato finito para sua implementa¸cão. As principais caracter´ısticas desse autômato:

• O alfabeto de entrada s˜ao os caracteres pertencentes ao arquivo fonte

• Cada estado final reconhece uma classe espec´ıfica de tokens da linguagem fonte

´

E denominado erro léxico a qualquer evento (durante o processo de análise léxica) que impossibilite a interpreta¸cão de um token.

Uma lista de tokens é o resultado do processo de análise léxica, caso nenhum erro léxico tenha sido encontrado.

(18)

Porque efetuar an´alise l´exica?

Simplifica¸cão de Projeto é mais simples implementar dois analisadores distintos (para tarefas distintas) do que um analisador sintático que fa¸ca todo trabalho de forma unificada;

Melhor Eficiência a análise léxica é potencialmente mais lenta que a sintática (pois efetua leitura de caracteres em disco). Técnicas de buferiza¸cão de leitura podem acelerar significativamente este processo;

Portabilidade as peculiaridades do alfabeto de entrada de cada linguagem podem ser tratadas exclusivamente pelo scanner.

Tokens, Padr˜oes e Lexemas

Um token é um s´ımbolo terminal da gramática da linguagem fonte sob análise. Em geral, existem diversas cadeias de caracteres para as quais o mesmo token é gerado.

Essas cadeias respeitam um determinado padrão ou regra associada a esse token. Um lexema é um conjunto de caracteres que é reconhecido pelo padrão de um deter-minado token.

Exemplo:

const pi = 3.14159;

a subcadeia pi ´e um lexema para o token “identificador”, pois respeita o padr˜ao para os identificadores (letra)(letra | digito)∗_.

Atributos para os tokens

Um token ´e comumente representado como um par [LEXEMA, CLASSE], onde a classe indica qual foi o padr˜ao utilizado para reconhecer o lexema.

Outras informa¸cões adicionais podem ser incorporadas à descri¸cão do token, de acordo com as necessidades das fases subseqüentes, como por exemplo, número da linha e co-luna onde o token foi reconhecido no arquivo fonte e número de caracteres lidos até o reconhecimento, seria exemplos de informa¸cões adicionais úteis caso um erro léxico seja detectado.

3.2 Buferiza¸c˜

ao de Entrada

Conforme já visto, o processo de análise léxica é normalmente realizado efetuando-se uma leitura do arquivo fonte de entrada, caracter a caracter, o que resulta em um processo significativamente lento.

Existem 3 alternativas de implementa¸cão de analisadores léxicos (listados em ordem crescente de complexidade de implementa¸cão):

1. Usar ferramentas de constru¸cão de analisadores léxicos (como o Lex), através de expressões regulares;

(19)

2. Escrever um programa numa linguagem de programa¸c˜ao convencional, usando seus recursos de entrada e sa´ıda;

3. Escrever um programa numa linguagem de montagem e manipular explicitamente a entrada e a sa´ıda.

Alguns aspectos a serem considerados no projeto de implementa¸c˜ao de um scanner : Buffer

Em muitas linguagens, existem momentos que o analisador léxico precisa examinar vários caracteres à frente do lexema, antes que seja anunciado um reconhecimento.

Os caracteres que foram lidos e não foram “aproveitados” no lexema sob análise, são então, devolvidos ao fluxo de entrada para que possam ser lidos novamente na análise de outro lexema posterior.

Assim sendo, um buffer de entrada que acumula vários caracteres é criado, conforme a figura 3.2. O processo de análise léxica é realizado sobre este buffer. Os tokens que foram reconhecidos são eliminados do buffer e novos caracteres são adicionados a ele até que todo o arquivo fonte seja lido e analisado.

E = m * c * c eof

apontador

Figura 3.2: Buffer de entrada para um analisador l´exico

Em casos mais simples, a entrada pode ser realizada caracter a caracter, contendo apenas um buffer de armazenamento dos caracteres lidos.

3.3 Gram´

aticas e Linguagens Regulares

A seguir, serão revisados alguns conceitos importantes da disciplina linguagens formais e máquinas (LFM) para então prosseguir na análise léxica.

Gram´atica

Uma gramática é um mecanismo gerador de senten¸cas de uma dada linguagem. É definida pela quádrupla (VN, VT, P, S), onde: VN representa o conjunto de s´ımbolos não-terminais

da linguagem; VT representa o conjunto de s´ımbolos terminais ou alfabeto; P ´e um

con-junto de regras de produ¸cão e S é o axioma da gramática (s´ımbolo inicial).

As regras de produ¸c˜ao s˜ao definidas na forma α ⇒ β1 | β2 | . . . | βN, onde α representa

um s´ımbolo n˜ao-terminal e os βN representam senten¸cas podendo conter tanto s´ımbolos

(20)

Seqüência de Deriva¸cão

Entende-se por deriva¸c˜ao ao processo de substitui¸c˜ao de α por um dos βN na regra de

produ¸cão, desta forma obtendo-se uma nova senten¸ca que por sua vez, pode ser novamente derivada por outra regra. Uma seqüência de deriva¸cão é uma série de deriva¸cões sucessivas que permitem a gera¸cão de uma determinada senten¸ca da linguagem.

Gram´atica Regular

Uma gramática é dita ser regular se todas as suas regras de produ¸cão respeitam a forma

A → αB ou A → α, onde A,B são s´ımbolos não-terminais e α é uma senten¸ca contendo

somente s´ımbolos terminais.

Gramática Linearmente à Esquerda e à Direita

Quando uma regra de produ¸cão é da forma A → αB, ou seja, novos s´ımbolos não-terminais são inseridos à direita da senten¸ca, diz-se se tratar de uma gramática linearmente à direita.

Se a produ¸cão for da forma A → Bα denomina-se como linearmente à esquerda. Expressões Regulares

Uma expressão regular representa uma determinada linguagem através de ‘fórmulas’ in-dutivas.

Simbologia adotada:

ε = senten¸ca vazia (comprimento = 0);

a | b = representa uma sele¸c˜ao entre a senten¸ca a ou b;

A∗ = conjunto de todas as senten¸cas de comprimento ≥ 0 sobre A;

A+ = A∗− {ε} = fechamento positivos sobre A

A? _{= representa que a express˜ao A ocorre zero ou uma vez.}

Exemplos: Digito(Digito)∗ _{= representa a descri¸cão de números inteiros.} Letra(Letra|Digito)∗ _{= representa a descri¸cão de identificadores.}

3.3.1 Exerc´ıcios Propostos

1. Defina express˜oes regulares e sua respectiva gram´atica regular para as seguintes linguagens:

• todas as palavras contendo a e/ou b.

• todas as palavras contendo a e/ou b com sufixo aa.

• todas as palavras contendo a e/ou b com aaa como sub-palavra. • todas as palavras contendo a e/ou b com exatamente dois b.

(21)

P: S → 0S | A

A → A1 | B B → 0 | 1 | ε

3.4 Especifica¸c˜

ao e Reconhecimento de Tokens

A especifica¸cão de tokens é feita através de expressões regulares e reconhecida através dos reconhecedores de gramáticas regulares chamados de autômatos finitos.

Exemplo:

< Numero > → < Digitos >< Frac Opc >< Exp Opc > < Frac Opc > → . < Digitos >| ε

< Digito > → 0 | 1 | 2 | . . . | 9

esta gramática é capaz de reconhecer números inteiros como 1, 100, 1234, etc. e também números reais expressos ou não por nota¸cão exponencial como: 1.5, 10.34, 1.3e15, 1E+2; porém, é incapaz de reconhecer números como 1., sem a parte fracionária. A figura 3.3 reconhece esta gramática, enquanto que a figura 3.4 reconhece identificadores simples1_.

0

1

8

DÍGITO DIGITO . INICIO * Retornar(Num_Inteiro, Obter_Token())

2

DIGITO

3

DÍGITO

4

E | e + | -

5

DIGITO

6

DÍGITO

7

* Retornar(Num_Real, Obter_Token()) OUTRO OUTRO E | e DIGITO OUTRO

Figura 3.3: Autˆomato finito de reconhecimento de n´umeros inteiros e reais

O reconhecimento de strings é apresentado na figura 3.5, onde “caracteres válidos” representa o alfabeto válido para strings, geralmente letras, números, espa¸cos e sinais ortográficos.

Exerc´ıcio: Criar um AFD capaz de reconhecer os tokens da linguagem P ASCALjr:

s´ımbolos (Dois Pontos, Ponto e V´ırgula, V´ırgula, Abre e Fecha Parênteses, Atribui¸cão), Operadores Relacionais e Aritméticos, Constante Caracter e identificadores de sub-rotinas

(22)

0

1

2

LETRA OU DÍGITO

LETRA OUTRO

INICIO

* Retornar(ID, Obter_Token())

Figura 3.4: AFD de reconhecimento de identificadores simples

0

1

CARACTERES VÁLIDOS " INICIO

2

Retornar(String,Obter_Token()) "

Figura 3.5: AFD de reconhecimento de strings

(iniciam obrigatoriamente com ‘ ’ e tem pelo menos 2 caracteres), e ainda, ser capaz de tratar os caracteres nulos: espa¸cos, enter, tab e coment´arios, sem reconhecer token.

Reconhecendo palavras reservadas como identificadores simples:

Criar uma fun¸cão de identifica¸cão de palavras reservadas (enumera¸cão) que retorna a classe palavra reservada ou identificador.

USO: Retornar(ObterClasse(Lexema),Lexema) Erros L´exicos

1. ‘Caracter Inv´alido’ : uso de um caracter (simbolo) de entrada (arquivo fonte)

que n˜ao perten¸ca ao alfabeto da linguagem. Exemplo: # ou %

2. ‘Delimitador N˜ao Balanceado’ : defini¸c˜ao de uma cadeia literal (ou constante

caracter) sem o correto balanceamento das aspas. Exemplo: “Entrada de Dados 3. ‘Número Real Inválido’ : defini¸cão incorreta ou incompleta de um número real.

Exemplos: 1., 1.0e3, .8, 1e+

O código abaixo apresenta algum erro léxico? Apresente a lista léxica. begin ; <>media==10.5E-5

/===//%_ M´edia 1.P Teste?

Solu¸c˜ao:

begin Palavra Reservada ; S´ımbolo Ponto e Virgula

(23)

<> Operador Relacional Diferente

media Identificador

= Operador Relacional de Igualdade = Operador Relacional de Igualdade 10.5E-5 N´umero Real

/= S´ımbolo de Atribui¸c˜ao

= Operador Relacional de Igualdade = Operador Relacional de Igualdade Teste Identificador

? S´ımbolo Interroga¸c˜ao

3.4.1 Trabalho Pr´

atico #1

Implementar um módulo (sub-rotina) analisador léxico para um protótipo de compilador para a linguagem P ASCALjr vista em aula.

Caracter´ısticas: Do m´odulo scanner:

• A sub-rotina retorna um token (classe e lexema) cada vez que for chamada. • Considera que o programa fonte para análise já está aberto.

• N˜ao retorna nada quando atingir o fim de arquivo (flag de controle). • Implementa um AFD para o reconhecimento de tokens.

Do programa a ser criado:

• Abre um arquivo fonte para an´alise.

• Chama (sucessivas vezes) a rotina de scanner e exibe o valor do token. • Fecha o arquivo fonte ao final da compila¸c˜ao.

• Pára o processo de compila¸cão caso um erro seja encontrado. • Exibe erros de compila¸cão (se ocorrerem) ou mensagem de sucesso.

Crit´erios de Avalia¸c˜ao:

• Implementa¸c˜ao usando linguagem C ou C++.

• Entrega de fontes e execut´avel (em um arquivo zipado) via disquete/CD ou e-mail: rsilva@joinville.udesc.br ou professor.rogerio@gmail.com

(24)

• Grupo de 02 alunos (m´aximo).

• Valor do trabalho: 10.0 (25% da nota pr´atica). • Data de Entrega: A Definir

• Puni¸c˜oes:

– de 10% por cada an´alise incorreta.

– de 20% do valor do trabalho por dia de atraso.

– de 20% do valor do trabalho para a entrega não conforme dos arquivos pedidos. – de 50% do valor do trabalho para o caso de não executar ou travar (após teste

em 2 computadores, sendo um o do professor).

– de 100% do valor do trabalho para o caso de c´opias (mesmo de trabalhos de semestres anteriores).

• Prazo máximo para defesa e argui¸cão sobre o trabalho: 5 dias letivos após entrega. • Puni¸cões:

– de 25% para argui¸cão não respondida ou respondida incorretamente. Obs.: A argui¸cão é individual.

(25)

Cap´ıtulo 4

An´

alise Sint´

atica

4.1 O Papel do Analisador Sint´

atico

A análise sintática constitui a segunda etapa de um tradutor. Sua fun¸cão é verificar se as constru¸cões usadas no programa estão gramaticalmente corretas. Normalmente, as estruturas sintáticas válidas são especificadas através de uma gramática livre de contexto. Dada uma GLC e uma senten¸ca (programa fonte) s, o objetivo do parser é verificar se s pertence a GLC, através da constru¸cão de uma árvore de deriva¸cão.

O processo de constru¸cão dessa árvore pode ser feito de forma expl´ıcita (construindo-se o TDA) ou impl´ıcita, através de chamadas recursivas das rotinas que aplicam as regras de produ¸cão da gramática durante o reconhecimento.

Existem duas estrat´egias b´asicas: Descendente (Top-Down) e Ascendente

(Bottom-Up). Na estratégia top-down constrói-se a árvore a partir da raiz em dire¸cão às folhas

(tokens), enquanto que na bottom-up, o processo é invertido e a constru¸cão é realizada partindo-se das folhas, agrupando-se os tokens até que a raiz da árvore seja gerada.

A árvore gramatical é então a sa´ıda para as próximas fases da compila¸cão. Revisão sobre Gramáticas Livre de Contexto (GLC)

Uma gramática livre de contexto é qualquer gramática da forma: A → α, onde A é um s´ımbolo não-terminal e α um elemento pertencente a (VN ∪ VT)∗.

Exemplo de produ¸c˜oes de uma G.L.C.: S → SS+ | SS∗ | a. ´

Arvores de Deriva¸c˜ao ´

Arvore de deriva¸cão é a representa¸cão gráfica de uma deriva¸cão de senten¸ca.

Exemplo: Considerando a gramática abaixo, gerar árvore de deriva¸cão que comprova que a senten¸ca 45 é válida (ver Figura 4.1).

(26)

< Numero > → < Num >

< Num > → < Num >< Digito >|< Digito > < Digito > → 0 | 1 | 2 | . . . | 9

<Numero>

<Num>

<Digito>

4

5

Figura 4.1: Exemplo de Árvore Sintática Deriva¸cão mais à Esquerda e mais à Direita

Deriva¸cão mais à esquerda é obtida por gramáticas que geram inicialmente, os s´ımbolos mais à esquerda da senten¸ca sob análise; analogamente para as deriva¸cão mais à direita. Exemplo: Seja a gramática: E → E + E | E − E | E ∗ E | E/E | (E) | x. Pode obter a expressão x+x*x de duas formas, conforme a figura 4.2:

E

X

E

+

E

*

X

E

X

E

_E

+

_E

E

*

X

Figura 4.2: Deriva¸cão à Esquerda e à Direita

Exerc´ıcio: Para a gram´atica G = ({S,A},{0,1},P,S) sendo P: S → 0S | A A → 1A | 1,

(27)

4.2 An´

alise Sint´

atica Ascendente - BOTTOM UP

A cria¸cão da árvore gramatical é realizada no sentido folhas → raiz, ou seja, gera¸cão de senten¸cas é feita através do processo de empilhar e reduzir. A idéia é “reduzir” a senten¸ca original até o axioma da gramática através de sucessivas substitui¸cões por não-terminais.

Exemplo: S → aABe A → Abc | b B → d

Verificar se a senten¸ca abbcde pode ser reduzida pela gram´atica: abbcde ↓ aAbcde ↓ aAde ↓ aABe ↓ S

4.2.1 Algoritmo “Empilhar-e-Reduzir”

Este procedimento de análise sintática ascendente consiste de dois passos: 1. Escolha de um candidato α a redu¸cão (handle);

2. Redu¸cão do candidato pelo não-terminal A à esquerda da produ¸cão A → α;

3. Repetir os passos 1 e 2 at´e que a senten¸ca tenha sido reduzida ao axioma da gram´atica.

Um candidato é uma subcadeia que reconhece o lado direito de uma produ¸cão e cuja redu¸cão ao não-terminal do lado esquerdo da produ¸cão representa um passo ao longo do percurso de uma deriva¸cão.

´

E denominado de “poda do candidato” ao processo de substitu´ı-lo pelo não-terminal à esquerda da regra de produ¸cão, obtendo desta forma, uma redu¸cão na senten¸ca sob análise.

Uma forma conveniente de implementar um analisador sintático de empilhar e reduzir é usar uma pilha para guardar os s´ımbolos gramaticais. O analisador sintático opera empilhando zero ou mais s´ımbolos até que um candidato surja no topo da pilha. Uma poda do candidato é então feita. Repete-se este processo até que no topo da pilha esteja o axioma da gramática ou um erro seja encontrado (nenhuma poda seja poss´ıvel).

Exemplo: E → E + E | E − E | E ∗ E | E/E | (E) | id. Senten¸ca sob an´alise: id + id * id

(28)

Entrada Pilha Ac¸˜ao id+id*id $ empilhar

+id*id $id reduzir E → id +id*id $E empilhar

id*id $E+ empilhar *id $E+id reduzir E → id *id $E+E reduzir E → E + E *id $E empilhar

id $E* empilhar $ $E*id reduzir E → id $ $E*E reduzir E → E ∗ E $ $E aceitar

São apenas 4 as opera¸cões poss´ıveis por este método: empilhar, reduzir, aceitar ou erro.

Conflitos durante a An´alise Sint´atica de Empilhar e Reduzir

Existem gram´aticas livres de contexto para as quais o procedimento empilhar-e-reduzir n˜ao pode ser utilizado, porque, em certos casos, o analisador pode atingir um estado tal, que:

• Mesmo conhecendo toda a pilha e o pr´oximo s´ımbolo de entrada, n˜ao pode decidir

entre empilhar e reduzir. Isto ´e chamado de conflito empilhar/reduzir.

• Outro conflito poss´ıvel, o reduzir/reduzir, ocorre quando n˜ao ´e poss´ıvel optar entre

as diversas redu¸c˜oes poss´ıveis.

4.3 An´

alise Sint´

atica Descendente - TOP DOWN

A análise sintática top-down pode ser vista como uma tentativa de se encontrar uma deriva¸cão mais à esquerda para uma cadeia de entrada, ou ainda, como de se construir a árvore gramatical a partir da raiz em dire¸cão às folhas.

O processo de análise pode ser feito de forma recursiva ou não, onde a forma recur-siva pode ser realizada com ou sem retrocesso (backtracking), dependendo das regras de produ¸cão gramática.

An´alise Sint´atica Recursiva com Retrocesso

A constru¸cão da árvore é feita a partir da raiz, expandindo sempre o não-terminal mais à esquerda primeiro. Quando existe mais de uma regra de produ¸cão para o não-terminal a ser expandido, a op¸cão escolhida é fun¸cão do s´ımbolo corrente na fita de entrada (token sob análise). Se o token não define a produ¸cão a ser usada, então todas as alternativas vão ser tentadas até que se obtenha sucesso (ou todas falhem).

Exemplo 1:S → cAd A → ab | a.

Verificar se a gram´atica gera a senten¸ca cad. Exemplo 2: S → cA A → aB B → D | bD D → d

(29)

S

c

A

d

S

c

A

d

a

b

S

c

A

d

a

falha!

sucesso!

Figura 4.3: An´alise descendente com backtracking

A análise sintática é dita ser uma análise sintática preditiva caso não seja necessário a realiza¸cão de retrocesso no processo e pode ser implementada de forma recursiva ou não (através da utiliza¸cão de uma pilha).

4.3.1 An´

alise Sint´

atica Preditiva

O processo de análise preditiva (sem retrocesso) exige modifica¸cões na gramática original para análise:

• elimina¸cão de recursão à esquerda;

• fatora¸cão à esquerda das regras de produ¸cão;

• os n˜ao-terminais que apresentarem mais de uma regra de produ¸c˜ao, tenham o

pri-meiro terminal derivável único (capaz de identificar a produ¸cão a ser analisada). Ou seja, deve ser poss´ıvel determinar, para um dado s´ımbolo a, qual das produ¸cões deve ser derivada.

Exemplo: No exemplo 2 visto acima a produ¸cão B → D | bD D → d apresenta duas alternativas de deriva¸cão. A escolha é feita a partir do primeiro terminal para cada regra (d ou b).

O conjunto de s´ımbolos terminais que iniciam senten¸cas deriváveis a partir de uma produ¸cão b é denominado FIRST(β) ou PRIMEIRO(β).

Exemplo: FIRST(S) = {c}; FIRST(A) = {a}; FIRST(B) = {b, d}; FIRST(D) = {d}. As regras que definem o conjunto FIRST s˜ao:

(30)

• Se β → ε, ent˜ao ε ´e um elemento de FIRST.

• Se β → aδ, sendo a um s´ımbolo terminal, ent˜ao a pertence a FIRST.

• Se β → X1X2. . . XN, sendo X1X2. . . XN elementos n˜ao-terminais, ent˜ao FIRST(β)

= FIRST(X1). Se em FIRST(X1) constar o elemento ε, ent˜ao incluir FIRST(X2)

em FIRST(β) e assim por diante. Elimina¸cão da Recursão à Esquerda

´

E poss´ıvel que um analisador gramatical descendente recursivo execute indefinidamente. O problema ocorre em produ¸c˜oes recursivas `a esquerda, tais como: A → A0 | 1.

Este tipo de produ¸cão gera uma árvore que cresce recursivamente à esquerda até que um terminal 1 seja gerado à esquerda da seqüência de 0’s.

Para se evitar isso deve-se substituir o elemento causador da recursão à esquerda, que é do tipo A → Aα | β, onde α, β representam outras seqüências de terminais e não-terminais não iniciadas por A .

Para eliminar a recursão à esquerda deve-se reescrever essa produ¸cão, da seguinte forma: A → βA0 _{e A}0 _{→ αA}0 _{| ε. A figura 4.4 apresenta as árvors de deriva¸cão para uma}

senten¸ca qualquer da forma βαααα.

4.3.2 Exerc´ıcios Propostos

• Para as gramáticas abaixo elimine sua recursão à esquerda.

1. G=({S,A,B},{a,b},P,S) onde P: S → Sa | Sb | A | B A → Aa | a B → bB | b 2. G=({S,A},{0,1,2},P,S) onde P: S → S0 | S1 | A | 0 A → S2

3. G=({S,A,B},{0,1},P,S) onde P: S → SA | A A → A0B | 0 B → B1 | ε 4. G=({A},{0,1},P,A) onde P: A → A0A | 1

• Apresente a cláusula First para as produ¸cões das gramáticas abaixo:

1. G=({S,X,Y,Z},{0,1,2,3},P,S) onde P: S → XY Z X → OXO | 1 Y → 2Y 2 | 3 Z → 0Z1 | ε

2. G=({S,A,B,C},{a,b,c},P,S) onde P: S → Sa | aA A → aA | Bb B → cB | ε 3. G=({S,X,Y,Z},{0,1},P,S) onde P: S → XY Z X → 0X | 1Y | ε Y → 1Y |

ε Z → 01Z | ε

Fatora¸c˜ao `a Esquerda

A fatora¸cão à esquerda é uma transforma¸cão gramatical útil para a cria¸cão de uma gramática adequada à análise sintática preditiva. A idéia básica está em, quando não estiver claro qual das duas produ¸cões alternativas usar para expandir um não-terminal A, estarmos capacitados a reescrever as produ¸cões A e postergar a decisão até que tenhamos visto o suficiente da entrada para realizarmos a escolha certa.

(31)

α

A

β

A

A'

α

A

α

A

α

A

α

β

A'

α

_A'

α

_A'

α

_A'

ε

Figura 4.4: Exemplos de Recursão à Esquerda e à Direita

Ao analisarmos o token a não há como saber qual das duas alternativas utilizar (o comando com ou sem o “cZ”). Quando houver duas produ¸cões A → αβ1 | αβ2, devemos

postergar a decis˜ao expandindo A para αA0 _{e ent˜ao expandir A’ para β}

1 | β2. Fatorando

esta gram´atica temos: S → aXbY S0 _S0 _{→ cZ | ε.}

4.4 Reconhecedor de Gram´

aticas Preditivas

Descen-dentes

Um reconhecedor preditivo descendente (orientado por tabela) compreende uma fita de entrada, uma pilha e uma tabela de análise, conforme é mostrado na figura 4.5. A fita contém a senten¸ca a ser analisada seguida de $. A pilha contém os s´ımbolos utilizados durante o processo de análise. A tabela de análise é uma matriz com n linhas (correspon-dendo aos s´ımbolos não-terminais) e t+1 colunas (correspon(correspon-dendo aos s´ımbolos terminais mais o s´ımbolo especial $).

Considerando X o elemento no topo da pilha e a o s´ımbolo de entrada sob análise, o analisador executa uma de três a¸cões poss´ıveis:

1. se X = a = $, o analisador p´ara, aceitando a senten¸ca;

2. se X = a 6= $, o analisador desempilha a e avan¸ca o cabe¸cote de leitura para o pr´oximo s´ımbolo na fita de entrada;

3. se X é um s´ımbolo não-terminal, o analisador consulta a tabela M[X,a] da tabela de análise. Essa entrada poderá conter uma produ¸cão da gramática ou ser vazia. Supondo M[X,a] = { X → XY Z }, o analisador substitui X (no topo da pilha) por ZYX (ficando X no topo). Se M[X,a] for vazio isto é um erro sintático.

Na implementa¸cão de um analisador sintático, a maior dificuldade está na constru¸cão da tabela de análise. Para construir essa tabela, é necessário computar duas fun¸cões associadas à gramática: FIRST e FOLLOW.

(32)

Tabela de

Análise

Parser

a + b $

X

Y

Z

Figura 4.5: Funcionamento de um Analisador Sint´atico Descendente

O algoritmo para calcular a fun¸cão FIRST já foi visto anteriormente. O algoritmo para calcular a fun¸cão FOLLOW é apresentado a seguir:

1. Se S é o s´ımbolo inicial da gramática e $ é o marcador de fim de senten¸ca, então $ está em FOLLOW(S);

2. Se existe produ¸c˜ao do tipo A → αXβ, ent˜ao todos os terminais de FIRST(β), fazem parte de FOLLOW(X);

3. Se existe produ¸c˜ao do tipo A → αX, ou A → αXβ, sendo que β → ε, ent˜ao todos os terminais que estiverem em FOLLOW(A) fazem parte de FOLLOW(X).

Dada a gramática G = ({E, E0_{, T, T}0_{, F }, {∨, ∧, ¬, id}, P, E) para expressões lógicas:}

E → T E0 E0 _{→ ∨T E}0 _{| ε} T → F T0 T0 _{→ ∧F T}0 _{| ε} F → ¬F | id Cl´ausula First

Convém iniciar o processo pelos não-terminais que gerem conjuntos triviais. No exemplo, temos os não-terminais F, E’ e T’ que só geram elementos terminais (ou vazio):

F = {¬, id} E0 _{= {∧, ε}}

T0 _{= {∨, ε}}

Como T deriva apenas em FT’ e F n˜ao leva em vazio, conclui-se que FIRST(T) = FIRST(F). E ainda, FIRST(E) = FIRST(T) = FIRST(F) = {¬, id}.

(33)

Cl´ausula Follow

Pela regra 1 temos que FOLLOW(E) = {$}. Pela regra 3 tem-se que FOLLOW(E) = FOLLOW(E’). FOLLOW(T) é obtido a partir da união dos conjuntos obtidos pela aplica¸cão da regra 2 em (E0 _{→ ∨T E}0_{) e regra 3 em (E}0 _{→ ε). Sendo assim temos:}

FOLLOW(T) = FIRST(E’) + FOLLOW(E’) = {∨, $}.

FOLLOW(T’) = FOLLOW(T) pela aplica¸c˜ao da regra 3 em T → F T0_{. E finalmente,}

FOLLOW(F) = FIRST(T’) + FOLLOW(T’). Aplica¸c˜ao das regras 2 e 3 em T0 _{→ ∧F T}0 _| ε, ou seja FOLLOW(F) = {∨, ∧, $}.

4.4.1 Algoritmo para Constru¸c˜

ao da Tabela de An´

alise

M´etodo:

• Para cada produ¸c˜ao X → α, execute os passos 2 e 3 (para criar a linha X da tabela

M);

• Para cada terminal a de FIRST(α), adicione a produ¸c˜ao X → α a M[X,a];

• Se FIRST(α) inclui a palavra vazia, ent˜ao adicione X → α a M[X,b] para cada b

em FOLLOW(X);

Aplicando-se o algoritmo acima à gramática de expressões lógicas temos:

Para E → T E0 _{tem-se FIRST(TE’) = {¬, id} ent˜ao, M[E, ¬] = M[E,id] = E → T E}0_.

Para E0 _{→ ∨T E}0 _{tem-se FIRST(∨T E}0_{) = {∨} ent˜ao, M[E’, ∨] = E}0 _{→ ∨T E}0_.

Para E0 _{→ ε tem-se FOLLOW(E’) = {$} ent˜ao, M[E’, $] = E}0 _{→ ε.}

Para T → F T0 _{tem-se FIRST(FT’) = {¬, id} ent˜ao, M[T, ¬] = M[T,id] = T → F T}0_.

Para T0 _{→ ∧F T}0 _{tem-se FIRST(∧F T}0_{) = {∧} ent˜ao, M[T’, ∧] = T}0 _{→ ∧F T}0_.

Para T0 _{→ ε tem-se FOLLOW(T’) = {∨, $} ent˜ao, M[T’, ∨] = M[T’,$] = T}0 _{→ ε.}

Para F → ¬F tem-se FIRST(¬F ) = {¬} ent˜ao, M[F, ¬] = F → ¬F . Para F → id tem-se FIRST(id) = {id} ent˜ao,M[F,id] = F → id.

id ∨ ∧ ¬ $ E E → T E0 _{E → T E}0 E’ E0 _{→ ∨T E}0 _E0 _{→ ε} T T → F T0 _{T → F T}0 T’ T0 _{→ ε} _T0 _{→ ∧F T}0 _T0 _{→ ε} F F → id F → ¬id

Se, em cada entrada da Tabela de Análise, existe apenas uma produ¸cão, então a gramática que originou a tabela é dita ser do tipo LL(1), ou seja: as senten¸cas geradas pela gramática são pass´ıveis de serem analisadas da esquerda para a direita (Left to Right), produzindo uma deriva¸cão mais à esquerda (Leftmost Derivation), levando em conta apenas um s´ımbolo da entrada.

Exerc´ıcio: Considerando a gram´atica para a linguagem a ser reconhecida pelo

(34)

4.4.2 Projeto de uma Gram´

atica para um Analisador Sint´

atico

Preditivo Ascendente

Analisa gram´aticas do tipo LR(k), ou seja, left-to-right e rightmost derivation com k s´ımbolos lidos da entrada a cada etapa de an´alise.

Porque usar an´alise sint´atica ascendente LR?

• porque é poss´ıvel ser elaborados reconhecedores para todas as GLC, sem restri¸cão; • porque o método de análise LR é tão eficiente quanto os demais métodos de análise; • porque um analisador LR consegue encontrar um erro sintático o mais cedo poss´ıvel

em uma an´alise da esquerda para a direita.

As gramáticas GLC para as quais é viável a implementa¸cão manual de reconhece-dores ascendentes (devido à complexidade de implementa¸cão) apresentam as seguintes restri¸cões:

• nenhum lado direito das produ¸c˜oes seja ε

• nenhum lado direito tenha dois n˜ao-terminais adjacentes (gram´atica de operadores)

Exemplo: E → E + E | E − E | E ∗ E | E/E | (E) | −E | id

Um forma simples de se implementar um reconhecedor ascendente é através da análise de precedência de operadores, porém, justamente devido à sua simplicidade, uma série de restri¸cões estão associadas a estes:

• dificuldades de analisar operadores com mais de um significado semˆantico (ex.:

ope-rador unário e binário de subtra¸cão)

• somente uma pequena classe de linguagens pode ser analisada por esta alternativa,

apesar disso, j´a foram desenvolvidos analisadores de precedˆencia para linguagens inteiras.

Na análise de precedência temos definidos as rela¸cões de precedência entre os opera-dores, sendo (a < • b) onde a confere precedência a b; (a = b) onde a possui a mesma precedência de b e (a • > b) a tem precedência sobre b.

Seja o exemplo da gramática anterior onde a precedência dos operadores é dada por: id + * $

id • > • > • >

+ < • • > < • • >

* < • • > • > • >

$ < • < • < •

Analisando a expressão: id+id*id temos as seguintes rela¸cões de precedência: $ < • id • > + < • id • > ∗ < • id • > $

(35)

1. Percorrer a cadeia, a partir da esquerda até que o primeiro • > seja encontrado. 2. Percorrer, então, de volta (para a esquerda) por sobre quaisquer rela¸cões (=) até

que < • seja encontrado.

3. O handle contém tudo à esquerda do primeiro • > e à direita do < •, incluindo quaisquer não-terminais presentes.

No exemplo acima, o primeiro handle é dado pelo primeiro id encontrado que pode ser reduzido para o não-terminal E (segundo a gramática vista), seguido pelos próximos dois ids da senten¸ca. A seguir, a senten¸ca obtida ficaria $ E + E * E $; removendo-se os não-terminais e acrescentando-se as rela¸cões de precedência temos: $ < • + < • ∗ • > $, indicando que a próxima redu¸cão deve ser realizada sobre o operador “*” (e seus respec-tivos operandos associados “E* E”).

Devido ao fato da sua implementa¸cão não ser trivial, a solu¸cão de implementa¸cão mais viável para este tipo de gramática é fazer uso de um gerador de analisadores sintáticos, como o YACC ou BISON.

4.4.3 Projeto de uma Gram´

atica para um Analisador Sint´

atico

Preditivo Descendente

Considerando o uso de analisadores sintáticos descendentes preditivo algumas preocupa-¸cões quanto a gramática a ser utilizada, devem ser tomadas: eliminar ambigüidade, eli-minar as recursões à esquerda e fatorar à esquerda a gramática.

Analisando um Programa Simples

A seguir, ´e apresentado um exemplo de um programa simples na linguagem P ASCALjr:

var: float N1, N2, M; int Ct; const: int Qtde = 10;

func float _Media(float a,float b) float media; { media = (a+b)/2.0; return media; } main( ) { Ct = 0; do {

print("Digite duas notas:"); scanf(N1,N2);

printl("Media = ",_Media(N1,N2)); Ct ++;

} while(Ct != Qtde); }

(36)

[ Declara¸cão de Variáveis e Constantes ] [ Declara¸cão de Sub-Rotinas ]

<Programa Principal>

onde: [ ] indica se¸cão opcional e <> indica se¸cão obrigatória.

Pode-se descrever esta estrutura na forma de uma regra de produ¸cão de uma GLC da seguinte forma, onde o não-terminal Programa será o axioma da gramática da linguagem

P ASCALjr:

Programa → AreaDecl AreaSubRot Principal Analisando a Se¸cão de Declara¸cão de Variáveis e Constantes

Esta se¸cão declara todas as variáveis e constantes utilizadas pelo programa. É poss´ıvel a declara¸cão de várias áreas de declara¸cão de variáveis e/ou constantes simultaneamente. Um programa pode ainda não conter esta se¸cão.

AreaDecl → AreaDeclVar AreaDecl | AreaDeclConst AreaDecl | ε AreaDeclVar → prVar DoisPt DeclVars

DeclVars → Tipo ListaID PtVirg DeclVars’ DeclVars’ → Tipo ListaID PtVirg DeclVars’ | ε

Tipo → prInt | prFloat | prChar | prString | prBool ListaID → Identificador ListaID’

ListaID’ → Virg Identificador ListaID’ | ε AreaDeclConst → prConst DoisPt DeclConsts

DeclConsts → Tipo ListaIDConst PtVirg DeclConsts’ DeclConsts’ → Tipo ListaIDConst PtVirg DeclConsts’ | ε ListaIDConst → Identificador Atrib Valor ListaIDConst’

ListaIDConst’ → Virg Identificador Atrib Valor ListaIDConst’ | ε Valor → OpAritSubt Numeros | Numeros |

ConstChar | ConstString | prTrue | prFalse Numeros → NumeroInteiro | NumeroReal

Analisando a Se¸cão de Declara¸cão de Procedimentos e Fun¸cões

A se¸cão de declara¸cão de procedimentos e fun¸cões declara todas as sub-rotinas utilizadas pelo programa. É poss´ıvel a declara¸cão de várias áreas de declara¸cão de sub-rotinas simultaneamente. Um programa pode ainda não conter esta se¸cão.

(37)

AreaSubRot → AreaProc AreaSubRot | AreaFunc AreaSubRot | ε

AreaProc → prProc IdentSR AbrePar ListaParam FechaPar AreaDecl BlocoCom

ListaParam → Tipo Identificador ListaParam’ | ε ListaParam’ → Virg Tipo Identificador ListaParam’ | ε

AreaFunc → prFunc Tipo IdentSR AbrePar ListaParam FechaPar AreaDecl BlocoCom

Analisando o Programa Principal

O programa principal é o ponto onde inicia-se a execu¸cão do código fonte. Ela é definida pela fun¸cão “main”. Apesar da linguagem P ASCALjr não permitir a passagem de

parâmetros para esta fun¸cão, ainda sim utilizar-se-ão os parênteses “(” “)” na sintaxe do comando meramente por uma questão didática. Esta se¸cão é obrigatória em qualquer programa.

Principal → prMain AbrePar FechaPar BlocoCom Analisando um Bloco de Comandos

Um bloco de comandos pode ser entendido como um comando composto por uma lista de outros comandos simples (ou outros blocos) podendo (em alguns casos) ser separados por “;” e delimitados por “{” e “}”. Sendo assim:

BlocoCom → AbreChaves ListaCom FechaChaves ListaCom → Comando ListaCom | ε

Analisando o comando Atribui¸c˜ao

Pode ser realizado atrav´es de 7 diferentes operadores: = atribui¸c˜ao simples

(38)

-= atribui¸cão após subtra¸cão (X− = Y ⇔ X = X − Y ) *= atribui¸cão após multiplica¸cão (X∗ = Y ⇔ X = X ∗ Y )

/= atribui¸cão após divisão (X/ = Y ⇔ X = X/Y )obs.:Não prevê divisão por zero ++ atribui¸cão incremental (X + + ⇔ X = X + 1)

- - atribui¸c˜ao decremental (X − − ⇔ X = X − 1)

Exemplo de uma gram´atica que reconhece esses comandos: Atrib → Identificador SimbAtrib Expr |

Identificador SimbAtribSoma Expr | Identificador SimbAtribSubt Expr | Identificador SimbAtribMult Expr | Identificador SimbAtribDivi Expr |

Identificador SimbIncr | Identificador SimbDecr porém, temos problemas de fatora¸cão. Fatorando à esquerda estas produ¸cões temos:

Atrib → Identificador Atrib’ Atrib’ → SimbAtrib Expr |

O comando condicional (sem fatora¸c˜ao) ficaria:

Condic → prIf AbrePar Expr FechaPar Comando | prIf AbrePar Expr FechaPar Comando prElse Comando

e ap´os fatora¸c˜ao teremos:

Condic → prIf AbrePar Expr FechaPar Comando Condic’ Condic’ → prElse Comando | ε

(39)

Analisando os comandos de Repeti¸c˜ao

Os comandos de repeti¸c˜ao podem ser reconhecidos por:

RepetPos → prDo ListaCom prWhile AbrePar Expr FechaPar RepetPre → prWhile AbrePar Expr FechaPar Comando

RepetCont → prFor AbrePar Atrib PtVirg Expr PtVirg Atrib FechaPar Comando

Analisando os comandos para chamada a Sub-Rotinas

Os comandos para chamadas a sub-rotinas incluem o comando < Retorno > que deve ser usado nas chamadas a fun¸c˜oes.

SubRot → IdentSR AbrePar ListaExpr FechaPar Retorno → prReturn Expr

Analisando os comandos de Entrada e Sa´ıda Para os comandos de entrada e sa´ıda temos:

(40)

Entrada → prScanf AbrePar ListaVar FechaPar Saida → prPrint AbrePar ListaExpr FechaPar |

prPrintl AbrePar ListaExpr FechaPar ListaExpr → Expr ListaExpr’ | ε

ListaExpr’ → Virg Expr ListaExpr’ | ε Analisando Expressões Lógicas e Aritméticas

Para descrever senten¸cas que formam expressões aritméticas compostas das cinco opera-¸cões básicas (adi¸cão, subtra¸cão, multiplica¸cão, divisão e potencia¸cão), tendo como ope-randos: identificadores de variáveis e constantes, números inteiros e reais, chamadas a sub-rotinas e ainda permitir o uso de parênteses e do operador unário de sinal “-”; a representa¸cão mais simples poss´ıvel seria:

Identificador | NumeroInteiro | NumeroReal | ConstCaracter | ConstString

Exerc´ıcio: Montar a ´arvore gramatical para a express˜ao 2 ∗ (X − 5.0) + 10/B

Apesar de que, com esta gramática, é poss´ıvel gerar qualquer expressão aritmética sim-ples, esta não leva em considera¸cão todas as restri¸cões já estudadas para a implementa¸cão de reconhecedores de gramática TOP-DOWN.

O primeiro problema que se percebe é o fato da gramática anterior não considerar a questão da precedência de operadores. Para resolver este problema deve-se inserir novos elementos não-terminais à gramática:

ExprAr → ExprAr OpAdic TermoAr |

ExprAr OpSubt TermoAr | TermoAr TermoAr → TermoAr OpMult FatorAr |

TermoAr OpDivi FatorAr | FatorAr

FatorAr → FatorAr OpPote ElementoAr | ElementoAr ElementoAr → AbrePar ExprAr FechaPar |

(41)

OpSubt ExprAr | SubRot |

Exerc´ıcio: Montar a ´arvore gramatical para a express˜ao 2 ∗ (X − 5.0) + 10/B

A idéia é gerar os elementos de menor precedência mais próximos à raiz da árvore sintática e os de maior precedência, mais próximos às folhas.

Novamente temos problemas com a solu¸cão proposta: recursão à esquerda. A nova gramática após realizado o processo (já estudado) de elimina¸cão da recursão à esquerda, temos:

ExprAr → TermoAr ExprAr’

ExprAr’ → OpAdic TermoAr ExprAr’ | OpSubt TermoAr ExprAr’ | ε TermoAr → FatorAr TermoAr’

TermoAr’ → OpMult FatorAr TermoAr’ | OpDivi FatorAr TermoAr’ | ε FatorAr → ElementoAr FatorAr’

FatorAr’ → OpPote ElementoAr FatorAr’ | ε ElementoAr → AbrePar ExprAr FechaPar |

OpSubt ExprAr | SubRot |

Exerc´ıcio: Montar a árvore sintática para a expressão: 2 ∗ (X − 5.0) + 10/B.

Analisando Express˜oes L´ogicas

Uma expressão lógica é, na verdade, uma compara¸cão entre resultados de expressões aritméticas, ou ainda, a união de duas expressões aritméticas através de um operador relacional.

São poss´ıveis ainda, expressões lógicas mais complexas através da união de duas ex-pressões lógicas simples por operadores lógicos.

Expr → TermoLog Expr’ Ternario Ternario → Interrog Expr DoisPt Expr | ε

Expr’ → OpLogAnd TermoLog Expr’ | OpLogOr TermoLog Expr’ | OpLogXor TermoLog Expr’ | ε TermoLog → FatorLog TermoLog’