Compiladores Captulo 1: Introduo 1.

A estrutura global do compilador Este captulo pretende apresentar a estrutura geral de um compilador, sem entretanto entrar em detalhes que s podem ser apresentados aps uma discusso mais longa, aps a apresentao de importantes conceitos e resultados adicionais. Vamos apenas descrever aqui as partes componentes principais de um compilador "tpico", e o seu funcionamento simplificado. O nome compilador, criado nos anos 50, faz referncia ao processo de composio de um programa pela reunio de vrias rotinas de biblioteca; o processo de traduo (de uma linguagem fonte para uma linguagem objeto), considerado hoje a funo central de um compilador, era ento conhecido como programao automtica. Nesse processo de traduo, h duas tarefas bsicas a serem executadas por um compilador:
anlise, em que o texto de entrada (na linguagem fonte) examinado,

verificado e compreendido
sntese, ou gerao de cdigo, em que o texto de sada (na linguagem objeto)

gerado, de forma a corresponder ao texto de entrada. Normalmente, pensamos nessas tarefas como fases do processo de compilao, mas no absolutamente necessrio que a anlise de todo o programa seja completada antes que o primeiro trecho de cdigo objeto seja gerado: essas duas fases podem ser intercaladas. Como exemplos, um compilador pode analisar cada comando do programa de entrada, e gerar imediatamente o cdigo de sada correspondente a esse comando; alternativamente, o compilador pode esperar o fim da anlise de cada unidade de programa (rotina, procedimento, funo, ...) para ento gerar o cdigo correspondente unidade. Para melhor aproveitamento de memria durante sua execuo, compiladores mais antigos costumavam ser divididos em vrios passos, executados em seqncia, freqentemente de forma aparente para o usurio. Cada passo executa parte do processo de traduo, transformando o cdigo fonte em alguma forma intermediria adequada, cada vez mais prxima do cdigo objeto final. Naturalmente, a tarefa de anlise deve ter como resultado uma representao do programa fonte que contenha informao suficiente para a gerao do programa objeto correspondente. Normalmente, essa representao (conhecida como representao intermediria) complementada por tabelas que contm informao adicional sobre o programa fonte. Em alguns casos, a representao intermediria pode tomar a forma de um programa em uma linguagem intermediria, a partir da qual seja fcil a traduo para a linguagem objeto desejada. Independentemente da forma que possa tomar a representao intermediria, ela deve conter toda a informao necessria para a gerao do cdigo objeto. Uma das caractersticas da representao intermediria que as estruturas de dados empregadas devem garantir acesso eficiente a todas as informaes, podendo, para isso, ser conveniente algum grau de redundncia. Normalmente esse acesso consideravelmente
J.L.Rangel - Compiladores - 1-1

mais rpido que o acesso ao programa fonte em formato de texto, ou a cdigo executvel em alguma mquina real.

Uma das formas mais comuns de tabela utilizada nessa representao intermediria a tabela de smbolos, em que se guarda para cada identificador (smbolo) usado no programa as informaes correspondentes, tais como natureza (varivel, constante, procedimento, ...), tipo, endereo, espao ocupado, etc. Um dos modelos possveis para a construo de compiladores faz a separao total entre o front-end, encarregado da fase de anlise, e o back-end, encarregado da gerao de cdigo, de forma que
front-end e back-end se comunicam apenas atravs da representao

intermediria;
o front-end depende exclusivamente da linguagem fonte (e, portanto,

independe da linguagem ou da mquina objeto);

o back-end depende exclusivamente da linguagem objeto (e, portanto,

independe da linguagem fonte). Essa idia visa simplificar a implementao de vrias linguagens de programao para vrias mquinas: em princpio, basta escrever um front-end para cada linguagem, e um back-end para cada mquina. Ou seja, para implementar m linguagens em n mquinas, precisamos fazer m front-ends e n back-ends, em vez de mn compiladores completos. Este esquema mais facilmente aplicado quando existe alguma semelhana entre as mquinas e o mesmo acontece entre as linguagens. Os primeiros compiladores (da linguagem FORTRAN) foram construdos quase quarenta anos atrs (1957), quando tcnicas de projeto e implementao de linguagens ainda no estavam muito desenvolvidas. Uma boa idia da tecnologia disponvel para a implementao dos primeiros compiladores pode ser obtida em [Rosen1], onde esto reunidos alguns dos papers mais importantes dos anos 50. Quase todos os compiladores fazem hoje uso de uma tcnica chamada traduo dirigida pela sintaxe, em que as regras de construo do programa fonte so utilizadas diretamente para guiar todo o processo de compilao. Assim, por exemplo, a regra da gramtica da linguagem fonte que contm o sinal de + deve ser a que deflagra o processo de gerao da instruo ADD. 2. Anlise
1S.

Rosen, Programming Systems and Languages, McGraw-Hill, 1967. J.L.Rangel - Compiladores - 1-2

Normalmente associamos a sintaxe a idia de forma, em oposio a semntica, associada a significado, contedo. Assim, em princpio, a sintaxe de uma linguagem de programao deve descrever todos os aspectos relativos forma de construo de programas corretos na linguagem, enquanto a semntica deve descrever o que acontece quando o programa executado. Portanto, toda a anlise est relacionada com sintaxe, e a semntica deveria corresponder apenas gerao de cdigo, que deve preservar o significado do programa fonte, construindo um programa objeto com o mesmo significado. Uma observao cabe aqui. Do ponto de vista da teoria, apenas programas corretos pertencem linguagem, e os programas incorretos no tem nenhum interesse. Um programa ou da linguagem (est correto) ou no da linguagem (est incorreto). Do ponto de vista da prtica, entretanto, no momento em que avisa que um programa est incorreto, um bom compilador deve ser capaz de indicar como esse fato foi descoberto, e, de alguma forma, ajudar o usurio a transform-lo em um programa correto. O tratamento de erros deve incluir mensagens informativas e um reparo (ou recuperao) do programa incorreto, para que a anlise possa ser continuada e outros erros sinalizados. Por razes de convenincia prtica, a fase de anlise normalmente se subdivide em anlise lxica, anlise sinttica e anlise semntica. Sabe-se que possvel representar completamente a sintaxe de uma linguagem de programao atravs de uma gramtica sensvel ao contexto2, mas como no existem algoritmos prticos para tratar essas gramticas, a preferncia recai em usar gramticas livres de contexto. Assim, a separao entre anlise sinttica e anlise semntica dependente de implementao: deixa-se para a anlise semntica a verificao de todos os aspectos da linguagens que no se consegue exprimir de forma simples usando gramticas livres de contexto. Por outro lado, sabe-se que a implementao de reconhecedores de linguagens regulares (autmatos finitos) mais simples e mais eficiente do que a implementao de reconhecedores de linguagens livres de contexto (autmatos de pilha). Como possvel usar expresses regulares para descrever a estrutura de componentes bsicos das linguagens de programao, tais como identificadores, palavras reservadas, literais numricos, operadores e delimitadores, essa parte da tarefa de anlise (anlise lxica) implementada separadamente, pela simulao de autmatos finitos. Assim, a anlise lxica tem como finalidade a separao e identificao dos elementos componentes do programa fonte; normalmente esses componentes so especificados atravs de expresses regulares. A anlise sinttica deve reconhecer a estrutura global do programa, descrita atravs de gramticas livres de contexto. A anlise semntica se encarrega da verificao das regras restantes. Essas regras tratam quase sempre da verificao de que os objetos so usados no programa da maneira prevista em suas declaraes, por exemplo verificando que no h erros de tipos.

ser usadas tambm gramticas de dois nveis, como as gramticas de van Wijngaarden, que foram usadas para descrever a sintaxe completa da linguagem Algol 68. Ver: A. van Wijngaarden (Editor) Report on the Algorithmic Language Algol-68, Numerische Mathematik, 14, (1969) pp 79218 J.L.Rangel - Compiladores - 1-3

2Podem

No existe um modelo matemtico inteiramente adequado para descrever o que deve ser verificado na anlise semntica, ao contrrio do que acontece nas duas outras fases da anlise, mas mecanismos como gramticas de atributos tem sido usados com sucesso para simplificar a construo de analisadores semnticos. Existem diversas ferramentas de software que auxiliam a construo de compiladores, construindo mdulos do compilador a partir de especificaes. Considerase normal, hoje em dia, o uso dessas ferramentas, sendo as mais comuns os construtores de analisadores lxicos e sintticos, caso em que os mdulos gerados automaticamente so tanto ou mais eficazes que os construdos a mo. J possvel especificar totalmente a semntica de uma linguagem de programao, e construir automaticamente um compilador para a linguagem a partir dessa especificao. Entretanto, ainda no possvel a construo totalmente automtica de compiladores de qualidade comercial (production quality), razo pela qual partes dos compiladores so ainda escritas mo. Em geral, um compilador passa por um processo de ajuste (sintonizao, fine tuning), em que se determina quais as partes do compilador que consomem mais recursos (tempo de execuo, espao em memria), e ento se procura re-escrever estas partes de forma melhorada. 3. Anlise lxica Como vimos, cabe anlise lxica a separao e identificao dos elementos componentes do programa fonte; anlise lxica cabe tambm a eliminao dos elementos "decorativos" do programa, tais como espaos em branco, marcas de formatao de texto e comentrios. Isso significa que, aps a anlise lxica, itens como identificadores, operadores, delimitadores, palavras chave, palavras reservadas esto identificados, normalmente atravs de duas informaes: um cdigo numrico e uma cadeia de smbolos (o trecho do programa fonte correspondente). Estes itens so conhecidos como componentes lxicos do programa, lexemas, ou ainda tokens. Por exemplo, considere o trecho de programa Pascal: if x>0 then modx := x else modx := (-x) { x e' positivo } { x e' negativo ou nulo }

Aps a anlise lxica, a seqncia de tokens identificada : tipo do token palavra reservada if identificador operador maior literal numrico palavra reservada then identificador operador de atribuio identificador palavra reservada else identificador valor do token if x > 0 then modx := x else modx
J.L.Rangel - Compiladores - 1-4

tipo do token operador de atribuio delimitador abre parntese operador menos unrio identificador delimitador fecha parntese

valor do token := ( x )

Normalmente os tipos dos tokens (na primeira coluna) so representados por valores de um tipo de enumerao ou por cdigos numricos apropriados. Usualmente, a implementao de um analisador lxico (um scanner) se baseia em um autmato finito que reconhece as diversas construes. Por exemplo, o conjunto dos identificadores permitidos em Pascal pode ser descrito pela expresso regular
letra ( letra digito sublinhado )*,

onde os operadores , , e * representam respectivamente concatenao, unio e repetio, (zero ou mais vezes) e letra, digito e sublinhado representam conjuntos (ou classes) de caracteres: letra = { 'A', ...., 'Z', 'a', ... 'z' } digito = { '0', ..., '9' } sublinhado = { '_' }. A parte correspondente do autmato finito pode ser construda a partir dessa expresso regular. A anlise lxica pode ser mais complicada em outras linguagens. Por exemplo, FORTRAN no tem palavras reservadas, tem apenas palavras-chave, que tambm podem ser usadas como identificadores; alm disso, FORTRAN permite tambm o uso de espaos dentro de identificadores e palavras-chave. O exemplo clssico dos problemas que podem ser encontrados a cadeia DO 10 I = 5 que pode ser a parte inicial de um comando de atribuio DO 10 I = 5. em que a varivel real DO10I recebe o valor real 5., ou pode ser o comeo do comando de repetio, DO 10 I = 5, 20 ... CONTINUE

10

que especifica que os comandos entre o comando DO e o comando rotulado por 10 devem ser executados uma vez para cada valor de I = 5, 6, ..., 20. Note que at que o ponto ou a vrgula sejam encontrados, no possvel decidir qual a interpretao correta para DO10I. O projeto da maioria das linguagens modernas procura simplificar a implementao dos analisadores lxicos, que so, em geral, bem mais simples e mais rpidos que os de FORTRAN. Mesmo assim, uma parte substancial do tempo de compilao gasta em anlise lxica. J.L.Rangel - Compiladores - 1-5

4. Anlise sinttica A anlise sinttica deve reconhecer a estrutura global do programa, por exemplo, verificando que programas, comandos, declaraes, expresses, etc tm as regras de composio respeitadas. Caberia anlise sinttica reconhecer a estrutura do trecho if x>0 then modx := x else modx := (-x) identificando que se trata de um <comando>, no caso um <comando-if>, composto pela palavra reservada if, seguida de uma <expresso>, seguida da palavra reservada then, etc. Os itens <expresso> e <atribuio> ainda podem ser decompostos em fragmentos menores.

Quase universalmente, a sintaxe das linguagens de programao descrita por gramticas livres de contexto, em uma notao chamada BNF (Forma de Backus-Naur ou ainda Forma Normal de Backus), ou em alguma variante ou extenso dessa notao. Essa notao foi introduzida por volta de 1960, para a descrio da linguagem Algol3. Entre as regras para a sintaxe de comando em Pascal podemos ter as regras abaixo, algumas das quais seriam usadas na anlise do trecho de cdigo Pascal apresentado acima. A notao com os parnteses bicudos "<" e ">" freqentemente usada para indicar que <comando>, <comando-if>, <atribuio>, etc. so smbolos no terminais de uma gramtica livre de contexto. <comando> ::= <comando-if> | <atribuio> | ...

outras opes de comando

<comando-if> ::= IF <condio> THEN <comando> | IF <condio> THEN <comando> ELSE <comando> <atribuio> ::= <varivel> ::= <expresso> Algumas extenses da notao BNF permitem a introduo de expresses regulares no lado direito das regras. Por exemplo, um comando if de Ada pode ser representado pela regra <comando-if> ::= IF <expresso> THEN <comandos>

{
3

ELSIF <expresso> THEN <comandos>

Ver: Peter Naur (Editor), Revised Report on the Algorithmic Language Algol-60, Numerische Mathematik, 4, (1963) pp 420-453. J.L.Rangel - Compiladores - 1-6

ELSE <comandos> END IF ;

onde as chaves e os colchetes indicam que a parte ELSIF pode ser repetida zero ou mais vezes, e que a parte ELSE pode ocorrer zero ou uma vez. De forma semelhante, temos: <comandos> ::= <comando>

<comando>

Estas extenses abreviam as especificaes de gramticas de linguagens de programao, sem no entanto aumentar a classe de linguagens que podem ser representadas. Algumas ferramentas de construo de analisadores sintticos aceitam estas e outras extenses notao BNF. A teoria de gramticas e linguagens livres de contexto fornece algoritmos determinsticos que permitem determinar se uma cadeia pertence linguagem de uma gramtica livre de contexto qualquer em tempo polinomial ( O(n3) ) no comprimento da cadeia. Entretanto, na prtica, restries nas classes de gramticas utilizadas permitem garantir o funcionamento dos analisadores em tempo linear ( O(n) ). As classes de gramticas mais utilizadas so LL(1), LR(1) e suas variantes. 5. Anlise semntica Fundamentalmente, a anlise semntica trata os aspectos sensveis ao contexto da sintaxe das linguagens de programao. Por exemplo, no possvel representar em uma gramtica livre de contexto uma regra como "Todo identificador deve ser declarado antes de ser usado.", e a verificao de que essa regra foi aplicada cabe anlise semntica. A regra pode ser representada em uma gramtica sensvel ao contexto, mas no existem algoritmos rpidos para essa classe de gramticas. A idia fundamental a de usar tabelas externas ao processo de anlise sinttica, em que as informaes so coletadas para posterior consulta. Por exemplo, uma tabela de smbolos (ou tabela de identificadores) pode guardar informaes sobre as declaraes dos identificadores, e essas informaes podem ser consultadas para verificar a correo de cada uso de um identificador. Esse processo implementado de forma dirigida pela sintaxe: associa-se a cada regra da gramtica uma ao (ao semntica) a ser executada quando o analisador sinttico sinaliza um uso da regra. Essas aes so freqentemente implementadas como chamadas de rotinas semnticas, e podem ser responsveis por efetuar a anlise semntica e a gerao de cdigo, pelo menos parcialmente. No exemplo acima, toda vez que o analisador sinttico indicar o uso de uma regra associada a uma declarao, a rotina semntica associada a essa regra chamada para acrescentar tabela o identificador correspondente, fornecido pelo analisador lxico. Quando uma regra associada a um uso de um identificador for sinalizada, a rotina semntica correspondente ser chamada para verificar se o identificador (novamente fornecido pelo analisador lxico) consta da tabela. No existe uma fronteira definida entre o que deve ser tratado pelo analisador sinttico e o que deve ser tratado pelo analisador semntico, cabendo ao programador do compilador a escolha, segundo suas preferncias. Por exemplo, algumas verses de Pascal exigem que as declaraes em um bloco ocorram numa ordem determinada,
J.L.Rangel - Compiladores - 1-7

comeando pelas declaraes de rtulos e terminando pelas de procedimentos e funes. Isto pode ser feito (na sintaxe) por uma regra <decs> ::= <dec1> <dec2> <dec3> <dec4> <dec5>, ou (na semntica) atravs de um nmero inteiro que representa a fase em que o processo se encontra: na fase i, s podem ser aceitas declaraes <decj> para ji. Durante o curso, encontraremos outras situaes semelhantes, em que a escolha da forma de implementao ser feita de acordo com as preferncias do implementador. 6. Gerao de Cdigo e Otimizao Dependente de Mquina Observamos antes que uma representao intermediria do programa fonte deve ser construda durante a fase de anlise, para ser usada como base para a gerao do programa objeto. Se a forma dessa representao intermediria bem escolhida, a complexidade do processo de gerao de cdigo depende apenas da arquitetura da mquina (real ou virtual) para a qual o cdigo est sendo gerado. Mquinas mais simples oferecem poucas opes e por isso o processo de gerao de cdigo mais direto. Por exemplo, se uma mquina tem apenas um registrador (acumulador) em que as operaes aritmticas so realizadas, e apenas uma instruo para realizar cada operao (uma instruo para soma, uma para produto, ...), existe pouca ou nenhuma possibilidade de variao no cdigo que pode ser gerado. Considere o comando de atribuio x := a + b * c A primeira operao a ser realizada o produto de b por c. Seu valor deve ser guardado numa posio temporria, que indicaremos aqui por t1. (Para sistematizar o processo, todos os resultados de operaes aritmticas sero armazenados em posies temporrias.) Em seguida, devemos realizar a soma de a com t1, cujo valor ser guardado numa posio temporria t2. (Naturalmente, neste caso particular, o valor poderia ser armazenado diretamente em x, mas no caso geral, a temporria necessria.) Finalmente, o valor de t2 armazenado em x. t1:=b*c t2:=a+t1 x:=t2 Podemos fazer um gerador de cdigo relativamente simples usando regras como:

J.L.Rangel - Compiladores - 1-8

1. toda operao aritmtica (binria) gera 3 instrues: instruo exemplo: b c Load b carrega o primeiro operando no acumulador usa a instruo correspondente a operao com o Mult c segundo operando, deixando o resultado no acumulador Store t1 armazena o resultado em uma temporria nova 2. um comando de atribuio gera sempre duas instrues: instruo carrega o valor da expresso no acumulador armazena o resultado na varivel O comando de atribuio x := a + b c, gera o cdigo 1 2 3 4 5 6 7 8

exemplo: x := t2 Load t2 Store x

Load b Mult c Store t1 Load a Add t1 Store t2 Load t2 Store x

{ t1:=b*c }

{ t2:=a+t1 }

{ x:=t2 }

Embora correto, este cdigo pode obviamente ser melhorado: a instruo 7 desnecessria e pode ser retirada: copia para o acumulador o valor de t2, que j se encontra l. (aps a remoo da instruo 7) a instruo 6 desnecessria e pode ser retirada: o valor da varivel t2 nunca utilizado. (considerando que a soma comutativa) as instrues 4 e 5 podem ser trocadas por 4' e 5', preparando novas alteraes: 4' Load t1 5' Add a

As instrues 3 e 4' so desnecessrias e podem ser retiradas (pelas mesmas razes que 6 e 7 acima). O cdigo final aps as transformaes consideravelmente melhor que o original: 1 2 5' 8 Load b Mult c Add a Store x

Normalmente, as mquinas oferecem vrias instrues (ou variantes de instrues) com caractersticas semelhantes, e o gerador deve escolher a mais apropriada
J.L.Rangel - Compiladores - 1-9

entre elas. Como exemplo, vamos examinar o caso da operao de soma. Em geral, podemos observar os seguintes pontos:
h vrias instrues de soma, correspondendo a vrios tipos de dados e a

vrios modos de endereamento;

h instrues de soma aplicveis a casos particulares importantes, como

instrues de incremento e decremento: soma com 1; algumas das somas a serem efetuadas no foram especificadas explicitamente pelo programador. Entre essas citamos as somas usadas no clculo de endereos de variveis componentes de vetores, matrizes e estruturas situadas em registros de ativao de procedimentos ou funes. Freqentemente, essas somas podem ser includas no cdigo de forma implcita atravs da escolha de modos de endereamento adequados; instrues cuja finalidade principal no a soma podem mesmo assim efetuar somas. Por exemplo, as instrues que manipulam a pilha de hardware, incrementam ou decrementam o registrador apontador do topo da pilha.

Esses pontos devem ser levados em considerao pelo gerador de cdigo na seleo de instrues. Outro problema que tambm deve ser tratado o da escolha do local para guarda dos valores das variveis definidas pelo usurio e das variveis temporrias introduzidas pelo compilador. Alm da alocao de posies de memria a essas variveis, freqente a disponibilidade de vrios registradores de uso geral, que tambm podem ser usados com essa finalidade. A alocao de registradores, entretanto, no independente da seleo de instrues, j que muitas instrues usam registradores ou combinaes de registradores para operaes especficas. Cabe ao projetista do gerador de cdigo decidir como implementar a gerao de cdigo de maneira a fazer bom uso dos recursos disponveis na mquina. Cabe tambm ao projetista decidir se a gerao do cdigo deve ser feita com cuidado, gerando diretamente cdigo de qualidade aceitvel, ou se prefervel usar um esquema mais simples de gerao de cdigo, seguido por uma otimizao do cdigo depois de gerado. Esta otimizao do cdigo leva em considerao principalmente as caractersticas da mquina alvo, e por isso normalmente chamada de otimizao dependente de mquina. 7. Otimizao independente de mquina Algumas transformaes feitas no cdigo gerado por um compilador independem da mquina para o qual o cdigo est sendo gerado. Normalmente estas transformaes so feitas no cdigo intermedirio, pela facilidade de acesso j mencionada anteriormente. Vamos nesta seo apresentar alguns exemplos deste tipo de otimizao.

J.L.Rangel - Compiladores - 1-10

Exemplo 1: Sub-expresses comuns. Considere a seqncia de comandos de atribuio da primeira coluna da tabela. Fonte
w:=(a+b)+c;

cdigo intermedirio original

t1:=a+b t2:=t1+c w:=t2 t3:=a+b t4:=t3d x:=t4 t5:=a+b t6:=t5+c y:=t6 t7:=a+b t8:=t7d t9:=t8+e z:=t9

cdigo intermedirio otimizado

t1:=a+b t2:=t1+c w:=t2 t4:=t1d x:=t4 y:=t2 t9:=t4+e z:=t9

x:=(a+b)d; y:=(a+b)+c;

z:=(a+b)d+e;

Claramente, as (sub-)expresses a+b, (a+b)+c, e (a+b)d no precisam ser calculadas mais de uma vez. (Isto s verdade porque os valores de a, b, c e d no se alteram no trecho em questo.) Podemos alterar a representao intermediria correspondente (segunda coluna) para a forma intermediria equivalente otimizada apresentada na terceira coluna. Exemplo 2: Retirada de comandos invariantes de loop. Considere o trecho de cdigo a seguir: for i:=1 to n do begin pi:=3.1416; pi4:=pi/4.; d[i]:=pi4 * r[i] * r[i]; end; Claramente, os dois primeiros comandos de atribuio podem ser retirados do loop, uma vez que seu funcionamento independente do funcionamento do loop. Obteramos pi:=3.1416; pi4:=pi/4.; for i:=1 to n do d[i]:=pi4 r[i] r[i]; que uma verso "otimizada" do trecho de cdigo anterior. Note, entretanto, que s h uma melhora no tempo de execuo se o valor de n for maior que zero. Se n=0, o cdigo foi piorado: os dois comandos de atribuio sero sempre executados. Normalmente, as transformaes realizadas no programa durante a otimizao so simples: eliminar ou alterar instrues, ou ainda mover instrues para outras posies. A parte mais trabalhosa a verificar que a transformao pode ser feita. Por exemplo, para eliminar um comando da forma v:=e, preciso verificar que o valor de v calculado neste comando no ser usado por nenhum outro comando, e, portanto, examinar toda a parte do programa que poder ser executada a seguir. Por essa razo, o principal assunto discutido no captulo de otimizao a anlise de fluxo de dados (dataflow analysis), que visa obter informao sobre o funcionamento do programa, em
J.L.Rangel - Compiladores - 1-11

particular especificando os pontos do programa onde as variveis recebem valores, e onde os valores so usados. 8. Concluso Em 1977, Aho e Ullman indicaram, na capa de seu livro4, as armas disponveis contra o Drago da Complexidade do Projeto de Compiladores: o gerador de analisadores sintticos LALR, a traduo dirigida pela sintaxe, e a anlise de fluxo de dados. O projeto de um compilador se inicia pela escolha de uma gramtica para a linguagem fonte, e uma ferramenta existente se encarrega da construo do analisador sinttico; as aes (rotinas semnticas) a serem executadas so associadas s regras dessa gramtica; tcnicas de anlise de fluxo de dados fornecem a informao para boa gerao/otimizao de cdigo. Muitos sistemas tem sido propostos com a finalidade de construir um compilador a partir de especificaes sintticas e semnticas das linguagens fonte e objeto. At hoje, entretanto, nenhum deles mereceu ser chamado de compilador de compiladores5, e a construo de compiladores continua a ser feita mo, ainda que auxiliada por ferramentas cada vez mais poderosas. Veremos alguma coisa sobre o uso de algumas dessas ferramentas nos captulos seguintes.

(rev. mar 99)

4Alfred

V. Aho, Jeffrey D. Ullman, Principles of Compiler Design, Addison-Wesley, 1977, ou Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman, Compilers: Principles, Techniques and Tools, AddisonWesley, 1986 5O nome do conhecido gerador de analisadores sintticos yacc uma brincadeira sobre esse fato. Ver: S. C. Johnson, Yacc - Yet Another Compiler Compiler, Computing Science Technical Report 32, AT&T Bell Laboratories, 1975 J.L.Rangel - Compiladores - 1-12