Resumo do cap´ıtulo - Um modelo arquitectónico para desenvolvimento de compiladores: aplicação

Conclui-se assim a descri¸cão das ferramentas/sistemas de maior relevo para o trabalho desenvolvido neste doutoramento, cuja principal contribui¸cão é uma arquitectura para sistemas implementados através de frameworks. Nesta perspectiva, as ferramentas/sistemas mais significativos são aqueles que de forma assumida fazem uso de uma solu¸cão deste tipo e que são comparáveis/compat´ıveis com a solu¸cão que é aqui proposta. É o caso do RTL System e do SUIF System, que servem de referência para a avalia¸cão das solu¸cões apresentadas.

O gráfico da Figura2.2quantifica a adequa¸cão de cada um dos sistemas analisados, no desenvolvimento das tarefas de front-end, medium-level e back-end. Os três primeiros sistemas (Eli, GENTLE e Cocktail) são representativos dos sistemas de gera¸cão, caracterizados pela sua adequa¸cão ao desenvolvimento de front-ends, mas também de back-ends. O GCC é o sistema que mais se aproxima de uma biblioteca, adequando-se mais à constru¸cão do medium- level do processo de compila¸cão. O RTL System é o único sistema cuja implementa¸cão assenta unicamente numa framework, que como tal só permite suportar o desenvolvimento das tarefas de medium-level. Os três últimos sistemas (Zephyr, SUIF System e CoSy) são representativos da aplica¸cão de ferramentas de gera¸cão com frameworks, que de uma forma geral permitem suportar o desenvolvimento do medium-level e do back-end, mas por vezes também do front-end.

Figura 2.2: Gr´afico comparativo entre os v´arios sistemas.

2.9. Resumo do cap´ıtulo 27

CAP´ITULO 3

Framework Dolphin: Vers˜ao original

´_Indice

3.1 Modelo de compila¸cão . . . 32 3.2 Componentes . . . 33 3.3 Modelo da Representa¸cão Intermédia do Código . . . 35 3.4 Interfaces . . . 36 3.5 Exemplo de utiliza¸cão. . . 38 3.6 Resumo do cap´ıtulo . . . 40

No sentido de satisfazer o principal objectivo deste doutoramento, isto é, de tornar mais simples a constru¸cão de compiladores, entendeu-se partir de uma solu¸cão que claramente apostasse na reutiliza¸cão, sem que no entanto impossibilitasse a utiliza¸cão de ferramentas de gera¸cão.

Eram vários os motivos que levavam a apostar na reutiliza¸cão, em detrimento de solu¸cões de gera¸cão: em primeiro lugar, porque reutilizar significa pegar e fazer uso de algo que já existe, sem ter que ajustar, modificar ou alterar; em segundo lugar, porque se é to- talmente verdade que as ferramentas de gera¸cão contribuem para simplificar a constru¸cão de determinadas tarefas, também é verdade que especificar essas tarefas nem sempre é simples ou acess´ıvel para a grande maioria dos utilizadores. Por exemplo, ninguém põe em dúvida a utilidade de ferramentas como o Lex e o Yacc, ou mesmo de ferramentas mais evolu´ıdas como o Eli, mas quantas pessoas neste mundo podem afirmar ter conseguido desenvolver umfront-endpara C++ ou até mesmo para C? E ferramentas como oImproved Bottom-Up Rewrite Generator-IBURG ou o BEG que permitem construir boa parte das tarefas deback-

end, que são sem dúvida grandes auxiliares para quem constrói compiladores e que nem são dif´ıceis de utilizar. Mas quantas pessoas podem afirmar ter especificado um back-end que permita aproveitar razoavelmente os recursos disponibilizados por um processador do tipo Pentium? A verdade é que reutilizar é muito mais simples que especificar, seja para tarefas de front-end, back-end ou demedium-level.

Estas questões são de tal forma relevantes, que a grande maioria dos sistemas apresentados no Cap´ıtulo2, valem-se da reutiliza¸cão para assim disponibilizarem aos seus utilizadores front-ends e back-ends para as principais linguagens de programa¸cão e arquitecturas de computa¸cão.

Não significa isto que se pretende excluir as ferramentas de gera¸cão, antes pelo con- trário, pretende-se poder fazer uso dessas ferramentas, mas apenas quando não é poss´ıvel reutilizar ou quando os componentes1que se desejaria utilizar não existem.

Praticamente todos os sistemas apresentados no Cap´ıtulo2permitem a reutiliza¸cão e a aplica¸cão de ferramentas de gera¸cão, mas nem todos favorecem a reutiliza¸cão em detrimento da gera¸cão e nem todos disponibilizam uma solu¸cão que permita integrar ambas op¸cões.

Para potenciar a reutiliza¸cão há que apostar em for¸ca no medium-level, tentando deslo- car o maior número de componentes para este n´ıvel do processo de compila¸cão, e se poss´ıvel disponibilizar também ferramentas que gerem componentes para este n´ıvel, permitindo assim reutilizar os componentes gerados.

O simples facto de se fazer uso de um medium-level por si só, já traz grandes benef´ı- cios. Nos compiladores em que este n´ıvel não existe, as tarefas têm que ser implementadas no front-end ou no back-end, mesmo que sejam integralmente ou parcialmente independentes da linguagem fonte e da arquitectura de computa¸cão. No entanto, como estão implementadas sobre um modelo de RIC que é dependente destas caracter´ısticas (árvore de sintaxe abstracta/assembly), não poderão ser tão facilmente reutilizáveis.

Acresce ainda que nem sempre os modelos de RIC utilizados nos front-ends e nos back- ends são os mais adequados para implementar as tarefas. Por exemplo, a atribui¸cão global de registos, feita com base no algoritmo proposto por Chaitin [CAC+81, Cha82], requer o que se designa por inference graph, uma estrutura de dados que caracteriza a sobreposi¸cão do per´ıodo de vida útil das variáveis do programa. A computa¸cão desta estrutura, que não é uma tarefa trivial, requer informa¸cão que nem sempre está facilmente acess´ıvel nos ´

ultimos n´ıveis do processo de compila¸cão. Acresce ainda que, apesar de suportar uma tarefa que é completamente dependente das caracter´ısticas do microprocessador (a atribui¸cão de registos), a sua implementa¸cão é em grande parte independente do tipo de arquitectura de computa¸cão. Pelo que se for implementada no medium-level, poderá ser reutilizada sem ser necessário qualquer tipo de altera¸cão.

E já poss´ıvel tirar algumas conclusões sobre as caracter´ısticas que uma ferramenta para constru¸cão de compiladores deve satisfazer para potenciar a reutiliza¸cão de componentes. A primeira é que o modelo de compila¸cão a utilizar deverá conter três n´ıveis: front-end, medium- level e back-end. A segunda conclusão é que as tarefas implementadas sobre o medium-level devem utilizar um modelo de RIC comum. A terceira conclusão, é que come¸ca a fazer sentido a utiliza¸cão de uma solu¸cão do tipo framework em detrimento de ferramentas de gera¸cão.

Verifica-se que a utiliza¸cão de frameworks apresenta várias vantagens. É uma solu¸cão orientada à reutiliza¸cão, que tem a vantagem adicional de permitir aplicar conceitos mais abstractos, nomeadamente de carácter estrutural e comportamental, como por exemplo: definir um modelo de compila¸cão, o tipo de entidades que utiliza e até mesmo a forma como estas se relacionam. É também uma excelente solu¸cão para integrar ferramentas de gera¸cão

O termo componente ´e utilizado para designar uma rotina ou conjunto de rotinas que visem executar uma ou mais tarefas de compila¸c˜ao.

ou inclusive outras frameworks.

Inverte-se assim o papel da framework no contexto das ferramentas/sistemas para constru¸cão de compiladores, passando agora a ser a base de todo o sistema. Esta solu¸cão acaba mesmo por relegar as ferramentas de gera¸cão para um segundo plano, em que funcionam como simples “acessórios”. Isto para além dos benef´ıcios inerentes a qualquer framework, que:

• Pelo simples facto de disponibilizarem componentes já implementados, reduzem os custos de implementa¸cão, teste e avalia¸cão;

• Para al´em dos componentes, disponibilizam um desenho tipo para as aplica¸c˜oes (modelo funcional);

• Mas também de certa forma, o conhecimento e a experiência de desenvolvimento e de implementa¸cão;

• Pelo facto das aplica¸cões partilharem o mesmo desenho e componentes, são mais nor- malizados, tendencialmente mais consistentes e com menores custos de actualiza¸cão e manuten¸cão;

• Contribuem para uma prototipagem rápida dos componentes, interfaces, protocolos, e das próprias aplica¸cões;

• Facilitam o desenvolvimento cooperativo da framework ; • Funcionam como um reposit´orio de experiˆencia.

A utiliza¸c˜ao de frameworks segundo este modelo, encontra-se representada na Fi- gura1.2.

Dentro deste contexto, apenas dois dos sistemas apresentados no Cap´ıtulo 2satisfazem as condi¸cões requeridas. É o caso doSUIF Compiler Systeme doRTL System. O CoSy fica de fora por falta de informa¸cão de ´ındole cient´ıfica e por não ser um sistema aberto.

O SUIF System, apesar de ser um sistema que visa criar as condi¸cões necessárias para a experimenta¸cão e investiga¸cão de técnicas de compila¸cão, é uma solu¸cão menos flex´ıvel no que diz respeito à realiza¸cão de experiências com o próprio sistema, isto devido à sua dimensão e complexidade. O que levou a considerar o RTL System como a solu¸cão mais adequada para se desenvolver os trabalhos inerentes a este doutoramento.

O RTL System apresenta no entanto um pequeno senão: está implementado em Small- talk, quando as linguagens de elei¸cão utilizadas nesta área são o C e o C++. A utiliza¸cão do Smalltalk coloca logo à partida problemas de compatibilidade. De notar que enquanto numa ferramenta de gera¸cão, a linguagem utilizada na sua implementa¸cão não tem que ser a mesma das rotinas geradas por essa ferramenta, já numa solu¸cão do tipo framework não há esta diferen¸ca. Por exemplo, muitas ferramentas do Cocktail estão implementadas em Modula-2, no entanto podem gerar código em linguagem C. Isto permite facilmente integrar esse código com solu¸cões provenientes de outros sistemas, ou até mesmo integrar estas ferramentas noutros sistemas, não obstante o facto de estarem implementadas em Modula-2. No entanto, no caso das frameworks a linguagem que é utilizada na sua implementa¸cão é neces- sariamente a mesma dos seus componentes, isto porque são os componentes que formam a framework. Significa isto que implementar frameworks com linguagens que não as de elei¸cão, cria sérias dificuldades à integra¸cão dos componentes com solu¸cões provenientes de outros sistemas, mas também à utiliza¸cão dessas frameworks como plataformas de integra¸cão de ferramentas de gera¸cão.

Estes inconvenientes enfatizaram o trabalho já efectuado no âmbito do projectoBack- End Development System- BEDS [Mat99], o qual poderia ser útil para alcan¸car os objectivos propostos e que, para além de estar implementado em C++, já continha uma implementa¸cão parcial do modelo de RIC utilizado pelo RTL System. Atendendo a que já havia algum know-how e mesmo algum código que poderia ser reaproveitado, ponderou-se e optou-se pela implementa¸cão de uma solu¸cão própria.

Contribuiu ainda para esta op¸cão, o facto de uma solu¸cão própria ser mais maleável, menos propensa a restri¸cões e mais incidente nos problemas que este doutoramento visa solucionar. Por um lado, isto significa que não é obrigatório utilizar solu¸cões que não são relevantes para este doutoramento ou das quais se discorda; e por outro lado, é mais acess´ıvel fazer uso de solu¸cões que tenham sido desenvolvidas propositadamente ou reaproveitadas de outros sistemas.

Do desenvolvimento desta solu¸cão resultou a framework Dolphin, que apesar de não fazer parte dos objectivos deste doutoramento, serviu à priori como test-bed para efectuar as experiências que conduziram aos resultados aqui apresentados, e a posteriori como prova que esses resultados não só são funcionais, como satisfazem em grande parte os objectivos propostos.

Este cap´ıtulo visa apresentar o que se designou por framework Dolphin - Versão Ori- ginal (framework Dolphin-VO ), que foi desenvolvida à imagem de outros sistemas, mas em especial do RTL System, e que foi utilizada para colocar em prática e avaliar, as solu¸cões idealizadas neste doutoramento.

E de real¸car que a implementa¸cão desta framework, não tinha por objectivo desenvolver uma ferramenta/sistema para constru¸cão de compiladores, previa-se apenas utilizá-la como test-bed. Resultou no entanto numa solu¸cão bastante apraz´ıvel, com caracter´ısticas e uma filosofia própria. O que levou a ponderar utilizá-la efectivamente (para lá do contexto deste doutoramento) como uma ferramenta/sistema para constru¸cão de compiladores, que faz mesmo parte de um projecto maior, o Sistema Dolphin (ver Cap´ıtulo 9). Houve assim necessidade de lhe dar um nome (inicialmente designada por framework Dolphin), e pos- teriormente de distinguir a versão utilizada como base para o trabalho desenvolvido neste doutoramento (framework Dolphin -VO ), da versão que resulta da aplica¸cão das solu¸cões aqui propostas (a qual se designa, simplesmente, por framework Dolphin2_).

Para simplificar a compreensão do texto, utilizar-se-á o termo “framework Dolphin- VO ” apenas para referir aspectos espec´ıficos da versão original deste sistema. Quando o contexto visar a versão definitiva ou caracter´ısticas comuns entre ambas versões, será utilizado simplesmente o termo “framework Dolphin”.

3.1 Modelo de compila¸c˜ao

Conceptualmente uma framework difere de uma biblioteca, porque pode incluir rotinas reutilizáveis, mas principalmente porque deve definir: o modelo da aplica¸cão (a desenvolver através da framework ); as entidades que compõem esse modelo; e a forma como essas entidades se relacionam. A framework reflecte assim a estrutura das aplica¸cões a desenvolver, que neste caso são compiladores.

Já foi dito que: os compiladores para este tipo de solu¸cão são formados por um front- end, um medium-level e um back-end ; e que as tarefas do medium-level funcionam sobre um modelo comum de RIC. Apesar de já dizer muito acerca do modelo de compila¸cão, há outras

Na realidade o trabalho desenvolvido neste doutoramento, permite que a versão original integre e coabite com a versão definitiva da framework Dolphin, de forma extremamente simples e eficiente e sem qualquer tipo de redundância (ver Seçcão3.4).

No documento Um modelo arquitectónico para desenvolvimento de compiladores: aplicação à framework Dolphin (páginas 42-49)