UNIVERSIDADE FEDERAL DE SANTA CATARINA PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO

Jos Otvio Carlomagno Filho

Escalonamento Redirecionvel de Cdigo sob Restries de Tempo Real

Dissertao submetida Universidade Federal de Santa Catarina como parte dos requisitos para a obteno do grau de Mestre em Cincia da Computao.

Luiz Cludio Villar dos Santos, Dr.

Florianpolis, maro de 2007

Escalonamento Redirecionvel de Cdigo sob Restries de Tempo Real

Jos Otvio Carlomagno Filho

Esta Dissertao foi julgada adequada para a obteno do ttulo de Mestre em Cincia da Computao, rea de concentrao completa e aprovada em sua forma nal pelo Programa de Ps-Graduao em Cincia da Computao.

Rogrio Cid Bastos, Dr.

Banca Examinadora

Luiz Cludio Villar dos Santos, Dr.

Olinto Jos Varela Furtado, Dr.

Lus Fernando Friedrich, Dr.

Rmulo Silva de Oliveira, Dr.

iii

If I have seen farther, it is by standing on the shoulders of giants. Isaac Newton

iv

Aos meus pais, Doralysa e Jos Otvio, e Marina.

Agradecimentos
Agradeo primeiramente a meus pais, Doralysa e Jos Otvio, a quem devo tudo que sou hoje. minha namorada, Marina, pelo companheirismo, apoio e incentivo constantes. Ao professor Luiz Cludio pelo excelente trabalho de orientao e pelas oportunidades proporcionadas desde a graduao. Aos colegas do LAPS que contriburam direta ou indiretamente neste trabalho. Ao Alexandro Baldassin e Sandro Riggo, da UNICAMP, pelo suporte tcnico. Agradeo as contribuies de todos os membros da banca e por terem aceitado o convite.

Sumrio

Lista de Figuras Lista de Tabelas Lista de Acrnimos Resumo Abstract 1 Introduo 1.1 1.2 1.3 1.4 1.5 1.6 2 SoCs e plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A necessidade de tcnicas redirecionveis . . . . . . . . . . . . . . . . . A necessidade da captura de restries temporais . . . . . . . . . . . . . A pragmaticidade da otimizao ps-compilao . . . . . . . . . . . . . A contribuio desta dissertao . . . . . . . . . . . . . . . . . . . . . . A organizao desta dissertao . . . . . . . . . . . . . . . . . . . . . .

ix xi xiii xv xvi 1 2 4 5 6 7 7 9 9 11 13 14

Trabalhos Correlatos 2.1 2.2 2.3 2.4 Ferramentas redirecionveis . . . . . . . . . . . . . . . . . . . . . . . . Anlise de restries temporais . . . . . . . . . . . . . . . . . . . . . . . Otimizao ps-compilao . . . . . . . . . . . . . . . . . . . . . . . . . Traduo binria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii 3 Fundamentao Terica 3.1 Modelagem de CPUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.2 Estrutura bsica do modelo . . . . . . . . . . . . . . . . . . . . . Limitaes da modelagem ArchC . . . . . . . . . . . . . . . . . Extenses propostas para viabilizar o escalonamento de cdigo . . 16 16 16 19 21 24 25 26 27 28 29 34 36 36 37 38 49 51 51 51 56 60 62 62 64 65 66

Representao intermediria do cdigo . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 Grafo de uxo de controle . . . . . . . . . . . . . . . . . . . . . Grafo de uxo de dados . . . . . . . . . . . . . . . . . . . . . .

3.3

Modelagem de restries temporais . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 Modelagem de atrasos, latncias e deadlines . . . . . . . . . . . Modelagem de outros efeitos de temporizao . . . . . . . . . . . Vericao da factibilidade do escalonamento . . . . . . . . . . .

Otimizador de Cdigo Redirecionvel 4.1 4.2 4.3 4.4 4.5 4.6 Restries simplicadoras . . . . . . . . . . . . . . . . . . . . . . . . . Estrutura da ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . Fases de processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . Algoritmo de escalonamento de cdigo . . . . . . . . . . . . . . . . . . Algoritmo de alocao de registradores . . . . . . . . . . . . . . . . . . Validao experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6.1 4.6.2 4.6.3 Experimentos sem cdigo condicional . . . . . . . . . . . . . . . Experimentos com cdigo condicional . . . . . . . . . . . . . . . Critrios de validao . . . . . . . . . . . . . . . . . . . . . . .

O Papel da Otimizao Redirecionvel na Traduo Binria 5.1 5.2 5.3 5.4 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposta de estrutura de um tradutor binrio . . . . . . . . . . . . . . . . A integrao do otimizador no tradutor binrio . . . . . . . . . . . . . . Resultados experimentais preliminares . . . . . . . . . . . . . . . . . . .

viii 6 Concluses e Trabalhos Futuros 6.1 6.2 6.3 6.4 Apreciao do trabalho de pesquisa . . . . . . . . . . . . . . . . . . . . Contribuies tcnico-cientcas . . . . . . . . . . . . . . . . . . . . . . Produtos de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tpicos para investigao futura . . . . . . . . . . . . . . . . . . . . . . 68 68 69 70 70 73

Referncias Bibliogrcas

Lista de Figuras
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 Descrio dos parmetros da arquitetura em ArchC . . . . . . . . . . . . Descrio da arquitetura do conjunto de instrues em ArchC . . . . . . . Descrio do comportamento de instrues em ArchC . . . . . . . . . . . Usando set_property para explicitar operandos fonte . . . . . . . . . Usando set_property para explicitar operandos destino . . . . . . . Usando set_property para declarar campos do endereo de memria Usando set_property para declarar latncias entre instrues . . . . Usando set_property para declarar registradores de propsitos gerais Exemplo de grafo de uxo de controle . . . . . . . . . . . . . . . . . . . 17 18 19 22 23 23 24 24 26 27 29 30 31 39 40 41 43 44 45 46 47

3.10 Exemplo de grafo de uxo de dados . . . . . . . . . . . . . . . . . . . . 3.11 Exemplo de grafo ponderado de precedncia . . . . . . . . . . . . . . . . 3.12 Modelagem de instruo de desvio com anulao do slot . . . . . . . . . 3.13 Modelagem de instruo de desvio sem anulao do slot . . . . . . . . . 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Fluxo de otimizao do cdigo . . . . . . . . . . . . . . . . . . . . . . . Transformao do assembly original em instrumentado . . . . . . . . . . WPG gerado a partir do assembly instrumentado . . . . . . . . . . . . . . Escalonamento da primeira instruo . . . . . . . . . . . . . . . . . . . . Escalonamento da segunda instruo . . . . . . . . . . . . . . . . . . . . WPG escalonado (SWPG) . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo otimizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impondo restrio temporal ao cdigo da Figura 3.9 . . . . . . . . . . . .

x 4.9 Impondo restrio restr_1 ao bloco b1 . . . . . . . . . . . . . . . . . . 48 48 53 54 54 55 55 58 58 59 59 60 64 66

4.10 Propagando a restrio restr_1 de b1 para b2 . . . . . . . . . . . . . . . 4.11 Porcentagem de solues factveis . . . . . . . . . . . . . . . . . . . . . 4.12 Correlao do tamanho do WPG e tempo de execuo (MIPS) . . . . . . 4.13 Correlao do tamanho do WPG e tempo de execuo (PowerPC) . . . . 4.14 Correlao do tamanho do WPG e tempo de execuo (SPARC) . . . . . 4.15 Acelerao da execuo do cdigo aps a otimizao . . . . . . . . . . . 4.16 Porcentagem de solues factveis . . . . . . . . . . . . . . . . . . . . . 4.17 Correlao do tamanho mdio do WPG e tempo de execuo (MIPS) . . . 4.18 Correlao do tamanho mdio do WPG e tempo de execuo (PowerPC) . 4.19 Correlao do tamanho mdio do WPG e tempo de execuo (SPARC) . . 4.20 Acelerao da execuo do cdigo aps a otimizao . . . . . . . . . . . 5.1 5.2 Fluxo de traduo binria . . . . . . . . . . . . . . . . . . . . . . . . . . Integrao do otimizador no tradutor binrio . . . . . . . . . . . . . . . .

Lista de Tabelas
4.1 4.2 5.1 5.2 Caracterizao dos benchmarks sem cdigo condicional . . . . . . . . . . Caracterizao dos benchmarks com cdigo condicional . . . . . . . . . Resultados da traduo binria MIPS-SPARC . . . . . . . . . . . . . . . Resultados da traduo binria SPARC-MIPS . . . . . . . . . . . . . . . 52 57 67 67

Lista de Algoritmos
1 2 Clculo dos caminhos mais longos . . . . . . . . . . . . . . . . . . . . . Escalonamento de cdigo . . . . . . . . . . . . . . . . . . . . . . . . . . 35 50

Lista de Acrnimos
ADL ASIP BB CFG CI CPU DFG DSP IP ISA NRE PV PVT RAM RISC ROM RT RTL SoC SWPG TLM VLIW Architecture Description Language Application-Specic Instruction Set Processor Bloco Bsico Control Flow Graph Circuito Integrado Central Processing Unit Data Flow Graph Digital Signal Processor Intellectual Property Instruction Set Architecture Non-recurring Engineering Programmers View Programmers View plus Timing Random Access Memory Reduced Instruction Set Computer Read-Only Memory Register-Transfer Register-Transfer Level System-on-Chip Scheduled Weighted Precedence Graph Transaction Level Modeling Very Long Instruction Word

xiv WPG Weighted Precedence Graph

Resumo
A evoluo dos sistemas computacionais deu origem aos systems-on-chip ou SoCs, onde diversos componentes (como memria, barramentos e processador(es)) esto presentes em um nico circuito integrado. Os SoCs possivelmente contm mltiplos processadores de diferentes tipos, portanto a explorao de seu espao de projeto requer ferramentas redirecionveis. O aumento da complexidade de tais sistemas, juntamente com a diminuio do time-to-market e a necessidade de iniciar-se o desenvolvimento do software embarcado o mais cedo possvel, deu origem modelagem no nvel de transaes ou TLM (transaction-level modeling). O projeto inicia-se com um modelo TLM atemporal, mas a posterior anotao de restries temporais exige que o software embarcado seja revisado, sendo teis ferramentas de anlise de restries temporais ps-compilao. Esta dissertao descreve uma tcnica automaticamente redirecionvel que combina anlise de restries temporais e escalonamento de cdigo assembly. A tcnica baseiase na extrao de informaes especcas da arquitetura-alvo atravs de uma descrio formal do processador e na codicao de restries temporais e de precedncia em uma representao unicada usando grafos. Resultados experimentais mostram que a tcnica no somente lida ecientemente com restries temporais, mas tambm as explora para guiar as otimizaes. So apresentados resultados para os processadores MIPS, PowerPC e SPARC, onde aceleraes na execuo do cdigo de at 1,3 vezes foram obtidas em relao ao cdigo pr-otimizado. Este trabalho aborda ainda um estudo da viabilidade de se integrar a tcnica proposta em um tradutor binrio, contribuindo para que, ao se traduzir cdigo compilado de uma arquitetura para outra, o cdigo traduzido resulte otimizado. Resultados preliminares so apresentados como um forte indcio de viabilidade.

Abstract
The evolution of computing systems gave rise to the systems-on-chip or SoCs, where different components (such as memory, buses and processor(s)) are present in a single chip. SoCs possibly contain multiple processors of different types, therefore their design space exploration requires retargetable tools. The growth in the complexity of these systems, along with a shorter time-to-market and the need to launch embedded software development as early as possible, gave rise to transaction-level modeling (TLM). System design starts with an untimed TLM model, but the later annotation of timing constraints requires the revision of the embedded software, where post-compiling timing constraint analysis tools are useful. This dissertation describes an automatically retargetable technique which combines time-constraint analysis and assembly code scheduling. The technique relies on the extraction of target-dependent information from a formal description of the target-CPU and on the encoding of time and precedence constraints on a unied graph representation. Experimental results show that the technique not only handles time-constraints efciently, but also exploits them to guide code optimizations. Results are presented for the MIPS, PowerPC and SPARC processors, where speed-ups of 1.3 over pre-optimized code were obtained. This work also describes a study of the viability of integrating the proposed technique in a binary translator so that, when code is translated from one architecture to another, the translated code results optimized. Preliminary results are presented as a strong indication of viability.

Captulo 1

Introduo

A constante evoluo dos sistemas eletrnicos nas ltimas dcadas deu-se de forma muito acelerada, tanto do ponto de vista do desempenho como do ponto de vista da complexidade. Alm do impacto bvio nos computadores de uso geral, os sistemas eletrnicos esto hoje embarcados em equipamentos de uso cotidiano como automveis, telefones celulares e outros dispositivos mveis, eletrodomsticos e aparelhos eletrnicos de entretenimento (jogos, TV, CD, DVD, etc.).

Os primeiros sistemas eram compostos por vrios circuitos integrados ou CIs, que por sua vez eram compostos por algumas dezenas ou centenas de transistores. Em 1965, Gordon Moore declarou que o nmero de transistores que poderiam ser incorporados em um CI dobraria a cada dezoito meses, previso que realmente se concretizou e cou conhecida como Lei de Moore, valendo por mais de trs dcadas. A reduo no tamanho dos transistores tem provocado melhoria de desempenho e aumento da complexidade dos circuitos integrados. Tal evoluo deu origem, em meados dos anos 90, a uma nova tecnologia, o System-on-chip ou SoC. Um SoC um CI contendo todo um sistema computacional composto de vrios componentes como memria, barramentos, processador(es) e perifricos.

1.1

SoCs e plataformas
Ao mesmo tempo em que a evoluo dos SoCs abriu novos caminhos para a in-

dstria de semicondutores, ela trouxe tambm novos desaos. O rpido crescimento da complexidade dos SoCs fez com que houvesse tambm um aumento nos custos de projeto de tais sistemas. Destacam-se aqui os custos das mscaras dos CIs e de engenharia norecorrente ou NRE (non-recurring engineering), que so custos envolvidos no processo de criao de um novo SoC (desde a pesquisa e o projeto inicial at o teste deste novo sistema). Tais aumentos nos custos de projeto tornam crtica a necessidade de se obter sucesso na primeira tentativa de produo de um SoC, ou seja, erros no projeto das funcionalidades e desempenho no so tolerados [GHE 05]. Alm disto, ao mesmo tempo que aumenta a complexidade e os custos de projeto, o time-to-market vem diminuindo signicativamente, ou seja, preciso colocar o produto no mercado cada vez mais cedo para obter uma vantagem sobre os competidores, mas o produto vem cando cada vez mais complexo. Nos primeiros projetos de SoCs, o desenvolvimento do hardware e do software dependente do hardware eram feitos separadamente. Criava-se um modelo do hardware no nvel de descrio Register-Transfer Level (RTL)1 e depois de este modelo estar pronto eram feitas simulaes para co-validar o hardware e o software dependente do hardware. Como o desenvolvimento do modelo RTL pode ser muito demorado, havia um atraso na validao do software. Alm disto, durante a validao deste software eram descobertos erros no projeto do hardware, fazendo com que fosse necessria uma nova iterao neste processo. Ademais, a simulao em nvel RTL pode tornar-se extremamente lenta para sistemas muito complexos. O aumento crescente nos custos de projeto de SoCs combinado com um time-tomarket cada vez menor fez com que a indstria buscasse outros paradigmas de projeto. Uma tentativa foi a de promover o re-uso de blocos de propriedade intelectual ou IPs
1

A descrio em nvel RTL baseia-se na noo de transferncia entre registradores ou RT (register-

transfer). Uma RT descreve o consumo de operandos armazenados em registrador, a execuo de uma operao e o armazenamento do restulado tambm em registrador.

3 (intellectual property) ao longo de diferentes projetos visando economizar tempo e custo de desenvolvimento, o que em vrios casos mostrou-se pouco prtico devido diculdade em entender o funcionamento e integrar IPs de terceiros [GHE 05]. Outra alternativa seria o chamado co-projeto hardware/software, onde o desenvolvimento e validao do hardware e do software seriam feitos de forma simultnea. Apesar de ter benefcios, esta abordagem ainda utilizava modelos RTL do hardware, o que acabava atrasando o incio do processo de co-vericao. Outro caminho proposto por parte da indstria foi o de elevar o nvel de abstrao para acima do RTL. Inicialmente, tentou-se a criao de modelos funcionais do hardware com preciso de ciclos, mas alm da diculdade na captura das informaes temporais a serem includas neste modelo, o seu tempo de simulao era muito alto, apenas uma ordem de magnitude acima dos modelos RTL [GHE 05]. Surgiu ento a abordagem de projeto orientado a plataformas [VIN 02], onde propese que em cada estgio do uxo de projeto do sistema seja criada uma plataforma. Uma plataforma denida como um circuito integrado exvel onde a customizao para uma aplicao em particular conseguida programando-se um ou mais componentes do chip [VIN 02]. Estas plataformas so representadas em diferentes nveis de abstrao do sistema (cada plataforma renada para dar origem a uma nova plataforma descrita no nvel de abstrao imediatamente inferior). A inteno que estas plataformas possam ser mais facilmente estendidas e personalizadas, podendo assim ser utilizadas em diferentes projetos que pertenam a uma mesma classe de aplicaes. Dentro da abordagem de projeto orientado a plataformas, foi proposta a modelagem no nvel de transaes ou TLM (transaction level modeling) [GHE 05]. Este tipo de modelagem baseia-se no desenvolvimento de um modelo do hardware onde os componentes do SoC so descritos por mdulos, os quais se comunicam atravs de transaes utilizando portas e interconexes 2 . O modelo desenvolvido com uma linguagem de descrio de sistemas como, por exemplo, SystemC [SYS 06].
2

Uma transao descreve o transporte de dados entre dois mdulos atravs de um meio de comunica-

o abstrato e possivelmente atemporal, onde comunicao e funcionalidade so ortogonais. Um mdulo representa o encapsulamento de um modelo de um IP.

4 Inicialmente, este modelo no inclui nenhuma informao de temporizao e utilizado para vericao funcional, sendo chamado de viso do programador ou PV (programmers view). Este modelo, apesar de inicialmente no incluir preciso de ciclos e nem detalhes de nvel mais baixo da arquitetura, ainda assim bastante preciso pois j inclui dados como a denio dos tipos dos barramentos, hierarquia de memria, mapeamento de entrada e sada em memria, etc. Informaes essenciais sobre restries temporais podem ser anotadas mais tarde no modelo PV para gerar um novo modelo TLM, chamado de viso do programador mais tempo ou PVT (programmers view plus timing) [GHE 05]. As duas principais vantagens da modelagem TLM so:

A simulao ca muito mais rpida, j que o modelo inicialmente no inclui informaes sobre preciso de ciclos, diminuindo tambm o tempo para desenvolv-lo. Pode-se iniciar mais cedo o desenvolvimento do software dependente do hardware, pois ele pode ser validado sobre o modelo executvel do hardware. Isso acarreta a diminuio do tempo de projeto, aumentando tambm as chances de sucesso na primeira tentativa de desenvolvimento.

1.2

A necessidade de tcnicas redirecionveis

Como foi dito anteriormente, um SoC basicamente composto de um ou mais pro-

cessadores, memria e perifricos. A escolha de IPs considera aspectos tais como o consumo de potncia e o tamanho do cdigo e busca desempenho suciente para satisfazer restries de tempo real. Isto requer uma explorao do espao de projeto. Em particular, a escolha de processadores bastante desaante. Como h uma grande variedade de CPUs e os SoCs muitas vezes so arquiteturas heterogneas compostas por diferentes tipos de CPU, durante o processo de explorao do espao de projeto vrias alternativas diferentes devem ser testadas, desde processadores de propsitos gerais, DSPs (digital signal processors), at processadores especcos para uma aplicao, os ASIPs (application-specic instruction-set processors).

5 Para cada alternativa de CPU, precisa-se de um conjunto de ferramentas para dar suporte gerao, inspeo e otimizao de cdigo tais como compilador, montador, ligador, simulador, depurador, escalonador, etc. Para processadores de propsitos gerais este conjunto de ferramentas normalmente j est disponvel, mas este nem sempre o caso quando CPUs dedicadas como, por exemplo, os DSPs e os ASIPs, so usadas. Portanto, essencial que estas ferramentas sejam facilmente redirecionveis para as diferentes alternativas de arquiteturas sendo testadas. Um bom ponto de partida para redirecionar tais ferramentas uma descrio do processador feita atravs de uma linguagem de descrio de arquiteturas ou ADL (architecture description language). Com uma ADL, possvel descrever a arquitetura do conjunto de instrues de um processador (alm de outras caractersticas como a hierarquia de memria, estrutura do pipeline, etc.) e, a partir desta descrio, gerar ferramentas de suporte gerao, inspeo e otimizao de cdigo, ou ainda gerar um modelo executvel do hardware (simulador).

1.3

A necessidade da captura de restries temporais

O projeto contemporneo de sistemas inicia-se pela criao de uma descrio em

TLM sem incluir informaes sobre restries de tempo, o modelo PV [GHE 05]. A principal vantagem desta metodologia que esta abstrao leva muito menos tempo para ser elaborada do que uma descrio RTL e resulta em menores tempos de simulao, permitindo iniciar mais cedo o desenvolvimento do software dependente de hardware. No entanto, necessria a posterior insero de restries temporais no modelo, gerando o modelo PVT. Isto faz com que o software dependente de hardware, desenvolvido e validado com o modelo atemporal, precise ser revisado e adaptado para atender s restries temporais do modelo PVT. Como as restries temporais so impostas ao cdigo j compilado, so desejveis tcnicas de otimizao ps-compilao que levem em conta tais restries, direcionando as otimizaes no cdigo a partir delas e vericando se o cdigo efetivamente as satisfaz.

1.4

A pragmaticidade da otimizao ps-compilao

Compiladores bastante populares, como o GCC [GCC 03], possuem suporte para

gerao de cdigo para vrios processadores (normalmente de propsitos gerais). Estes compiladores geralmente incluem tcnicas avanadas de escalonamento de cdigo. Justamente por gerarem cdigo para CPUs de propsitos gerais, estas tcnicas buscam otimizar apenas o desempenho mdio, no levando em conta o tempo de execuo no pior caso. Alm disto, estes compiladores tm uma limitao prtica: como geram cdigo para uma variedade de CPUs, costuma-se limitar o suporte de otimizaes dependentes da arquitetura-alvo. Portanto, quando restries de tempo real devem ser levadas em considerao, um escalonador de cdigo convencional ca limitado ao esquema de tentativa e erro. Da mesma forma, a necessidade de rpida compilao para que sejam exploradas diferentes alternativas de CPU tambm limita o uso de otimizaes dependentes de mquina mais agressivas. Quando h restries temporais s quais um programa deve satisfazer, alguns poucos ciclos desperdiados em trechos crticos do cdigo podem ser cruciais. Segundo [LEU 01], seria desejvel que um compilador pudesse acionar tcnicas de otimizao mais agressivas quando estivesse lidando com tais trechos de cdigo, conhecidas como hot spots (por exemplo, laos que so repetidos muitas vezes e consomem muito tempo). Como isto no suportado em compiladores convencionais, o desenvolvedor obrigado a fazer otimizaes manuais em trechos crticos do cdigo fonte ou do cdigo compilado, um processo que obviamente torna-se impraticvel sob a presso do time-to-market, quando deve ser repetido para vrias CPUs diferentes. No entanto, apesar das limitaes das otimizaes feitas por compiladores de uso geral, a gerao de novos compiladores torna-se muito custosa, sendo que o re-uso da infra-estrutura j existente (por exemplo, GNU) mostra-se bastante pragmtico. Desta forma, para obter um cdigo de qualidade e ainda assim no abrir mo desta infraestrutura pr-estabelecida, as tcnicas de otimizao aps a compilao representam uma oportunidade a ser explorada.

1.5

A contribuio desta dissertao

Esta dissertao tem como principal produto de trabalho uma ferramenta de otimi-

zao ps-compilao, redirecionvel e apta a tratar restries temporais, a qual escalona o cdigo assembly e faz a alocao dos registradores para gerar cdigo otimizado. A tcnica utilizada automaticamente redirecionvel e combina anlise de restries temporais e escalonamento de cdigo assembly. Esta tcnica baseada em dois mecanismos principais: A extrao automtica de informaes dependentes da arquitetura a partir de uma descrio formal de um processador-alvo arbitrrio, o que torna a ferramenta redirecionvel. A codicao de restries temporais e de precedncia das instrues em uma representao unicada utilizando-se grafos, o que prov a base para a anlise de restries temporais e de factibilidade do escalonamento. Um subproduto desta dissertao a integrao do otimizador em um tradutor binrio, dando origem a uma ferramenta no somente capaz de traduzir cdigo compilado de uma arquitetura para outra, mas tambm apto a gerar o cdigo otimizado para a arquitetura-alvo.

1.6

A organizao desta dissertao

Esta dissertao est organizada da seguinte maneira: o Captulo 2 apresenta uma

reviso dos trabalhos correlatos na literatura, nas reas de ferramentas redirecionveis, anlise de restries temporais, otimizao de cdigo aps a compilao e traduo binria. O Captulo 3 explica como feita a modelagem das CPUs utilizando-se uma ADL, bem como a gerao da representao intermediria do cdigo atravs de grafos, nos quais feita a codicao das restries temporais e de precedncia. O Captulo 4 descreve o otimizador de cdigo redirecionvel, mostrando a estrutura da ferramenta, seus principais componentes, fases de processamento, algoritmos e resultados dos experimentos. O

8 Captulo 5 mostra como o escalonador redirecionvel proposto nesta dissertao pode ser integrado a um tradutor binrio, melhorando a qualidade do cdigo traduzido. No Captulo 6, so apresentadas as concluses e apontadas perspectivas de trabalhos futuros. O trabalho de pesquisa reportado nesta dissertao foi desenvolvido sob fomento parcial do Programa Nacional de Cooperao Acadmica (PROCAD) da CAPES, no mbito do Projeto n. 0326054, intitulado Automao de Projeto de Sistemas Dedicados Usando uma Linguagem de Descrio de Arquiteturas, que norteia e formaliza as atividades de cooperao cientca entre o Programa de Ps-Graduao em Cincia da Computao (PPGCC) da UFSC e o Instituto de Computao da UNICAMP. O projeto foi executado no Laboratrio de Automao do Projeto de Sistemas (LAPS) da UFSC (http://www.laps.inf.ufsc.br/). O desenvolvimento deste trabalho foi parcialmente amparado por bolsa de mestrado oferecida pela Motorola Industrial, no mbito da rede Brazil Test Center (BTC), mediante contrapartida de prestao de servios ao Projeto Test Automation no Laboratrio de Desenvolvimento de Software (LabSoft) da UFSC (http://www.labsoft.ufsc.br).

Captulo 2 Trabalhos Correlatos

2.1 Ferramentas redirecionveis
O uso de processadores dedicados a uma classe de aplicaes (os ASIPs) nos SoCs trouxe a necessidade de que conjuntos de ferramentas de suporte gerao de cdigo pudessem ser geradas ou redirecionadas automaticamente para estas novas arquiteturas. Vrios trabalhos na literatura abordam este tema, focando no redirecionamento de ferramentas como compiladores e montadores a partir de descries do processador feitas com uma ADL. Em [HAN 98] apresentada a ferramenta AVIV, um gerador de cdigo redirecionvel. Esta ferramenta recebe como entrada o cdigo fonte escrito em C ou C++ e primeiramente faz otimizaes independentes da arquitetura-alvo, gerando um formato intermedirio de cdigo. A partir deste, o back-end do compilador baseia-se em uma descrio da arquitetura-alvo feita em ISDL [HAD 97] para gerar o cdigo assembly. Esta descrio em ISDL tambm usada para a gerao automtica de um montador. O trabalho relatado em [HAN 98] aborda a gerao do cdigo assembly para a arquitetura-alvo. A ferramenta AVIV usa como front-end os compiladores SUIF [Sta 94] e SPAM [SPA 97] para a gerao do formato intermedirio do cdigo. Este formato consiste em grafos de uxo de controle e de dados que so usados para explorar as possibilidades de gerao de cdigo dos blocos bsicos. So feitas transformaes sobre estes

10 grafos e utilizadas heursticas para realizar, a partir da descrio ISDL, a associao de unidades funcionais a instrues, seleo de instrues, alocao de registradores e escalonamento. O back-end do compilador AVIV foca na minimizao do tamanho do cdigo gerado. O compilador redirecionvel EXPRESS apresentado em [HAL 01]. Ele utiliza a ADL EXPRESSION [HAL 99] para ser redirecionado para diferentes arquiteturas e recebe como entrada programas escritos em linguagem C. O front-end do compilador EXPRESS baseado no front-end do compilador GCC e faz algumas otimizaes independentes da arquitetura-alvo, enquanto que seu back-end faz a seleo de instrues e alocao de registradores. O back-end desse compilador incorpora um framework chamado Transmutations, o qual busca o melhor ordenamento das fases de processamento do compilador de acordo com as caractersticas do cdigo e dos recursos disponveis, procurando ainda customizar o compilador para diferentes classes de arquiteturas. A gerao automtica de um escalonador de instrues a partir da ADL LISA [PEE 99] foi relatada em [WAH 03]. Neste trabalho, foi utilizada a ferramenta de desenvolvimento de compiladores CoSy, a qual capaz de redirecionar o back-end do compilador para diferentes arquiteturas, com base em arquivos que descrevem as fases de gerao de cdigo. A partir da descrio do processador feita em LISA, gera-se o arquivo contendo a descrio do escalonador de instrues do compilador a ser gerado pelo CoSy, o qual combinado com outros arquivos (gerados manualmente) que descrevem a seleo de instrues e alocao de registradores. No entanto, apesar de em [HOH 04] os autores mencionarem que a gerao do escalonador totalmente automtica a partir da descrio LISA, isto no ca totalmente explcito j que em [WAH 03] reportado que a ferramenta gera apenas a parte que descreve os hazards estruturais, ou seja, os potenciais conitos de recursos da arquitetura-alvo. As informaes sobre as latncias entre instrues no so extradas automaticamente da descrio LISA; portanto, essa descrio deve ser elaborada manualmente. Os trabalhos em [TAG 05b], [TAG 05a] e [BAL 05a] abordam a gerao automtica de montadores a partir de uma descrio do processador feita utilizando-se a ADL ArchC

11 [RIG 04]. Em [TAG 05b] e [TAG 05a] as informaes especcas da arquitetura so extradas da descrio ArchC e armazenadas em estruturas de dados, as quais so combinadas a um parser do cdigo assembly da arquitetura-alvo, que tambm gerado a partir da descrio do processador. Em um arquivo separado, so descritas informaes sobre pseudoinstrues e sobre o clculo dos endereos-alvo dos desvios, e este arquivo utilizado para gerar um pr-processador, o qual integrado ao montador no nal do processo. J a abordagem em [BAL 05a] baseia-se nas ferramentas do pacote GNU Binutils [BIN 05] para redirecionar o montador GNU (gas) para uma determinada arquiteturaalvo. Primeiramente, foi feita uma extenso da linguagem ArchC, adicionando-se novas construes que permitissem a incluso de informaes necessrias gerao automtica do montador, como informaes sobre diferentes sintaxes assembly e decodicao de operandos das instrues [BAL 05b]. Com estas informaes extradas da descrio ArchC, so gerados automaticamente os arquivos do pacote GNU Binutils que so dependentes da arquitetura-alvo, enquanto os arquivos e bibliotecas independentes so reutilizados. Em [CAS 06] as ferramentas do pacote GNU Binutils tambm foram utilizadas, mas desta vez na gerao automtica de linkeditores a partir de uma descrio ArchC, redirecionando o linkeditor GNU (ld). As informaes sobre relocaes so includas na descrio ArchC re-utilizando ao mximo as construes j existentes na linguagem, mas foi feita ainda uma extenso da ferramenta descrita em [BAL 05a] para que os montadores por ela gerados fossem capazes de inserir informaes de relocao para serem usadas como insumo para o linkeditor. Uma reviso abrangente sobre compiladores redirecionveis e tcnicas de redirecionamento de ferramentas pode ser encontrada em [LEU 01].

2.2

Anlise de restries temporais

Na rea de compiladores, os algoritmos clssicos de escalonamento no abordam

diretamente a factibilidade sob restries temporais, pois so focados em otimizar o de-

12 sempenho mdio. No entanto, a anlise de restries temporais no escalonamento foi abordada em trabalhos nas reas de sntese comportamental e gerao de cdigo para DSPs.

Um grafo orientado ponderado foi proposto em [MIC 94] como forma de se unicar a representao de restries temporais e dependncias de dados entre instrues. Com as relaes de precedncia e de tempo sendo codicadas como arestas no grafo, este modelo trata o problema do escalonamento sob restries temporais como um problema de clculo de caminho mais longo, permitindo assim que seja feita uma anlise de factibilidade do escalonamento utilizando-se algoritmos clssicos como o de Bellman-Ford [COR 90].

Como o modelo descrito em [MIC 94] assume que os recursos da arquitetura-alvo so ilimitados, ele de pouco uso prtico, caso no seja combinado com tcnicas que assumam restries de recursos.

Em [MES 97] foi proposta uma extenso deste modelo onde todas as restries (de tempo, de precedncia e de recursos) so modeladas no mesmo grafo. Os vrtices do grafo representam as operaes, enquanto que as arestas representam as restries entre elas. Por exemplo, se duas operaes competem por um mesmo recurso, este conito evitado atravs da insero de uma aresta ponderada entre elas, cujo peso o atraso do recurso em questo. Da mesma forma, cada vez que uma operao escalonada so inseridas novas arestas. A cada nova operao escalonada, um analisador invocado para vericar se o escalonamento satisfaz as restries codicadas no grafo. Como a insero destas novas arestas reduz as possibilidades de ordenamento das instrues, o analisador acelera a convergncia para um escalonamento factvel, ou seja, quanto mais rgidas forem as restries, mais rapidamente a soluo encontrada. Como esta abordagem assume que a arquitetura-alvo um processador DSP com conjunto de instrues VLIW (very long instruction word), ela no totalmente adequada para a explorao do espao de projeto em SoCs, j que durante este processo devem ser levadas em considerao diferentes arquiteturas como ASIPs e processadores de propsitos gerais.

13

2.3

Otimizao ps-compilao
Apesar de muitos compiladores realizarem otimizaes durante o processo de gera-

o de cdigo objeto, estas melhorias visam normalmente otimizar o desempenho mdio e baseiam-se em otimizaes independentes da arquitetura para a qual se est compilando. Na literatura, entre os trabalhos sobre otimizaes feitas aps a compilao destacam-se o projeto SALTO [SAL 06] e PROPAN [KS 00]. A tcnica descrita em [SAL 06] baseia-se em um framework em que o usurio pode implementar ferramentas de otimizao de cdigo compilado. O framework baseia-se em uma descrio formal da arquitetura-alvo atravs de uma ADL similar linguagem LISP. Esta descrio lida juntamente com o cdigo a ser otimizado, e este cdigo transformado em uma representao intermediria. Atravs de uma interface, o usurio pode manipular esta representao intermediria. Dados como tabelas de recursos, de dependncias e de latncias entre instrues podem ser acessados, e o cdigo pode ser modicado atravs da insero ou remoo de instrues. O usurio tem a opo de implementar ferramentas para a otimizao ou para o proling do cdigo, para isto tendo que prover os algoritmos adequados. A ferramenta SALTO foca principalmente em arquiteturas do tipo VLIW. J a ferramenta PROPAN [KS 00] tem como foco principal os DSPs. Ela toma como entrada uma descrio da arquitetura-alvo atravs da linguagem TDL [KS 03], gerando um parser do cdigo assembly e armazenando informaes dependentes da arquitetura em estruturas de dados internas. Aps a leitura da descrio da arquitetura-alvo, PROPAN renomeia os registradores para eliminar dependncias de nomes. Em seguida, so aplicadas otimizaes especcas da arquitetura-alvo, as quais so baseadas em tcnicas que levam em conta superblocos1 de cdigo. Apesar de alcanar bons resultados quanto reduo de cdigo quando comparada com outras heursticas, esta tcnica tem um tempo de computao signicativamente alto [LEU 01].
1

Superblocos so trechos de cdigo que envolvem instrues pertencentes a mltiplos blocos bsicos,

com o objetivo de explicitar mais paralelismo e com isso aumentar as chances de otimizao.

14

2.4

Traduo binria
Alm de realizar otimizaes no cdigo gerado pelo compilador, levando em conta

restries temporais, a ferramenta proposta nesta dissertao pode ser integrada a um tradutor binrio, permitindo assim que um cdigo assembly seja traduzido de uma determinada arquitetura para outra e seja em seguida otimizado para esta arquitetura alvo. Por isso, cabe aqui uma breve anlise dos trabalhos em traduo binria mais relevantes para a discusso do Captulo 5. Os trabalhos em [CIF 99] e [CIF 00] apresentam a ferramenta UQBT, um tradutor binrio capaz de gerar cdigo para arquiteturas baseadas em registradores ou em pilha. A ferramenta re-utiliza informaes independentes da arquitetura-alvo, enquanto que as informaes dependentes da arquitetura (incluindo sintaxe e semntica das instrues, alm da indicao de quais instrues causam transferncia de controle quando executadas) devem ser fornecidas atravs de descries em diferentes linguagens. O cdigo a ser traduzido transformado em uma representao intermediria similar de uma descrio RTL, a qual descreve a maneira como as instrues da arquitetura-fonte interagem com os registradores. Esta representao transformada em uma de mais alto nvel e independente da arquitetura, a qual descreve transferncias de controle elementares (desvios condicionais, incondicionais, chamadas de procedimento, etc.) e supe um nmero innito de registradores. Levando em considerao os parmetros da arquitetura-alvo, esta descrio ento transformada novamente na descrio similar de RTL, a qual usada para gerar cdigo. Isto permite, por exemplo, que seja feita a traduo de cdigo de uma arquitetura baseada em pilha para outra baseada em registradores. Enquanto o UQBT aborda a traduo binria esttica, o trabalho apresentado em [CIF 02] descreve um framework, chamado Walkabout, focado na traduo binria dinmica, o qual inspirado no UQBT. Similarmente ao UQBT, a ferramenta Walkabout utiliza descries das sintaxes e semntica das instrues para obter redirecionabilidade. No processo de traduo, o cdigo-fonte primeiramente carregado em uma memria virtual e interpretado at que seja detectado um trecho recorrente ou um hot path 2 . Este
2

Trecho de cdigo executado com bastante freqncia.

15 trecho ento traduzido e submetido a algumas otimizaes simples. O cdigo resultante colocado em uma memria cache de instrues traduzidas. Os interpretadores e a ferramenta que identica os hot paths so gerados automaticamente a partir das descries da sintaxe e semntica das instrues, feitas com as linguagens SLED [RAM 97] e SSL [CIF 98] respectivamente.

Captulo 3 Fundamentao Terica

3.1 Modelagem de CPUs
A descrio de um processador atravs de uma ADL um bom ponto de partida para a gerao de ferramentas redirecionveis. O escalonador redirecionvel a ser descrito no Captulo 4 requer que as propriedades da CPU-alvo sejam representadas atravs de um modelo formal. Para ns de implementao, os modelos de CPUs so descritos atravs da ADL ArchC [RIG 04]. Embora qualquer ADL capaz de descrever as propriedades necessrias ao escalonamento pudesse ser usada, a adoo de ArchC - sem perda de generalidade - deve-se sua disponibilidade sob licena GPL (General Public License) e ao fato de gerar modelos em SystemC adequados ao estilo TLM. Nesta seo, primeiramente a estrutura de um modelo ArchC ilustrada atravs de exemplos e, em seguida, algumas extenses so propostas na linguagem para permitir a descrio de propriedades especcas utilizadas pelo escalonador.

3.1.1

Estrutura bsica do modelo

Basicamente, um modelo descrito em ArchC dividido em trs partes principais, que residem em arquivos separados: Parmetros da arquitetura: neste arquivo so denidos os recursos da arquitetura como endian e os tamanhos do banco de registradores, da memria cache e da

17 palavra de dados. Nos modelos com preciso de ciclos, aqui so tambm declarados os estgios do pipeline, bem como registradores especcos utilizados no transporte de informaes entre um estgio e outro. Alm disto, este arquivo referencia o arquivo que contm a descrio da arquitetura do conjunto de instrues ou ISA (Instruction Set Architecture). A Figura 3.1 mostra um exemplo de descrio dos parmetros da arquitetura MIPS.

AC_ARCH(mips1) { ac_wordsize 32; ac_cache DM:5M; ac_regbank RB:34;

// Tamanho da palavra // Tamanho da memria cache // Tamanho do banco de registradores

ARCH_CTOR(mips1) { // Referncia ao arquivo que descreve a arquitetura do conjunto de instrues ac_isa("mips1_isa.ac"); set_endian("big"); // Declarao arquitetura como big endian }; };

Figura 3.1: Descrio dos parmetros da arquitetura em ArchC

Arquitetura do conjunto de instrues: este arquivo dividido em duas sees principais: a descrio das caractersticas do conjunto de instrues e a descrio das propriedades das instrues da ISA. Na primeira seo, so descritos os diferentes formatos de instruo da arquitetura, bem como a lista de instrues, associando-as a seus respectivos formatos. feita ainda a declarao de nomes simblicos dos registradores, que so usados pelo compilador ao gerar o cdigo assembly. Na segunda seo, so declaradas propriedades especcas de cada instruo como, por exemplo, as suas diferentes sintaxes assembly, valores dos campos de cdigo operacional utilizados na sua decodicao, a maneira como efetuado o clculo do endereo-alvo de instrues de desvio, etc. A Figura 3.2 mostra um fragmento da descrio da ISA do MIPS.

Comportamento das instrues: neste arquivo descrito o comportamento de cada instruo. possvel descrever comportamentos especcos para cada instruo,

18
AC_ISA(mips1) { // Formatos de instruo ac_format Type_R = "%op:6 %rs:5 %rt:5 %rd:5 %shamt:5 %func:6"; ac_format Type_I = "%op:6 %rs:5 %rt:5 %imm:16:s"; ac_format Type_J = "%op:6 %addr:26"; // Instrues associadas aos seus formatos ac_instr<Type_I> beq; ac_instr<Type_R> add; // Mapeamento de nomes dos registradores ac_asm_map reg { "$"[0..31] = [0..31]; "$zero" = 0; "$at" = 1; "$kt"[0..1] = [26..27]; "$gp" = 28; "$sp" = 29; "$fp" = 30; "$ra" = 31; } // Propriedades das instrues ISA_CTOR(mips1) { add.set_asm("add %reg, %reg, %reg", rd, rs, rt); add.set_decoder(op=0x00, func=0x20); beq.set_asm("beq %reg, %reg, %expR4A", rs, rt, imm); beq.set_asm("b %expR4A", imm, rs=0, rt=0); beq.set_asm("beqz %reg, %expR4A", rs, imm, rt=0); beq.set_decoder(op=0x04); beq.is_branch((ac_pc+4) + (imm<<2)); beq.cond(RB[rs] == RB[rt]); beq.delay(1) }; };

Figura 3.2: Descrio da arquitetura do conjunto de instrues em ArchC

comportamentos comuns a todas as instrues de um determinado formato ou ainda um comportamento que comum a todas as instrues da ISA (por exemplo, incrementar o program counter). A descrio dos comportamentos feita em cdigo C++. A Figura 3.3 mostra um exemplo de descrio contendo um comportamento comum a todas as instrues do MIPS e o comportamento de uma instruo especca. Apesar de a ADL ArchC prover uma variedade de opes para se descrever um modelo de uma arquitetura, h algumas informaes requeridas pelo escalonamento de cdigo cuja descrio no era originalmente suportada nos modelos ArchC. Em face das limitaes da ADL, algumas extenses foram propostas para viabilizar o escalonamento

19
#include #include "mips1-isa.H" "ac_isa_init.cpp"

// Comportamento geral de todas as instrues void ac_behavior( instruction ) { #ifndef NO_NEED_PC_UPDATE ac_pc = ac_pc +4; #endif }; // Comportamento da instruo lb void ac_behavior( lb ) { char byte; byte = DM.read_byte(RB[rs]+ imm); RB[rt] = (ac_Sword)byte ; };

Figura 3.3: Descrio do comportamento de instrues em ArchC

redirecionvel ps-compilao, conforme descrito nas Sees 3.1.2 e 3.1.3.

3.1.2

Limitaes da modelagem ArchC

Como o escalonador redirecionvel opera aps o programa-fonte ter sido compilado, ele deve ser capaz de determinar as dependncias de dados a partir do cdigo em linguagem de montagem. Infelizmente, em sua verso original, as construes da ADL ArchC no capturavam informaes que permitissem diretamente a anlise de uxo de dados, como explicado abaixo: Operandos fonte e destino no explicitados: Para determinar dependncias de dados atravs de registradores, necessrio detectar se o operando-destino de uma instruo o operando-fonte de uma outra. As construes ArchC permitem descrever os campos que codicam operandos, bem como associar os operandos da sintaxe assembly a seus respectivos campos nos formatos de instruo, mas no permitem distinguir quais campos codicam operandos-fonte e quais campos codicam operandos-destino. Campos que determinam endereo efetivo no explicitados: Para determinar dependncias de dados atravs da memria e para fazer desambiguao esttica de memria no programa, necessrio identicar os campos que determinam o ende-

20 reo efetivo de memria usado por instrues load ou store. As construes ArchC permitem descrever os campos usados para compor endereos (registrador-base e imediato), mas no permitem identicar quais campos so efetivamente utilizados para determinar o endereo de memria. Latncia entre instrues no explicitadas: Para possibilitar que um escalonador esttico possa reordenar as instrues sem a introduo de bolhas no pipeline devido a conitos de dados, preciso codicar as latncias entre instrues, ou seja, o nmero de ciclos que se precisa intercalar entre duas instrues para garantir que o dado seja produzido pela primeira instruo antes que a segunda tente consumi-lo. As construes ArchC no permitem descrever as latncias entre instrues. Em princpio, em uma descrio funcional com preciso de ciclos possvel determinar as latncias atravs de uma anlise da estrutura do pipeline e dos caminhos de bypass-forwarding, codicados no arquivo de comportamentos. Entretanto, a implementao automtica de tal anlise para extrair as latncias seria ineciente, uma vez que aquele arquivo permite vrios estilos de descrio. Ademais, a extrao de latncias a partir do arquivo de comportamentos no permitiria que o escalonador pudesse ser usado sobre descries puramente funcionais (sem preciso de ciclos). Como o conceito de latncia fundamental para a discusso a ser feita na Seo 3.3, sua denio formal apresentada a seguir. Denio 3.1 - A latncia entre duas instrues o nmero de ciclos que se precisa intercalar entre elas para garantir que o dado produzido pela primeira instruo esteja disponvel antes que a segunda possa consumi-lo. Felizmente, os desenvolvedores de ArchC disponibilizam um mecanismo genrico para a extenso dos modelos com informaes necessrias a novas aplicaes. Este mecanismo baseia-se na construo set_property. Desta forma, no necessrio criar uma nova palavra-chave para cada nova propriedade que se precise descrever no modelo ArchC. Primeiramente, cada nova propriedade deve ser declarada utilizando-se uma construo do tipo ac_property, que tem a seguinte estrutura bsica:

21 ac_property{propriedade_1, propriedade_2, ..., propriedade_n} Em seguida, deve-se associar cada propriedade aos elementos da descrio. Tal associao feita atravs da seguinte declarao: <dono da propriedade>.set_property(<propriedade>, <descrio>); Os elementos de tal declarao so os seguintes: <dono da propriedade>: pode ser uma instruo, um formato ou ainda um mapeamento de nomes declarado pela construo ac_asm_map, ou seja, uma propriedade pode ser associada a uma instruo especca ou a todas as instrues de um mesmo formato, ou ento, por exemplo, a um grupo de registradores (para se declarar quais so usados como registradores de propsito geral). <propriedade>: nome da propriedade a ser associada; este nome deve ter sido declarado utilizando-se ac_property. <descrio>: a descrio especca da propriedade sendo associada. Por exemplo, se queremos declarar qual o operando destino de uma instruo, a descrio da propriedade seria o nome deste operando. O parser do modelo ArchC se encarrega de vericar se todas as propriedades referenciadas em set_property foram declaradas na construo ac_property, e monta uma lista que relaciona todas propriedades, a quem foram associadas e qual a descrio de cada uma. Cada ferramenta que utiliza o parser do modelo se encarrega de tratar esta lista, validando as propriedades e suas descries. A seguir, so listadas as propriedades a serem declaradas para viabilizar o escalonamento de cdigo, bem como a sintaxe adotada para a declarao dessas propriedades.

3.1.3

Extenses propostas para viabilizar o escalonamento de cdigo

As extenses a seguir sugeridas contornam as limitaes descritas na Seo 3.1.2, explicitando os campos que descrevem operandos-fonte e destino e endereo efetivo, ex-

22 plicitando as latncias entre instrues, alm de explicitar quais registradores sero considerados de uso geral para ns de alocao de registradores. Propriedade source: esta propriedade dene quais so os operandos fonte de uma instruo. A sua descrio deve conter uma lista com nomes de campos do formato da instruo, declarados com ac_format. Pode-se ainda explicitar que uma instruo tem como operando-fonte um valor da memria, sendo que para isso declarase uma lista, entre colchetes, dos campos que compe o endereo da memria onde este valor ser lido. A Figura 3.4 mostra exemplos do uso de set_property para explicitar quais so os operandos-fonte de uma instruo.

// Todas as instrues do tipo R tm como fontes os operandos "rs" e "rt". Type_R.set_property(source,(rs,rt)); // Instruo "sll" tem como fontes os operandos "rt" e "shamt". sll.set_property(source,(rt,shamt)); // Instruo "sw" tem como fontes os operandos "rt", "imm" e "rs". sw.set_property(source,(rt,imm,rs)); // Instruo "lw" tem como fontes os operandos "imm", "rs" e o valor na // posio de memria composta por "imm" e "rs". lw.set_property(source,(imm,rs,[imm,rs]));

Figura 3.4: Usando set_property para explicitar operandos fonte

Propriedade dest: esta propriedade dene os operandos destino de uma instruo. Similarmente propriedade source, a sua descrio deve conter uma lista com nomes de campos do formato da instruo, declarados com ac_format, ou uma lista de campos entre colchetes para indicar que a instruo tem como destino uma posio na memria. A Figura 3.5 mostra exemplos do uso de set_property para explicitar quais so os operandos destino de uma instruo.

Propriedade efa: com esta propriedade, declaram-se quais campos codicam os componentes utilizados no clculo do endereo efetivo de memria a ser lido ou escrito pela instruo. A descrio da propriedade efa deve conter uma lista, entre colchetes, destes campos (declarados com ac_format). A Figura 3.6 mostra

23
// Todas as instrues do tipo R tm como destino o operando "rd". Type_R.set_property(dest,rd); // Instruo "sw" tem como destino a posio de memria determinada // pela composio dos campos "imm" e "rs". sw.set_property(dest,[imm,rs]); // Instruo "lw" tem como destino o operando "rt". lw.set_property(dest,rt);

Figura 3.5: Usando set_property para explicitar operandos destino

exemplos do uso de set_property para explicitar quais so os campos que compe o endereo efetivo de memria acessado por uma instruo.

// Para as instrues "sw" e "lw", os campos que compem o endereo // efetivo de memria por elas acessado so "imm" e "rs". sw.set_property(efa,[imm,rs]); lw.set_property(efa,[imm,rs]);

Figura 3.6: Usando set_property para declarar campos do endereo de memria

Propriedade latency: usada para declarar a latncia entre duas instrues. A descrio desta propriedade contm trs elementos: a instruo em relao qual estamos declarando a latncia (a instruo sucessora e que consome o dado produzido pela instruo corrente), o nome do operando-fonte da instruo sucessora que conter o valor produzido pela instruo corrente e o nmero de ciclos de latncia a serem intercalados. O segundo elemento pode ser tanto um campo da instruo (declarado com ac_format) ou uma concatenao de campos que indicam uma posio de memria (declarada utilizando uma lista de campos entre colchetes). O nmero de ciclos de latncia entre diferentes pares de instrues uma informao usualmente disponvel nos manuais dos processadores. A Figura 3.7 mostra exemplos do uso de set_property para declarar latncias entre instrues.

Propriedade gpr: esta uma propriedade que deve ser associada a um grupo de mapeamentos feitos com ac_asm_map, quando este grupo representa o mapeamento dos nomes dos registradores (nomes usados pelos compiladores na gerao

24
// Quando um "lw" produz um valor a ser consumido por um // "add", h uma latncia de 1 ciclo (independentemente // do campo - "rs" ou "rt" - utilizado para codificar o // registrador onde o valor ser armazenado). lw.set_property(latency, (add,rt,1)); lw.set_property(latency, (add,rs,1)); // Quando um "lw" produz um valor a ser consumido por um // "sw", as latncias so de 0 ou 1 ciclo, conforme o // valor seja referenciado no campo "rs" e "rt", respectivamente. lw.set_property(latency, (sw,rs,0)); lw.set_property(latency, (sw,rt,1)); // Quando um "sw" escreve um valor na memria em um // endereo, composto pelos campos "imm" e "rs", onde um // "lw" ler um valor, h uma latncia de 1 ciclo. sw.set_property(latency, (lw,[imm,rs],1));

Figura 3.7: Usando set_property para declarar latncias entre instrues

do cdigo assembly) aos seus nmeros no banco de registradores real, para indicar quais registradores so considerados de propsitos gerais para ns de alocao de registradores. A descrio desta propriedade contm uma lista com os nomes dos registradores. A Figura 3.8 mostra exemplos do uso de set_property para declarar a lista de registradores de propsitos gerais da arquitetura.

// Dentre os registradores declarados com "ac_asm_map", // especifica a lista de registradores de propsitos gerais. reg.set_property(gpr,("$8","$9","$10","$11","$12","$13","$14"));

Figura 3.8: Usando set_property para declarar registradores de propsitos gerais

3.2

Representao intermediria do cdigo

Para garantir redirecionabilidade ao escalonador, a representao do programa a ser

escalonado deve ser independente da arquitetura-alvo. Assim, uma vez que o modelo ArchC tenha capturado as propriedades descritas nas sees anteriores, uma representao intermediria do cdigo pode ser obtida atravs das anlises de uxo controle e de dados, conforme descrito a seguir.

25

3.2.1

Grafo de uxo de controle

Um programa escrito em linguagem de montagem pode ser decomposto em trechos de cdigo sem ramicaes denominados blocos bsicos. Denio 3.2 - Um bloco bsico (BB) a mais longa seqncia de instrues (i, i+1, ..., n) tal que: Se a instruo i executada, ento n ser tambm executada; Se a instruo n executada, ento i foi tambm executada. Um BB pode ser identicado pelo seguinte conjunto de regras [AHO 95]: Regra 1 - Iniciam um bloco bsico: A primeira instruo do cdigo. Instrues que so alvo de um desvio condicional ou incondicional. Instrues precedidas por uma instruo de desvio condicional ou incondicional. Regra 2 - Encerram um bloco bsico: Instrues de desvio condicional ou incondicional. A ltima instruo do cdigo. Uma vez dividido em blocos bsicos, o cdigo pode ser representado atravs de um grafo de uxo de controle, denido a seguir: Denio 3.3: Um grafo de uxo de controle CFG(V, E) um grafo orientado onde cada vrtice bi representa um BB e cada aresta (bi , bj ) representa a ordem de precedncia entre dois BBs no uxo de execuo do programa. Como conseqncia dessa denio, as arestas de um CFG podem ser identicadas pelo seguinte conjunto de regras: Regra 3 - Se um BB bi termina em desvio condicional, bi tem duas arestas emergentes (bi , bj ) e (bi , bk ), cada uma representando um uxo de execuo alternativo: um para o caso de desvio tomado, outro para o caso de desvio no tomado.

26 Regra 4 - Se um BB bi termina em desvio incondicional, bi tem uma nica aresta emergente (bi , bj ), onde bj o BB que contm a instruo-alvo daquele desvio. Regra 5 - Se um BB bi no termina com instruo de desvio, bi tem uma nica aresta emergente (bi , bj ), tal que a ltima instruo de bi predecessora imediata da primeira instruo de bj na seqncia do cdigo. A Figura 3.9 ilustra um CFG obtido a partir de um segmento de cdigo atravs da aplicao das Regras 1 a 5.

Figura 3.9: Exemplo de grafo de uxo de controle

3.2.2

Grafo de uxo de dados

Enquanto o CFG captura o uxo de execuo do programa, a relao de precedncia entre as instrues de um dado BB pode ser representada atravs de um grafo de uxo de dados, como formalizado a seguir: Denio 3.4: Um grafo de uxo de dados DFG(V, E) um grafo polar orientado onde cada vrtice vi representa uma instruo e cada aresta (vi , vj ) representa o uxo de um valor produzido por vi e consumido por vj . Os plos do grafo, v0 e vn , so chamados

27 source e sink respectivamente e representam os valores iniciais de entrada e os valores nais de sada. As restries de precedncia so impostas pelas dependncias de dados entre as instrues do bloco bsico, ou seja, a produo de um dado deve preceder seu consumo. Cada vrtice do CFG ser associado a um DFG. A Figura 3.10 mostra o DFG correspondente ao bloco b2 do grafo da Figura 3.9.

Figura 3.10: Exemplo de grafo de uxo de dados

3.3

Modelagem de restries temporais

Como visto na seo anterior, o DFG representa as instrues de um bloco bsico

e suas dependncias de dados. No entanto, para escalonar instrues necessrio capturar as restries temporais, tanto aquelas devidas s latncias entre as instrues como aquelas devido a restries de tempo real impostas a um trecho de cdigo. A tcnica aqui descrita adota a modelagem de restries temporais proposta em [MIC 94]. Isto leva a uma representao mais genrica para as relaes entre as instrues de um BB, como formalizado a seguir:

28 Denio 3.5: Um grafo ponderado de precedncia WPG(V, E, W) um grafo polar orientado, onde cada vrtice vi representa uma instruo, cada aresta representa uma restrio de precedncia, e cada peso wij Z representa o atraso relativo entre os tempos de incio das instrues vi e vj . As arestas do WPG, alm de representarem as dependncias de dados entre as instrues, tambm encapsulam o nmero de ciclos que uma instruo deve aguardar para consumir um dado produzido por outra. No entanto, uma aresta do WPG pode tambm representar apenas uma restrio temporal entre duas instrues, conforme as denies 3.6, 3.7 e 3.8 a seguir: Denio 3.6: Sejam um WPG(V, E, W) e um nmero k Z+ . Um atraso mnimo de k ciclos entre os tempos de incio de duas instrues vi e vj V representado por uma aresta (vi , vj ) E com peso wij = +k, desta forma restringindo a instruo vj a iniciar sua execuo pelo menos k ciclos aps a instruo vi ter iniciado a sua. Denio 3.7: Sejam um WPG(V, E, W) e um nmero k Z+ . Um atraso mximo de k ciclos entre os tempos de incio de duas instrues vi e vj V representado por uma aresta (vj , vi ) E com peso wji = -k, desta forma restringindo a instruo vj a iniciar sua execuo no mximo k ciclos aps a instruo vi ter iniciado a sua. Denio 3.8: Sejam um WPG(V, E, W) e um nmero k Z+ . Um atraso exato de k ciclos entre os tempos de incio de duas instrues vi e vj V representado por uma aresta (vi , vj ) E com peso wij = +k e uma aresta (vj , vi ) E com peso wji = -k, desta forma restringindo a instruo vj a iniciar sua execuo exatamente k ciclos aps a instruo vi ter iniciado a sua.

3.3.1

Modelagem de atrasos, latncias e deadlines

A Figura 3.11 mostra a incorporao de restries temporais s arestas do grafo da Figura 3.10. Note que, como conseqncia da Denio 3.6, quando h uma dependncia de dados entre duas instrues especica-se que h um atraso mnimo entre produtor e consumidor atravs de um peso positivo atribudo aresta que representa a restrio de prece-

29

Figura 3.11: Exemplo de grafo ponderado de precedncia

dncia. O peso desta aresta igual ao valor da latncia entre as duas instrues (conforme a Denio 3.1) mais um. Assim, a modelagem de latncias englobada pela Denio 3.6. Observe tambm que um atraso mximo de 10 ciclos foi imposto entre os vrtices source e sink. Isto signica que todas as instrues compreendidas naquele BB precisam iniciar sua execuo dentro deste intervalo de tempo. Portanto, a modelagem de deadlines capturada pela Denio 3.7.

3.3.2

Modelagem de outros efeitos de temporizao

Esta seo aborda a modelagem de vrios efeitos de temporizao associados a arquiteturas contemporneas e discute as limitaes da modelagem proposta no contexto de tempo real.

3.3.2.1

Desvios com atraso

As arestas ponderadas podem tambm ser usadas para a modelagem de desvios com atraso, que utilizam os chamados delay slots [PAT 04]. Em arquiteturas RISC bem conhe-

30 cidas, como o MIPS e o SPARC, uma instruo pode ser colocada neste slot e desta forma ser executada antes de o desvio ser realizado. Caso nenhuma instruo seja colocada no slot, uma instruo de nop (no operation) deve ser inserida ali (compiladores como o gcc normalmente inserem este nop ao gerar o cdigo assembly). H ainda a possibilidade, em algumas arquiteturas, de serem usados desvios com anulao do slot. Nestes casos, a instruo que reside no slot no ser executada em alguns casos especcos. Como as informaes descritas acima podem ser codicadas no modelo ArchC utilizando-se construes como delay e delay_cond, tais restries de temporizao podem ser modeladas da seguinte forma: Regra 6 - A uma instruo de desvio com anulao do slot atribui-se um atraso exato de 1 ciclo em relao ao vrtice sink do WPG, mas a qualquer outra instruo do mesmo BB atribudo um atraso mnimo de 2 ciclos em relao a sink. A Figura 3.12 mostra o WPG correspondente a um trecho de cdigo terminado em uma instruo de desvio com anulao do delay slot, onde a aplicao da Regra 6 resulta na insero das arestas pontilhadas.

Figura 3.12: Modelagem de instruo de desvio com anulao do slot

Regra 7 - A uma instruo de desvio sem anulao do slot atribui-se um atraso exato de 1 ciclo em relao ao vrtice sink do WPG e no h restrio alguma de atraso

31 mnimo para as demais instrues do BB (que podem ser candidatas a escalonamento no slot). A Figura 3.13 mostra o WPG correspondente a um trecho de cdigo terminado em uma instruo de desvio sem anulao do delay slot. A insero das arestas pontilhadas o resultado da aplicao da Regra 7.

Figura 3.13: Modelagem de instruo de desvio sem anulao do slot

Deve-se ressaltar que as Regras 6 e 7 deliberadamente restringem o escalonamento de cdigo no mbito de blocos bsicos. A discusso da pragmaticidade e adequao desta deciso feita na Seo 4.1. Desta forma, no primeiro caso obriga-se a instruo de desvio a ser a ltima a ser escalonada no BB (e o escalonador colocar um nop no slot, pois a instruo no slot correria o risco de no ser executada, violando a noo de bloco bsico), enquanto que, no segundo caso, obriga-se a instruo de desvio a ser a penltima, pois assim outra instruo do mesmo BB pode residir no slot.

3.3.2.2

Latncias do subsistema de memria

A modelagem proposta sucientemente genrica para capturar as restries temporais impostas s instrues load e store devidas s latncias do subsistema de memria. Entretanto, deve-se ter em mente que, para ns de anlise de tempo real, no faz sentido

32 modelar-se o caso mdio, mas o intervalo de latncias a que esto suscetveis as instrues de acesso memria, conforme discutido a seguir. Basicamente, o subsistema de memria pode ser implementado por dois tipos de memria: memrias com seleo atravs de endereo (RAM, ROM, Flash) ou memrias com seleo atravs de tags (memrias associativas). Alm disso, ele pode ser organizado com hierarquia de memria (por exemplo, memrias cache [PAT 04]) ou sem hierarquia (por exemplo, scratch pads [MAR 03]). Seja ta o tempo de acesso a um subsistema de memria sem hierarquia. A modelagem desta latncia de memria feita conforme descrito nas Regras 8 e 9. Regra 8 - Em um sistema sem hierarquia de memria, entre uma instruo load vi produtora e uma instruo arbitrria vj consumidora devem ser inseridas no WPG as seguintes arestas: (vi , vj ) tal que wij = ta ; (vj , vi ) tal que wji = -ta . Regra 9 - Em um sistema sem hierarquia de memria, entre uma instruo arbitrria vi produtora e uma instruo store vj consumidora devem ser inseridas no WPG as seguintes arestas: (vi , vj ) tal que wij = ta ; (vj , vi ) tal que wji = -ta . Sejam agora thit e tmiss os tempos de acesso quando um dado encontrado no nvel inferior ou no nvel superior da hierarquia, respectivamente. A modelagem destas latncias feita de acordo com a Regras 10 e 11. Regra 10 - Em um sistema com hierarquia de memria, entre uma instruo load vi produtora e uma instruo arbitrria vj consumidora devem ser inseridas no WPG as seguintes arestas: (vi , vj ) tal que wij = thit ; (vj , vi ) tal que wji = -tmiss .

33 Regra 11 - Em um sistema com hierarquia de memria, sejam uma instruo arbitrria vi produtora e uma instruo store vj consumidora. So inseridas duas arestas no WPG:

(vi , vj ) tal que wij = thit ;

(vj , vi ) tal que wji = -tmiss .

Vale ressaltar que, como os tempos thit e tmiss podem diferir de uma ou mais ordens de magnitude, muitos sistemas de tempo real utilizam a tcnica de scratch pad para acelerar o acesso a dados ao invs de recorrer estrutura hierrquica de memria.

3.3.2.3

Efeitos dinmicos de execuo

Vrias arquiteturas contemporneas desenvolvidas originalmente para o mercado de computao de uso geral so utilizadas em sistemas embarcados, possivelmente com requisitos de tempo real. Ora, vrias tcnicas dinmicas para explorao de paralelismo de baixa granularidade foram introduzidas para melhorar a execuo do caso mdio, tais como previso dinmica de desvios, escalonamento dinmico de cdigo, execuo especulativa dinmica [PAT 06]. Essas tcnicas visam permitir a execuo fora de ordem (out-of-order execution) do cdigo para otimizar o caso mdio, mas no oferecem garantia alguma sobre a factibilidade de restries de tempo real, uma vez que elas deterioram a previsibilidade do pior caso de execuo, inviabilizando a anlise de factibilidade em tempo de compilao. Por isso, arquiteturas destitudas de tcnicas dinmicas so muitas vezes adotadas sob restries severas de tempo real como, por exemplo, as arquiteturas VLIW subjacentes a vrios processadores DSP. Portanto, como a modelagem aqui proposta visa a anlise de factibilidade de restries de tempo real, no faz sentido empreg-la para a modelagem de efeitos dinmicos.

34

3.3.3

Vericao da factibilidade do escalonamento

Aps terem sido construdos WPGs para todos os blocos bsicos, cada BB submetido ao escalonador, o qual associar cada instruo a um tempo de incio respeitando as restries de precedncia entre as instrues devido s dependncias de dados, conitos de recursos e restries temporais. A funo que faz este mapeamento descrita pela Denio 3.9. Denio 3.9: Seja (vi , t) uma funo que associa cada instruo vi no tempo t a um tipo de recurso necessrio sua execuo. Seja ar o nmero de recursos do tipo r no processador-alvo. Uma funo chamada schedule : V N mapeia cada instruo vi a um tempo de incio (vi ) tal que: - (vi , vj ) E: (vj ) (vi ) + wij ; - t em [(vi ), (vi ) + wij ] : |{vk V: [ (vk , t) = r] [t = (vk )]}| ar . Entretanto, preciso vericar se o escalonamento produzido pela funo schedule factvel quando levamos em conta as restries temporais e de precedncia. Em [MES 97] e [MIC 94] mostra-se que um algoritmo de clculo de caminho mais longo em grafos, como o algoritmo de Bellman-Ford [COR 90], pode induzir um escalonamento desde que as restries de recursos estejam corretamente codicadas no grafo. Em [COR 90] e [MIC 94] mostra-se que o algoritmo de Bellman-Ford pode ser usado em grafos polares com apenas uma fonte (neste caso, o vrtice source) para calcular o caminho mais longo desde a fonte a cada um dos outros vrtices. Se o algoritmo no convergir em um nmero nito de iteraes, ento h um ciclo positivo1 no grafo, o que signica que o conjunto de arestas representando restries temporais inconsistente. Esta a chave da anlise de factibilidade do escalonamento, a qual ser descrita em maiores detalhes no Captulo 4. Primeiramente, deve-se denir a noo de distncia entre dois vrtices no grafo: Denio 3.10: Seja um WPG(V, E, W) e um caminho p tal que um vrtice vi alcana um vrtice vj atravs de p. A distncia de vi a vj atravs de p, escrita d(vi , vj ),
1

Um ciclo positivo ocorre quando o valor do caminho mais longo da fonte a um ou mais vrtices cresce

a cada nova iterao do algoritmo, nunca convergindo para um valor estvel.

35 a soma dos pesos de todas as arestas que pertencem a p. Denio 3.11: Seja um WPG(V, E, W) e dois vrtices arbitrrios vi e vj , a maior distncia (vi , vj ) entre vi e vj dada por: p | vi alcana vj atravs de p : Max d(vi , vj ). Seja i uma notao simplicada para a maior distncia entre o vrtice v0 (source) e um vrtice arbitrrio vi , ou seja, i = (v0 , vi ). O valor de i ser determinado atravs de sucessivas estimativas reduzidas iterativamente. Seja k a estimativa de i na k-sima i iterao. O Algoritmo 1 descreve o clculo dos caminhos mais longos. Algoritmo 1 Clculo dos caminhos mais longos
Procedure: BellmanFord(G(V, E, W)) 1: 1 = 0; 0 2: for i = 1 to n do 3: if (v0 , vi ) then 4: 1 = w0i ; i 5: else 6: 1 = -; i 7: end if 8: end for 9: for j = 1 to n do 10: for i = 1 to n do 11: for k = 1 to n do 12: if k = i then 13: j+1 = MAX{j , (k + wki )}; i i i 14: end if 15: end for 16: end for 17: if j+1 == j i then i i 18: return TRUE; 19: end if 20: end for 21: return FALSE;

As linhas de 1 a 7 descrevem como as estimativas de distncia mxima so inicializadas com os pesos das arestas adjacentes ao vrtice source. As linhas de 9 a 16 mostram a relaxao dos valores das distncias mximas. As linhas de 17 a 21 detectam a convergncia (ou no convergncia) das estimativas.

Captulo 4 Otimizador de Cdigo Redirecionvel

Esta seo descreve a ferramenta que o principal produto de trabalho desta dissertao, o otimizador de cdigo redirecionvel. Primeiramente, so explicitadas algumas restries simplicadoras assumidas durante o desenvolvimento e, em seguida, so apresentadas a estrutura da ferramenta, seus principais componentes, as fases de processamento do cdigo assembly a ser otimizado e os principais algoritmos utilizados.

4.1

Restries simplicadoras
A grande variedade de arquiteturas disponveis, desde processadores de propsito

geral a ASIPs, com diferentes caractersticas quanto arquitetura do conjunto de instrues, modos de endereamento, tratamento de desvios etc., torna o desenvolvimento de uma ferramenta totalmente genrica quase invivel em termos de custos e tempo. Portanto, algumas hipteses simplicadoras so assumidas a m de restringir as caractersticas das arquiteturas-alvo suportadas e simplicar a gerao do cdigo otimizado, mas ao mesmo tempo prover uma ferramenta redirecionvel e capaz de fazer otimizaes de impacto em pontos crticos do cdigo. Restrio 1 - O escalonamento de cdigo restringe-se ao reordenamento de instrues dentro de seus BBs originais. Em outras palavras, a Restrio 1 descarta tcnicas de escalonamento global de

37 cdigo, tais como code motion [dS 98] e execuo especulativa [PAT 06], o que simplica signicativamente a implementao do escalonador 1 . Uma discusso sobre o impacto de se relaxar a Restrio 1 deixada para o Captulo 6. Note que a Restrio 1 no se refere alocao de registradores, nem anlise de restries de tempo real, que no se restringem s fronteiras dos BBs. Tambm se assume algumas hipteses que restrigem as arquiteturas-alvo suportadas pela ferramenta, conforme descrito abaixo. Restrio 2 - A CPU-alvo uma mquina load/store. A vasta maioria das CPUs concebidas a partir de 1990 obedece Restrio 2. Entretanto, como h ainda algumas mquinas remanescentes da era pr-RISC (tais como o processador Motorola Coldre e o microcontrolador Intel 8051), umas poucas arquiteturas em uso em sistemas embarcados no so suportadas. Restrio 3 - Todas as instrues ocupam cada estgio do pipeline durante um nico ciclo de relgio. Embora a maior parte das instrues inteiras de processadores modernos satisfaam Restrio 3, h instrues de ponto utuante que nela no se enquadram. Esta uma restrio que merece relaxamento em futuras extenses da ferramenta, pois uma mera questo de implementao. Restrio 4 - A cada ciclo de relgio, apenas uma instruo inicia a sua execuo. Em outras palavras, a Restrio 4 descarta arquiteturas com emisso mltipla como as superescalares e VLIW [PAT 06]. Esta tambm uma restrio que merece prioridade em futuras extenses da ferramenta, pois muitas das CPUs usadas em sistemas embarcados apresentam emisso mltipla.

4.2

Estrutura da ferramenta
Esta seo descreve os principais componentes do otimizador de cdigo.

Tcnicas globais exigem uma complexa anlise da viabilidade de se mover instrues entre blocos

e mecanismos complexos de compensao de cdigo para preservar a semntica original do programa [dS 98].

38 Parser do Modelo: o componente responsvel por extrair do modelo escrito em ArchC as informaes especcas da arquitetura-alvo. Como visto na Seo 3.1, o modelo contm diversas informaes das instrues da ISA que so necessrias ferramenta, especialmente as suas sintaxes assembly, os campos fonte e destino e as latncias entre instrues, assim como a declarao de quais registradores da arquitetura so de uso geral. Estas informaes extradas do modelo ArchC so armazenadas em estruturas de dados que sero mais tarde manipuladas por outros componentes da ferramenta, em especial o Parser do Cdigo Assembly e o Gerador de Cdigo (descritos a seguir). Parser do Cdigo Assembly: este componente l o cdigo assembly de entrada e, utilizando as informaes extradas pelo parser do modelo ArchC, gera o CFG e os WPGs correspondentes a cada bloco bsico. Escalonador e Analisador: recebem como entrada cada WPG gerado pelo parser do cdigo e buscam um escalonamento factvel (se houver algum) para cada bloco bsico, inserindo arestas no grafo para induzir um ordenamento das instrues. Gerador de Cdigo: aps o escalonador ter gerado os WPGs escalonados, este componente percorre cada grafo visitando os seus vrtices na ordem induzida pelo escalonador e gera o cdigo assembly otimizado. Durante este processo feita tambm a alocao de registradores, onde os nomes simblicos atribudos pelo parser do cdigo sero mapeados para nomes reais de registradores. So apresentados a seguir o uxo da ferramenta e o detalhamento de suas fases de processamento, mostrando como os componentes operam sobre o cdigo assembly.

4.3

Fases de processamento
A Figura 4.1 mostra o uxo de execuo da ferramenta. A seguir, cada fase de

processamento do uxo ser descrita, desde o cdigo assembly original at a gerao do cdigo assembly otimizado.

39

Figura 4.1: Fluxo de otimizao do cdigo

Fase 1: Insero de restries temporais Entrada: cdigo assembly original, gerado pelo compilador. Sada: cdigo assembly instrumentado (contendo as restries temporais).

Procedimento: Como um compilador convencional no captura restries temporais, elas so inseridas no cdigo atravs de um editor, gerando assim o assembly instrumentado. As restries so representadas por pares de pseudo-instrues que englobam trechos de cdigo. Por exemplo, um par de pseudo-instrues [MIN k, rotulo] e [/MIN rotulo] representa um atraso mnimo de k ciclos de relgio ao trecho de cdigo englobado por ele. De forma similar, atrasos exatos e mximos podem ser inseridos com os pares de pseudo-instrues [EXACT k, rotulo] e [/EXACT rotulo], e [MAX k, rotulo] e [/MAX rotulo]. A Figura 4.2 mostra um exemplo da transformao de um trecho de cdigo assembly gerado por um compilador convencional para a arquitetura MIPS em cdigo assembly instrumentado. Note que uma restrio de atraso mximo de 11 ciclos foi imposta ao segmento de cdigo.

40

Figura 4.2: Transformao do assembly original em instrumentado

Fase 2: Anlise do uxo de dados Entrada: cdigo assembly instrumentado. Sada: grafo ponderado de precedncia (WPG).

Procedimento: Nesta fase, o parser do cdigo assembly gera um grafo de uxo de controle e os grafos ponderados de precedncia que representam os blocos bsicos. O WPG gerado aqui contm um vrtice para cada instruo do BB e arestas codicando tanto as restries de precedncia como as restries temporais, de acordo com as denies apresentadas nas Sees 3.2 e 3.3. Para cada instruo cujo valor de destino o valor fonte de outra instruo, o parser do cdigo insere uma aresta no WPG. O peso desta aresta determinado pela latncia da instruo consumidora em relao instruo produtora (conforme a Denio 3.1) mais um, valor que lido do modelo do processador. O parser do cdigo trata tambm as restries temporais inseridas na fase anterior, inserindo arestas ponderadas para cada pseudo instruo [MIN k, rotulo], [MAX k, rotulo] e [EXACT k, rotulo] de acordo com as Denies 3.6, 3.7 e 3.8. A Figura 4.3 mostra o WPG correspondente ao cdigo mostrado na Figura 4.2. Note que a restrio temporal de atraso mximo foi convertida na aresta (sink, source) conforme a Denio 3.7. Note que as arestas codicam as restries de precedncia devido s dependncias de dados entre as instrues, enquanto que os seus pesos indicam quantos ciclos depois da instruo produtora comear sua execuo a instruo consumidora pode iniciar a sua.

41

Figura 4.3: WPG gerado a partir do assembly instrumentado

Note tambm que o cdigo da Figura 4.2 contm uma falsa dependncia entre a instruo na linha 2 e a instruo na linha 5: elas escrevem no mesmo registrador e se o cdigo for mantido assim a instruo 5 no poderia ser executada, por exemplo, antes da instruo 2 ou antes da 3, j que a instruo 3 consome o valor produzido pela 2 (neste caso, seria vantajoso executar a instruo 5 antes da instruo 3 para preencher a latncia que existe entre as instrues 2 e 3). Mas, analisando-se o uxo de dados, percebe-se que estas instrues na verdade so independentes, por isso o WPG gerado de forma a eliminar tais dependncias de nome entre as instrues e assim expor o paralelismo entre elas. Fase 3: Escalonamento e anlise de factibilidade Entrada: WPG. Sada: WPG escalonado (SWPG).

Procedimento: Cada vrtice do WPG cujos predecessores j foram escalonados marcado como tal. Cada vez que um vrtice vi escalonado, insere-se um par de arestas (v0 , vi ) com w0i = k e (vi , v0 ) com wi0 = -k para designar que vi foi escalonado no k-simo

42 ciclo em relao ao vrtice-fonte. Aps a insero de cada par de arestas, invoca-se o analisador de restries temporais, cujo algoritmo foi discutido na Seo 3.3.3. Como o algoritmo de escalonamento ser apresentado somente na Seo 4.4, seu efeito ilustrado atravs de um exemplo que usa o WPG da Figura 4.3 como ponto de partida. Primeiramente, o escalonador utiliza o algoritmo de Bellman-Ford para estimar a distncia mxima entre o vrtice source e cada um dos outros vrtices do grafo. Isto equivale a uma estimativa inicial de distncia mxima (i ) entre o vrtice v0 e um vrtice arbitrrio vi . As estimativas iniciais resultantes so:

1 = 0 2 = 0 3 = 2 4 = 3 5 = 0 6 = 2 7 = 3 Aps esta inicializao, o escalonador verica que, no incio da execuo (o ciclo zero), h trs instrues que podem iniciar a sua execuo (as instrues representadas pelos vrtices v1 , v2 e v5 ), e escolhe uma delas para ser escalonada no ciclo atual. Esta escolha feita por uma funo de priorizao 2 . Por simplicidade mas sem perda de generalidade, adota-se a ordem original das instrues no cdigo assembly como funo de prioridade. Portanto, a primeira instruo a ser escalonada a representada pelo vrtice v1 . O escalonamento de v1 registrado no WPG atravs das arestas (v0 , v1 ) com w01 = 0 e (v1 , v0 ) com w10 = 0, conforme ilustra a Figura 4.4. As duas arestas inseridas foram a instruo do vrtice v1 a iniciar sua execuo no ciclo zero. Aps serem inseridas estas arestas, novamente executado o Algoritmo 1 para vericar se o escalonamento atual ainda factvel. Os pesos das arestas adjacentes a source
2

Uma funo genrica de priorizao foi concebida de forma a ser congurada para implementar dife-

rentes heursticas de priorizao.

43

Figura 4.4: Escalonamento da primeira instruo

e que apontam para vrtices no escalonados so incrementados em um, para que o Algoritmo 1 possa calcular corretamente as novas estimativas de distncias mximas. O vetor de pesos atualizado car da seguinte forma: 1 = 0 (peso xo, vrtice v1 j escalonado) 2 = 1 3 = 3 4 = 4 5 = 1 6 = 3 7 = 4 Assim, no ciclo 1, dois vrtices esto disponveis para escalonamento, v2 e v5 . Pela funo de prioridade adotada, o vrtice v2 ser escalonado no ciclo 1 atravs da insero das arestas (v0 , v2 ) com w02 = 1 e (v2 , v0 ) com w20 = -1, conforme mostra a Figura 4.5. Novamente o algoritmo de Bellman-Ford ser invocado para analisar a factibilidade do escalonamento sendo gerado e o vetor de pesos ser atualizado da seguinte maneira:

44

Figura 4.5: Escalonamento da segunda instruo

1 = 0 (peso xo, vrtice v1 j escalonado) 2 = 1 (peso xo, vrtice v2 j escalonado) 3 = 3 4 = 4 5 = 2 6 = 4 7 = 5 Observe que os pesos dos caminhos que passam pelos vrtices v3 e v4 no so incrementados em um. Isto ocorre pois os caminhos mais longos do vrtice source at eles passam somente pelos vrtices v1 e v2 , que j foram escalonados (ou seja, os valores de 1 e 2 no sero mais alterados). No ciclo 2 apenas o vrtice v5 estar disponvel para ser escalonado. Os passos descritos anteriormente sero repetidos a cada ciclo at que todas as instrues tenham sido escalonadas (ou at que fosse detectada a infactibilidade do escalonamento). O novo WPG, com as arestas que induzem a ordem das instrues, o WPG escalonado (SWPG).

45 O SWPG nal pode ser visto na Figura 4.6. Para facilitar a visualizao, o grafo da Figura 4.6 contm apenas as arestas que codicam as restries temporais e as decises do escalonador (as arestas representando precedncia foram removidas).

Figura 4.6: WPG escalonado (SWPG)

Note que os atrasos exatos impostos a cada um dos vrtices induzem a ordem linear (v0 , v1 , v5 , v3 , v4 , v6 , v7 ). Fase 4: Gerao de cdigo e alocao de registradores Entrada: SWPG. Sada: Cdigo assembly otimizado.

Procedimento: O gerador de cdigo percorre o SWPG na ordem induzida pelas arestas inseridas durante o escalonamento e, utilizando as informaes sintticas extradas pelo parser do modelo ArchC, gera o novo cdigo assembly. O cdigo gerado no contm as pseudo-instrues do assembly instrumentado e isento de dependncias de nome. Nesta fase faz-se tambm a alocao de registradores [AHO 95]. Este processo consiste em realizar o clculo do tempo de vida de cada valor e construir um grafo de conito. Obtido este grafo, executa-se um algoritmo de colorao de vrtices (denominado de algoritmo da borda esquerda) para determinar o nmero mnimo de cores (registradores)

46 necessrias. Em seguida, a cada cor distinta associado um registrador real, e se o nmero de cores exceder o nmero de registradores disponveis sero geradas instrues que armazenam na memria os valores no mapeados em registradores reais. A Seo 4.5 descrever o algoritmo de alocao de registradores. A Figura 4.7 mostra o cdigo assembly gerado a partir da ordem linear induzida no SWPG da Figura 4.6.

Figura 4.7: Cdigo otimizado

Observe que a latncia de 1 ciclo que existe entre a segunda instruo lw e a instruo sub foi preenchida pela terceira instruo lw, o que tambm eliminou a latncia de 1 ciclo entre esta instruo e a instruo addi, neste caso diminuindo em dois ciclos o tempo de execuo deste trecho. Note que, nesse exemplo, a restrio temporal de atraso mximo de 11 ciclos foi imposta dentro dos limites do bloco bsico. Entretanto, a modelagem de anlise de restries temporais proposta no se restringe apenas a blocos bsicos individuais. A ferramenta d suporte insero de restries que englobam mltiplos BBs, para os casos em que o trecho de cdigo a ser escalonado inclui desvios. Neste caso, as restries devero ser decompostas entre os BBs de acordo com os possveis uxos de execuo descritos pelo CFG. Como descrito anteriormente, cada vrtice do CFG ser visitado pelo escalonador, que far o escalonamento e anlise de factibilidade do BB que o vrtice representa. Como o escalonador visita os vrtices na ordem imposta pelas arestas do CFG (seguindo assim os possveis uxos de execuo do cdigo), a idia fazer a decomposio da restrio temporal ao longo deste processo, impondo a restrio ao primeiro bloco e propagando-a

47 aos blocos sucessores conforme seja calculado o nmero de ciclos necessrios ao escalonamento de cada BB. Para ilustrar o funcionamento desta tcnica, suponha que uma restrio temporal fosse imposta ao cdigo assembly apresentado na Figura 3.9 (Seo 3.2.1), transformandoo em assembly instrumentado, conforme mostra a Figura 4.8.

Figura 4.8: Impondo restrio temporal ao cdigo da Figura 3.9

Suponhamos que os vrtices do CFG sejam visitados seguindo a ordem b1 -> b2 -> b3 -> b4 . Como o primeiro bloco a ser visitado ser b1 e a restrio restr_1 engloba todos os BBs, antes de escalonar este bloco codicaremos nele a restrio do tipo MAX com o seu valor inteiro, ou seja, 19 ciclos, conforme mostra a Figura 4.9. Aps o bloco b1 ter sido escalonado, conclui-se que para ele so necessrios 2 ciclos. Portanto, a restrio restr_1 dever ser propagada a todos os sucessores do BB atual (no caso, apenas o bloco b2 ) com o seu valor original menos o nmero de ciclos necessrios para o escalonamento do BB atual. Neste caso, uma restrio do tipo MAX de 17 ciclos ser imposta ao bloco b2 , conforme ilustrado na Figura 4.10. De forma similar, o bloco b2 escalonado e a restrio deve ser novamente propagada aos seus sucessores. Digamos que o nmero de ciclos calculado pelo escalonador para b2 foi 7, portanto a restrio imposta ao prximo BB a ser visitado (pela ordem, b3 )

48

Figura 4.9: Impondo restrio restr_1 ao bloco b1

Figura 4.10: Propagando a restrio restr_1 de b1 para b2

ser de 10 ciclos. Finalmente, a restrio deve ser propagada de b3 para b4 de acordo com o nmero de ciclos calculado para b3 . Note que, inicialmente, a restrio temporal no muito rgida, mas vai cando cada vez mais apertada conforme seguimos o uxo de execuo do cdigo e os BBs que compes este uxo vo sendo escalonados. Desta forma, assim como no escalonamento dentro do BB, a infactibilidade pode vir a ser detectada mais cedo, caso a restrio seja bastante severa j de incio. Observe ainda que o CFG da Figura 4.8 contm dois uxos possveis de execuo:

49 b1 -> b2 -> b3 -> b4 e b1 -> b2 -> b4 . Desta forma possvel que, para uma certa restrio temporal imposta a todo o cdigo, o escalonamento fosse factvel quando apenas o uxo mais curto levado em considerao, mas no fosse factvel levando-se em considerao o uxo mais longo. Utilizando-se a tcnica apresentada acima, a anlise de restries temporais levar em conta sempre o uxo de execuo mais longo (ou seja, o pior caso) para fazer a vericao de factibilidade.

4.4

Algoritmo de escalonamento de cdigo

O Algoritmo 2 descreve o escalonamento de um WPG. Este algoritmo integra as

funcionalidades do escalonador e analisador de restries, atravs da invocao do Algoritmo 1 (linhas 1 e 22). O algoritmo consiste de um procedimento principal (Schedule) e procedimentos auxiliares (Infeasible, ScheduleStep e FindAvailableInstructions) por ele invocados , os quais sero descritos a seguir. A anlise de factibilidade do escalonamento feita pelo procedimento Infeasible, o qual invoca o algoritmo de Bellman-Ford para analisar se as restries temporais atualmente codicadas no WPG so consistentes. Caso o algoritmo retorne FALSE, o procedimento Infeasible retornar TRUE. O procedimento ScheduleStep invoca o procedimento SelectInstruction (linhas 2 e 11) para selecionar a instruo com a maior prioridade dentre as disponveis para escalonamento no ciclo t. Apesar de a ferramenta aqui descrita conter um mecanismo de escolha de qual instruo ser escalonada similar ao list scheduling [MIC 94], a funo que dene a prioridade genrica e pode ser alterada para capturar diferentes heursticas. Quando uma instruo vi escolhida, ela associada ao ciclo t, ou seja, so inseridas duas arestas ponderadas no WPG: a aresta (v0 , vi ) com peso t, e a aresta (vi , v0 ) com peso -t (linhas 4 a 7). Isto signica que esta instruo deve iniciar a sua execuo exatamente t ciclos aps a referncia inicial de tempo (representada pelo vrtice v0 , "source"), de acordo com a Denio 3.8 da Seo 3.3. A cada deciso tomada pelo escalonador, o procedimento Infeasible (linha 8) chamado para analisar se as restries temporais

50 Algoritmo 2 Escalonamento de cdigo

Procedure: Infeasible(WPG(V, E, W)) 1: return ( BellmanFord(WPG(V, E, W))); // Invoca o Algoritmo 1 Procedure: ScheduleStep(t, A) 2: vi = SelectInstruction(A); 3: while vi = none do 4: E = E (v0 , vi ); 5: w0i = +t; 6: E = E (vi , v0 ); 7: wi0 = -t; 8: if Infeasible(WPG(V, E, W)) == TRUE then 9: return (FALSE); 10: end if 11: vi = SelectInstruction(A); 12: end while 13: return TRUE; Procedure: FindAvailableInstructions(t) 14: A = ; 15: for k = 1 to n do 16: if (v0 , vk ) == t then 17: A = A vk ; 18: end if 19: end for 20: return (A); Procedure: Schedule( ) 21: t = 0; 22: W = BellmanFord(WPG(V, E, W)); // Inicializa o vetor de pesos invocando o Algoritmo 1 23: A = FindAvailableInstructions (t); 24: while A = do 25: if ScheduleStep(t, A) == FALSE then 26: return(); 27: end if 28: t = t + 1; 29: A = FindAvailableInstructions (t); 30: end while 31: return (t);

atualmente codicadas no WPG so consistentes. J o procedimento FindAvailableInstructions constri o conjunto de instrues que esto disponveis para serem escalonadas em um dado ciclo t, ou seja, aquelas cuja distncia mxima ao vrtice source igual a t (signicando que todos os seus operandos esto prontos para serem consumidos neste ciclo). No procedimento principal Schedule (linhas 21 a 31), inicialmente, as estimativas de distncia mxima do vrtice source para todos os outros vrtices do grafo so calculadas utilizando-se o algoritmo de Bellman-Ford (linha 22). Em seguida, dado um ciclo de relgio t, o procedimento FindAvailableInstructions (linha 23) invocado e retorna o conjunto de instrues que esto disponveis para serem escalonadas

51 neste ciclo. Construdo o conjunto de instrues inicialmente disponveis, invoca-se o procedimento ScheduleStep (linha 25) durante sucessivas iteraes at que todas as instrues tenham sido escalonadas de acordo com a Denio 3.9 da Seo 3.3, ou at que seja detectada a infactibilidade do escalonamento.

4.5

Algoritmo de alocao de registradores

O mecanismo de alocao de registradores subjacente ao otimizador foi objeto de

trabalho de pesquisa correlato em cuja monograa [SAN 07] pode ser encontrado o algoritmo de alocao de registradores utilizado.

4.6

Validao experimental
A seguir ser apresentada a metodologia utilizada para a validao da ferramenta

descrita neste captulo. Sero apresentados resultados para dois conjuntos diferentes de benchmarks e, em seguida, sero explicados os critrios usados para vericar se os resultados gerados pela ferramenta esto corretos. Para demonstrar a redirecionabilidade da ferramenta, foram adotadas trs CPUsalvo: MIPS R2000, PowerPC 405 e SPARCV8. O compilador adotado foi o gcc [GCC 03]. Todos os experimentos foram feitos em um computador com processador Pentium 4 rodando a 3 GHz, com 1 GB de memria principal.

4.6.1

Experimentos sem cdigo condicional

O primeiro conjunto de experimentos foi realizado utilizando-se trechos de cdigo que no contm desvios. Estes trechos foram extrados do conjunto de benchmarks Mibench [MIB 06]. Buscaram-se blocos bsicos pertencentes a partes crticas dos programas, como corpos de laos repetidos muitas vezes.

52 4.6.1.1 Congurao experimental

A Tabela 4.1 mostra a caracterizao dos benchmarks para cada CPU-alvo. A primeira coluna mostra o nome dos segmentos de cdigo, enquanto que a segunda indica os programas de onde eles foram extrados. Para cada CPU-alvo h um par de colunas mostrando o tamanho do WPG resultante em termos de nmero de vrtices (|V|) e de arestas (|E|).

Tabela 4.1: Caracterizao dos benchmarks sem cdigo condicional

4.6.1.2

Resultados

Para demonstrar como o escalonador lida com restries temporais efetivamente, cada segmento de cdigo foi submetido a diferentes restries, desde a mais rgida at a mais relaxada, e foi calculada a porcentagem total de solues factveis para todo o conjunto de segmentos usado nos experimentos. Para gerar tais restries, primeiramente adotou-se uma restrio temporal base para cada segmento de cdigo, a qual foi progressivamente relaxada. Esta base, chamada , assume que a cada ciclo uma nova instruo inicia a sua execuo, ignorando assim possveis conitos que possam causar paradas no pipeline. Note que esta uma estimativa otimista e que provavelmente acarretar em um escalonamento infactvel, assegurando que o experimento inicie com restries rgidas.

53 A Figura 4.11 mostra a porcentagem de solues factveis sob restries de atraso mximo de 1,1 , 1,2 e 1,3 .

Figura 4.11: Porcentagem de solues factveis

Observe que, com uma variao de 30% em relao base , todos os segmentos de cdigo satisfazem as restries temporais. No entanto, com uma variao de 10%, metade dos segmentos satisfazem as restries para o MIPS, um tero para o PowerPC e aproximadamente metade para o SPARC. Isto demonstra a diculdade em se satisfazerem restries temporais sem se utilizar um escalonador que delas esteja ciente. Os uxos de compiladores desenvolvidos para gerarem cdigo para sistemas embarcados geralmente toleram tempos maiores de otimizao do que uxos de compiladores convencionais. No entanto, como a ferramenta aqui apresentada executa um algoritmo de clculo de caminho mais longo para cada instruo escalonada, o overhead introduzido devido anlise de restries temporais deve ser vericado. As Figuras 4.12, 4.13 e 4.14 mostram o tempo de execuo do escalonador (expresso em segundos na escala da direita) correlacionado ao tamanho do WPG (expresso em nmero de vrtices e arestas na escala da esquerda). Observe que para todas as CPUs-alvo, em mdia, o crescimento do nmero de vrtices parece estabelecer um limite superior para o crescimento do tempo de execuo. Isto indica que a tcnica de anlise de restries temporais aqui descrita tem baixo overhead.

54

Figura 4.12: Correlao do tamanho do WPG e tempo de execuo (MIPS)

Figura 4.13: Correlao do tamanho do WPG e tempo de execuo (PowerPC)

Ao contrrio dos compiladores convencionais, a tcnica descrita neste trabalho explora as restries temporais para ns de otimizao. Otimizaes que um compilador convencional possivelmente deixa passar so induzidas para garantir que as restries temporais sejam satisfeitas em trechos crticos de cdigo. Para vericar como as restries temporais so exploradas, comparou-se o tamanho do escalonamento de um segmento de cdigo (sem restries temporais) com o tamanho do escalonamento do segmento otimizado equivalente obtido sob restries temporais

55

Figura 4.14: Correlao do tamanho do WPG e tempo de execuo (SPARC)

rgidas. Nos experimentos, um atraso mximo de 1,3 foi imposto a cada trecho de cdigo. A Figura 4.15 plota a razo entre os comprimentos dos escalonamentos dos cdigos originais e otimizados para cada CPU-alvo, ou seja, a acelerao obtida na execuo no cdigo. Os benchmarks so mostrados em ordem crescente de tamanho da esquerda para a direita.

Figura 4.15: Acelerao da execuo do cdigo aps a otimizao

A acelerao mdia foi de 1,18 para os cinco menores segmentos de cdigo e 1,23 para os cinco maiores. O aumento foi um pouco maior para os benchmarks com BBs

56 maiores, pois estes provm maiores oportunidades de otimizao. Note que o assembly original gerado por um compilador convencional, o qual introduz algumas otimizaes. Assim, a acelerao foi medida em relao a trechos de cdigo pr-otimizado. Portanto, os resultados experimentais indicam que o compilador realmente deixou passar algumas oportunidades de otimizao, o que pode ser explicado pelo fato de as restries temporais no serem capturadas em suas heursticas de escalonamento. A ferramenta descrita aqui converte as restries temporais em restries de precedncia, as quais invalidam algumas instrues como candidatas j que a seleo destas levaria a um escalonamento infactvel. Ou seja, a ferramenta sobrescreve as heursticas originais do compilador para favorecer a satisfao das restries temporais. Como aceleraes signicativas em relao a cdigo j pr-otimizado foram alcanadas com baixo overhead, h evidncias sucientes de que vantajosa a otimizao e anlise de restries temporais feitas aps a compilao.

4.6.2

Experimentos com cdigo condicional

Nesta segunda etapa de experimentao, os trechos de cdigo utilizados contm desvios. Novamente os trechos foram extrados do conjunto de benchmarks Mibench e, assim como nos experimentos sem cdigo condicional, buscaram-se trechos executados com freqncia.

4.6.2.1

Congurao experimental

A Tabela 4.2 mostra a caracterizao dos benchmarks para cada CPU-alvo. Similarmente Tabela 4.1, as colunas indicam os nomes dos benchmarks, os programas de onde foram extrados, o nmero de vrtices e o nmero de arestas do WPG resultante. Uma nova coluna foi adicionada para indicar o nmero de blocos bsicos (|BB|) de cada benchmark para cada CPU-alvo.

57

Tabela 4.2: Caracterizao dos benchmarks com cdigo condicional

4.6.2.2

Resultados

Como nesta etapa dos experimentos os benchmarks contm cdigo condicional, nem sempre todas as instrues de um segmento de cdigo so executadas em todas as vezes em que ele executado. Conforme exposto na Seo 4.3, a tcnica de anlise de restries temporais aqui descrita leva em considerao sempre o uxo mais longo de execuo. Desta forma, a aplicao de restries temporais aos benchmarks com cdigo condicional deve ser feita de forma diferente. Nos benchmarks sem cdigo condicional, a estimativa base levava em conta o nmero total de instrues, mas neste caso a estimativa inicial deve levar em conta o nmero de instrues no uxo mais longo de execuo. A Figura 4.16 mostra a porcentagem de solues factveis sob restries de atraso mximo de 1,1 , 1,2 e 1,3 . Observe que, com uma variao de 30% em relao base , todos os segmentos de cdigo satisfazem as restries temporais. No entanto, com uma variao de 10%, cerca de um tero satisfazem as restries para o MIPS, aproximadamente dois teros para o PowerPC e metade para o SPARC. O uso de benchmarks com cdigo condicional requer tambm que a vericao do overhead introduzido devido anlise de restries temporais seja feita de forma diferente. Como o maior overhead est relacionado execuo do algoritmo de Bellman-Ford sucessivas vezes durante o escalonamento de cada bloco bsico, a comparao do tempo

58

Figura 4.16: Porcentagem de solues factveis

de execuo do escalonador deve ser feita em relao ao tamanho mdio dos blocos bsicos do benchmark. As Figuras 4.17, 4.18 e 4.19 mostram o tempo de execuo do escalonador (expresso em segundos na escala da direita) correlacionado ao tamanho mdio dos WPGs que representam os blocos bsicos (expresso pelos nmeros de vrtices e de arestas divididos pelo nmero de BBs, na escala da esquerda).

Figura 4.17: Correlao do tamanho mdio do WPG e tempo de execuo (MIPS)

Novamente os resultados indicam que o overhead aceitvel, j que o crescimento do tamanho mdio dos blocos bsicos parece estabelecer um limite superior para o cres-

59

Figura 4.18: Correlao do tamanho mdio do WPG e tempo de execuo (PowerPC)

Figura 4.19: Correlao do tamanho mdio do WPG e tempo de execuo (SPARC)

cimento do tempo de execuo. A Figura 4.20 plota a razo entre os comprimentos dos escalonamentos dos uxos mais longos de execuo dos cdigos originais e otimizados para cada CPU-alvo, ou seja, a acelerao obtida entre dois cenrios de pior caso de execuo. Os benchmarks so mostrados em ordem crescente de tamanho mdio dos blocos bsicos da esquerda para a direita. A acelerao mdia foi de 1,13 para os quatro menores segmentos de cdigo e 1,25 para os quatro maiores. Assim como nos experimentos sem cdigo condicional, o

60

Figura 4.20: Acelerao da execuo do cdigo aps a otimizao

aumento foi um pouco maior para os benchmarks com BBs maiores devido ao fato de proverem maiores oportunidades de otimizao, e aceleraes acima de 1,3 foram obtidas em relao a cdigo j pr-otimizado.

4.6.3

Critrios de validao

O foco principal dos experimentos relatados nas Sees 4.6.1 e 4.6.2 foi avaliar o impacto das otimizaes no cdigo assembly juntamente com o overhead necessrio execuo da ferramenta. No entanto, para completar-se a validao do prottipo da ferramenta necessrio ainda vericar se a semntica do cdigo original mantida, ou seja, se o cdigo otimizado gerado pela ferramenta equivalente ao cdigo original gerado pelo compilador. Uma forma de se fazer tal vericao executar os dois trechos de cdigo e comparar os resultados. Como a ferramenta baseada em uma descrio do processador feita atravs do ArchC, esta mesma descrio pode ser usada para gerar um simulador onde esta validao pode ser feita. A partir de cada descrio em ArchC foi gerado o simulador correspondente ao processador-alvo desejado, utilizando-se a opo para que sejam impressos na tela o contedo da memria e dos registradores. Os resultados gerados na execuo do cdigo original (gerado pelo compilador) foram iguais queles gerados na execuo do cdigo

61 otimizado, vericando-se assim que a semntica do cdigo foi mantida.

Captulo 5 O Papel da Otimizao Redirecionvel na Traduo Binria

Este captulo prope uma tcnica para traduo binria, a qual baseada na gerao automtica de ferramentas a partir de modelos de CPUs descritos atravs de uma ADL. A motivao, a proposta e o estudo experimental de viabilidade dessa tcnica foram realizados cooperativamente pelo autor e dois outros mestrandos cujas dissertaes abordam tpicos tambm relevantes para a traduo binria [CAS 07] [dOS 07]. Por essa razo, o texto das Sees 5.1, 5.2 e 5.4 deliberadamente comum s trs dissertaes de mestrado. Entretanto, como a implementao do prottipo contou com contribuies distintas e complementares, a Seo 5.3 descreve a contribuio especca do autor para esse trabalho conjunto.

5.1

Motivao
Como discutido no Captulo 1, durante a explorao do espao de projeto de um

SoC pode-se ter que avaliar o impacto de vrias CPUs alternativas at que os requisitos sejam satisfeitos. Isso requer a rpida gerao de cdigo executvel para cada uma das CPUs exploradas, os quais podem ser obtidos de trs maneiras distintas: Alternativa 1 - Disponibilidade de compiladores convencionais portados para cada

63 uma das CPUs candidatas; Alternativa 2 - Disponibilidade de um compilador redirecionvel; Alternativa 3 - Disponibilidade de um compilador convencional para uma das CPUs e de um tradutor binrio capaz de gerar cdigo executvel para as demais CPUs. A Alternativa 1 restringe o espao de solues exploradas ao uso de CPUs tradicionais, cujo uso intensivo justicou o desenvolvimento de compiladores prprios. A Alternativa 2 a mais genrica, mas requer o uso de compiladores redirecionveis, os quais so invariavelmente proprietrios (como o caso do compilador LisaTek [COW 07]) e cujas licenas so caras j que sua oferta no mercado bastante pequena. A Alternativa 3 tem a vantagem de requerer apenas um compilador convencional portado para uma nica arquitetura, cuja licena pode ser pblica (como a do gcc), desde que se disponha de um tradutor binrio para redirecionar o cdigo para as demais arquiteturas a serem exploradas. Em princpio, um tradutor binrio poderia ser obtido atravs do encadeamento de geradores de utilitrios binrios (Seo 5.2). Ora, a ADL ArchC prov geradores de utilitrios binrios sob licena GPL. Assim, o desenvolvimento de um tal tradutor resultaria numa soluo de baixo custo para a explorao de CPUs. de se esperar que o esforo de desenvolvimento de um tradutor binrio esttico - restrito s necessidades de sistemas embarcados - seja inferior ao requerido para se desenvolver um compilador redirecionvel. A principal diculdade a de garantir que a qualidade do cdigo traduzido no seja muito inferior obtida atravs de um compilador. Supondo que o compilador tenha realizado otimizaes independentes de arquitetura antes de gerar o cdigo executvel sob traduo, de se esperar que o cdigo traduzido tenha qualidade similar, desde que o tradutor suporte otimizaes dependentes de arquitetura utilizados em compiladoresotimizadores contemporneos, tais como seleo de instrues, escalonamento de cdigo e alocao de registradores. A partir da reviso de literatura realizada, no de conhecimento do autor que exista algum trabalho de pesquisa similar utilizando gerao automtica de ferramentas

64 a partir de ADL para ns de traduo binria no contexto de explorao do espao de projeto. Este fato, aliado infra-estrutura disponibilizada pelo pacote ArchC, motivou a investigao da viabilidade dessa alternativa, como reportado nas prximas sees.

5.2

Proposta de estrutura de um tradutor binrio

O tradutor binrio proposto neste captulo realiza a traduo estaticamente. Uma

possvel estrutura de um tradutor binrio esttico ilustrada na Figura 5.1.

Figura 5.1: Fluxo de traduo binria

O cdigo executvel a ser traduzido deve inicialmente ser transformado em cdigo assembly atravs de um desmontador. Em seguida, um parser do cdigo assembly utiliza informaes especcas da arquitetura para que seja gerada uma representao intermediria do cdigo. Em geral este tipo de representao intermediria deve ser uma representao em mais alto nvel das instrues do cdigo assembly e deve ser independente

65 da arquitetura alvo. A partir desta representao e de informaes como sintaxe e semntica das instrues da arquitetura para a qual o cdigo foi originalmente gerado, o mapeador deve operar fazendo com que ela seja traduzida em outra similar buscando instrues da arquiteturaalvo que tenham semntica equivalente. gerada ento uma nova representao que corresponde s instrues da arquitetura-alvo que sejam equivalentes s instrues da arquitetura original. A representao resultante pode ser o ponto de entrada para um otimizador que opera antes da gerao do cdigo. A partir desta representao traduzida e otimizada, usando como insumos as informaes especcas da arquitetura-alvo, a ferramenta deve gerar o cdigo assembly equivalente ao original, o qual pode ser ento montado e linkeditado para dar origem ao cdigo executvel traduzido. As ferramentas usadas nos passos intermedirios (desmontador, montador e linkeditor) so geradas automaticamente a partir dos modelos das arquiteturas fonte e alvo descritos atravs de uma ADL.

5.3

A integrao do otimizador no tradutor binrio

Note que a ferramenta otimizadora de cdigo (cuja estrutura geral mostrada na

Figura 4.1 da Seo 4.3) utiliza componentes similares aos do tradutor binrio proposto na Figura 5.1. Desta forma, o processo de implementao do tradutor pode ser facilitado atravs da re-utilizao de tais componentes, como mostrado na Figura 5.2. Neste caso, tanto a representao intermediria gerada pelo parser do cdigo assembly como a gerada pelo tradutor so grafos ponderados de precedncia (WPG1 representa as instrues do cdigo original, WPG2 correspondente s instrues do cdigo traduzido e SWPG ao cdigo traduzido otimizado). O parser do cdigo assembly e o mdulo que gera cdigo a partir do WPG obtm as informaes especcas das arquiteturas para a qual o cdigo foi originalmente compilado e para a qual o cdigo deve ser traduzido utilizando seus respectivos modelos, descritos atravs de ArchC. O analisador de restries de tempo real embutido no otimizador prov uma funcio-

66

Figura 5.2: Integrao do otimizador no tradutor binrio

nalidade incomum nos tradutores binrios. Pode-se, por exemplo, vericar a factibilidade do escalonamento de um mesmo trecho de cdigo, sob as mesmas restries temporais, em diferentes arquiteturas. Podem haver casos em que um segmento de cdigo atende s restries de tempo real quando executado em uma arquitetura, mas resulte em escalonamento infactvel para uma outra arquitetura, sob as mesmas restries temporais.

5.4

Resultados experimentais preliminares

At o momento, o prottipo do tradutor binrio proposto restringe-se traduo

binria de blocos bsicos e foi validado para as CPUs MIPS e SPARC para o conjunto de benchmarks Dalton [DAL 06]. Contudo, o prottipo est sendo estendido para suportar cdigo condicional. As Tabelas 5.1 e 5.2 mostram os resultados preliminares da traduo do MIPS para

67 o SPARC e do SPARC para o MIPS, respectivamente, listando o nmero de instrues na arquitetura original e o nmero de instrues geradas no processo de traduo. Estes nmeros diferem nas duas tabelas em funo de algumas instrues da arquitetura de origem no possurem uma instruo equivalente nica na arquitetura destino, sendo ento necessria a gerao de duas ou mais instrues no processo de traduo.
Tabela 5.1: Resultados da traduo binria MIPS-SPARC
Programa cast b gcd int2bin negcnt xram Nmero de instrues MIPS 38 90 38 23 19 27 Nmero de instrues SPARC 34 105 33 26 20 35

Tabela 5.2: Resultados da traduo binria SPARC-MIPS

Programa cast b gcd int2bin negcnt xram Nmero de instrues SPARC 31 76 36 18 11 36 Nmero de instrues MIPS 28 78 32 19 12 40

A validao mais extensiva da tcnica de traduo envolvendo cdigo condicional, outras CPUs e um nmero maior de programas do benchmark ser objeto de trabalho futuro (veja Captulo 6).

Captulo 6 Concluses e Trabalhos Futuros

6.1 Apreciao do trabalho de pesquisa
Nesta dissertao foi proposta uma ferramenta de otimizao de cdigo ps-compilao, redirecionvel e capaz de realizar uma anlise de restries temporais e fazer a alocao de registradores para a gerao de cdigo otimizado. Para tornar a ferramenta redirecionvel, as informaes dependentes da arquiteturaalvo so extradas de forma automtica de uma descrio formal do processador, feita atravs de uma ADL. Ao mesmo tempo, restries temporais e de precedncia so codicadas em uma representao unicada utilizando-se grafos ponderados, provendo assim a base para a anlise de factibilidade do escalonamento sob restries temporais, utilizando-se algoritmos clssicos de clculo de caminho mais longo, como o de BellmanFord [COR 90]. Alm disso, o escalonador foi integrado a um prottipo de tradutor binrio para a criao de uma ferramenta capaz de traduzir cdigo compilado de uma arquitetura para outra, gerando cdigo otimizado para a arquitetura-alvo. Resultados experimentais foram apresentados para diferentes CPUs (MIPS, PowerPC e SPARC) e mostraram aceleraes de at 1,3 vezes no tempo de execuo de trechos de cdigo j otimizados pelo compilador. Ao mesmo tempo, o overhead mdio da anlise de restries temporais manteve-se abaixo de um limite superior dado pelo crescimento

69 do nmero de instrues. A tcnica descrita nesta dissertao se encaixa nos uxos contemporneos de projeto de sistemas embarcados pelas seguintes razes: Redirecionabilidade prov suporte explorao do espao de projeto: como se baseia em uma descrio formal do processador-alvo atravs de uma ADL, a tcnica redirecionvel permitindo a avaliao de CPUs alternativas. A ADL utilizada foi a linguagem ArchC, o que uma escolha pragmtica visto que esta ADL capaz de gerar modelos executveis em SystemC, a linguagem mais promissora para a criao de modelos no estilo TLM. Captura de restries temporais facilita a extenso de modelos TLM atemporais: a tcnica se adequa prtica de adotar-se como ponto de partida no uxo de projeto uma descrio TLM atemporal (o modelo PV), a qual mais tarde renada acrescentando-se informaes sobre restries temporais (o modelo PVT). Esta abordagem ao mesmo tempo eciente, j que guia as otimizaes de modo a satisfazer as restries temporais, e pragmtica, pois preserva a infraestrutura existente de compiladores convencionais.

6.2

Contribuies tcnico-cientcas
A reviso da literatura apresentada no Captulo 2 mostrou que, em geral, ferramen-

tas baseadas em ADL provm redirecionabilidade, mas no lidam de maneira eciente com restries temporais. Ao mesmo tempo, algumas abordagens tratam corretamente restries temporais, mas no so redirecionveis por focarem em arquiteturas especcas como, por exemplo, os DSPs. Portanto, a reviso da bibliograa no indicou a existncia de trabalho anterior que combine redirecionamento automtico com anlise de restries temporais para ns de escalonamento, explorando as restries para guiar as otimizaes no cdigo. A ferramenta aqui descrita baseia-se em descries formais das CPUs-alvo escritas atravs da linguagem ArchC. Porm, algumas informaes necessrias anlise de uxo

70 de dados e alocao de registradores no eram capturadas pelas construes da ADL ArchC em sua verso original. Por isto, foram propostas extenses para a linguagem de forma que ela viesse a capturar tais informaes: Operandos fonte e destino das instrues. Componentes utilizados no clculo do endereo efetivo de memria a ser lido ou escrito por instrues. Latncias entre instrues. Grupos de registradores considerados de propsitos gerais para ns de alocao de registradores.

6.3

Produtos de trabalho
Os produtos resultantes deste trabalho de pesquisa foram:

Prottipo do escalonador e analisador de restries temporais com alocao de registradores, validado com modelos descritos em ArchC dos processadores MIPS R2000, PowerPC e SPARC V8. Artigo submetido ao IEEE Annual Symposium on VLSI (ISVLSI 2007) [FIL 06]. Artigos submetidos ao IEEE International Midwest Symposium on Ciruits and Systems (MWSCAS 2007) [FIL 07b] [FIL 07a].

6.4

Tpicos para investigao futura

Ao longo desta dissertao foram levantadas algumas limitaes da tcnica pro-

posta, bem como algumas restries simplicadoras deliberadamente assumidas para ns de implementao do prottipo. Assim, vrios tpicos para continuidade deste trabalho consistem em relaxar as restries do Captulo 4, como segue:

71 Relaxamento da Restrio 1: Um tpico para investigao em trabalhos futuros seria a realizao de otimizaes globais no cdigo, utilizando-se tcnicas como code motion e execuo especulativa [dS 98]. Apesar de otimizaes feitas no nvel de blocos bsicos mostrarem resultados satisfatrios, isto permitiria otimizaes mais agressivas, possivelmente resultando em aumentos ainda maiores na acelerao de execuo do cdigo. Relaxamento da Restrio 2: Embora a restrio para mquinas load/store possa ser relaxada, o impacto desta generalizao seria pequeno, pois apenas arquiteturas mais antigas no aderem a esta restrio. Relaxamento da Restrio 3: Outro ponto a ser investigado o suporte a instrues que ocupam estgios do pipeline por mais de um ciclo. Isto permitiria que fossem feitas otimizaes em programas contendo, por exemplo, instrues de ponto utuante, que se encaixam nesta categoria, aumentando assim a aplicabilidade da ferramenta. Relaxamento da Restrio 4: O suporte a arquiteturas com emisso mltipla de instrues, como as superescalares e VLIW, tambm um tpico que merece investigao em futuras implementaes da ferramenta, tendo em vista que muitas CPUs utilizadas atualmente em sistemas embarcados apresentam esta caracterstica. Outro tpico que merece investigao futura refere-se ao subproduto desta dissertao, o tradutor binrio otimizado, apresentado no Captulo 5. Para aumentar a aplicabilidade da tcnica proposta e estender a sua validao, uma verso futura da ferramenta deve suportar a traduo de programas contendo cdigo condicional e ser capaz de traduzir cdigo gerado para outras arquiteturas alm daquelas usadas nos experimentos da Seo 5.4.

72

Referncias Bibliogrcas
[AHO 95] AHO, A. V.; SETHI, R.; ULLMAN, J. D. Compiladores - Princpios, Tcnicas e Ferramentas. Livros Tcnicos e Cientcos Editora S.A., 1995. [BAL 05a] BALDASSIN, A.; CENTODUCATTE, P. Gerao automtica de montadores para modelos de arquiteturas escritos em ArchC. In: PROCEEDINGS OF THE 9TH BRAZILIAN SYMPOSIUM ON PROGRAMMING LANGUAGES, 2005. [s.n.], 2005. p.3649. [BAL 05b] BALDASSIN, A.; CENTODUCATTE, P.; RIGO, S. Extending the ArchC language for automatic generation of assemblers. In: PROCEEDINGS OF THE 17TH INTERNATIONAL SYMPOSIUM ON COMPUTER ARCHITECTURE AND HIGH PERFORMANCE COMPUTING, 2005. [s.n.], 2005. p.6067. [BIN 05] BINUTILS, G. The GNU Binutils Website. Disponvel em <http://www.gnu.org/software/binutils. [CAS 06] CASAROTTO, D. C.; DOS SANTOS, L. C. V. Automatic Link Editor Generation for Embedded CPU Cores. In: NORTHEAST WORKSHOP ON CIRCUITS AND SYSTEMS NEWCAS PROCEEDINGS, 2006. Proceedings... Gatineau, Canada: [s.n.], 2006. [CAS 07] CASAROTTO, D. C. Utilitrios Binrios Redirecionveis: da Linkedio rumo Traduo Binria. Departamento de Informtica e Estatstica - UFSC, Maro, 2007. Dissertao de Mestrado. [CIF 98] CIFUENTES, C.; SENDALL, S. Specifying the semantics of machine instructions. In: IWPC 98: PROCEEDINGS OF THE 6TH INTERNATIONAL WORKSHOP ON PROGRAM COMPREHENSION, 1998. Proceedings... Washington, DC, USA: IEEE Computer Society, 1998. p.126. [CIF 99] CIFUENTES, C. et al. Preliminary Experiences with the Use of the UQBT Binary Translation Framework. Technical Committee on Computer Architecture News, [S.l.], p.1222, 1999. [CIF 00] CIFUENTES, C.; EMMERIK, M. V. UQBT: Adaptable binary translation at low cost. Computer, Los Alamitos, CA, USA, v.33, n.3, p.6066, 2000.

74
[CIF 02] CIFUENTES, C.; LEWIS, B.; UNG, D. Walkabout - a retargetable dynamic binary translation framework. Technical Report TR2002 -106, Sun Microsytems Laboratories. [COR 90] CORMEN, T. H.; LEISERSON, C. E.; RIVEST, R. L. Introduction to Algorithms. McGraw-Hill, 1990. [COW 07] COWARE. LisaTek. Disponvel em <http://www.coware.com>. Acesso em: January. [DAL 06] DALTON. The UCR Dalton Project. Disponvel em <http://www.cs.ucr.edu/ dalton/. [dOS 07] DE OLIVEIRA SCHULTZ, M. R. Gerao Automtica de Ferramentas de Inspeo de Cdigo para Processadores Especicados em ADL. Departamento de Informtica e Estatstica - UFSC, Maro, 2007. Dissertao de Mestrado. [dS 98] DOS SANTOS, L. C. V. Exploiting instruction-level parallelism: a constructive approach. Electrical Engineering department, Eindhoven University of Technology, 1998. Tese de Doutorado. [FIL 06] FILHO, J. O. C.; SANTOS, L. F. P.; DOS SANTOS, L. C. V. An Automatically-Retargetable Time-Constraint Driven Instruction Scheduler for Post-Compiling Optimization of Embedded Code. Submetido ao ISVLSI 2007: IEEE Annual Symposium on VLSI. [FIL 07a] FILHO, J. O. C. et al. Extending the Design Exploration of Embedded Cores with Binary Translation. Submetido ao MWSCAS 2007: IEEE International Midwest Symposium on Circuits and Systems. [FIL 07b] FILHO, J. O. C.; SANTOS, L. F. P.; DOS SANTOS, L. C. V. An Automatically-Retargetable Time-Constraint Driven Instruction Scheduler for Post-Compiling Optimization of Embedded Code. Submetido ao MWSCAS 2007: IEEE International Midwest Symposium on Circuits and Systems. [GCC 03] GCC. The GNU Compiler Collection Website. Disponvel em <http://gcc.gnu.org. [GHE 05] GHENASSIA, F. Transaction-level Modeling with SystemC - TLM Concepts and Applications for Embedded Systems. Springer, 2005. [HAD 97] HADJIYIANNIS, G.; HANONO, S.; DEVADAS, S. ISDL: An instruction set description language for retargetability. In: PROCEEDINGS OF THE 34TH ANNUAL CONFERENCE ON DESIGN AUTOMATION, 1997. ACM Press, 1997. p.299302. [HAL 99] HALAMBI, A. et al. EXPRESSION: A language for architecture exploration through compiler/simulator retargetability. In: DESIGN, AUTOMATION AND TEST IN EUROPE, 1999. [s.n.], 1999. p.485490.

75
[HAL 01] HALAMBI, A. et al. A customizable compiler framework for embedded systems. In: INTERNATIONAL WORKSHOP ON SOFTWARE AND COMPILERS FOR EMBEDDED PROCESSORS, 2001. [s.n.], 2001. [HAN 98] HANONO, S.; DEVADAS, S. Instruction selection, resource allocation, and scheduling in the AVIV retargetable code generator. In: PROCEEDINGS OF THE 35TH ANNUAL CONFERENCE ON DESIGN AUTOMATION, 1998. ACM Press, 1998. p.510515. [HOH 04] HOHENAUER, M. et al. A methodology and tool suite for c compiler generation from adl processor models. In: DATE 04: PROCEEDINGS OF THE CONFERENCE ON DESIGN, AUTOMATION AND TEST IN EUROPE, 2004. Proceedings... Washington, DC, USA: IEEE Computer Society, 2004. p.21276. [KS 00] KSTNER, D. PROPAN: A retargetable system for postpass optimizations and analyses. In: LCTES 00: PROCEEDINGS OF THE ACM SIGPLAN WORKSHOP ON LANGUAGES, COMPILERS, AND TOOLS FOR EMBEDDED SYSTEMS, 2000. Proceedings... London, UK: Springer-Verlag, 2000. p.6380. [KS 03] KSTNER, D. TDL: A hardware description language for retargetable postpass optimizations and analyses. In: GPCE 03: PROCEEDINGS OF THE 2ND INTERNATIONAL CONFERENCE ON GENERATIVE PROGRAMMING AND COMPONENT ENGINEERING, 2003. Proceedings... New York, NY, USA: Springer-Verlag New York, Inc., 2003. p.1836. [LEU 01] LEUPERS, R.; MARWEDEL, P. Retargetable Compiler Technology for Embedded Systems: Tools and Applications. Norwell, MA, USA: Kluwer Academic Publishers, 2001. [MAR 03] MARWEDEL, P. Embedded System Design. Kluwer Academic Publishers, 2003. [MES 97] MESMAN, B. et al. Constraint analysis for DSP code generation. In: INTERNATIONAL SYMPOSIUM ON SYSTEM SYNTHESIS, 1997. [s.n.], 1997. p.3340. [MIB 06] MIBENCH. MiBench Benchmark Suite. Disponvel em <http://www.eecs.umich.edu/mibench/. [MIC 94] MICHELI, G. D. Synthesis and Optimization of Digital Circuits. McGraw-Hill Higher Education, 1994. [PAT 04] PATTERSON, D.; HENNESSY, J. Computer Organization and Design: The Hardware/Software Interface. 3. ed. Morgan Kaufmann, 2004. [PAT 06] PATTERSON, D.; HENNESSY, J. Computer Organization and Design: The Hardware/Software Interface. 3. ed. Morgan Kaufmann, 2006.

76
[PEE 99] PEES, S. et al. LISA machine description language for cycle-accurate models of programmable DSP architectures. In: DESIGN AUTOMATION CONFERENCE, 1999. [s.n.], 1999. p.933938. [RAM 97] RAMSEY, N.; FERN&#225;NDEZ, M. F. Specifying representations of machine instructions. ACM Transactions on Programming Languages and Systems, New York, NY, USA, v.19, n.3, p.492524, 1997. [RIG 04] RIGO, S. ArchC: Uma linguagem de descrio de arquiteturas. Instituto de Computao, UNICAMP, Campinas, Julho, 2004. Tese de Doutorado. [SAL 06] SALTO. The Salto Project. Disponvel em <http://www.irisa.fr/caps/projects/Salto/. [SAN 07] SANTOS, L. F. P. Alocao de Registradores para um Otimizador de Cdigo Redirecionvel. Monograa de trabalho de concluso de curso. [SPA 97] SPAM Research Group. SPAM Compiler Users Manual, 1.0. ed., 1997. [Sta 94] Stanford Compiler Group. The SUIF Library, 1.0. ed., 1994.

[SYS 06] SYSTEMC. The SystemC Website. Disponvel em <http://www.systemc.org. [TAG 05a] TAGLIETTI, L. et al. Automatic ADL-Based Assembler Generation for ASIP Programming Support. Lecture Notes in Computer Science, [S.l.], v.3553/2005, p.262268, 2005. [TAG 05b] TAGLIETTI, L. et al. Automatically Retargetable Pre-Processor and Assembler Generation For ASIPs. In: THE 3RD INTERNATIONAL IEEE-NEWCAS CONFERENCE PROCEEDINGS, 2005. [s.n.], 2005. p.215218. [VIN 02] VINCENTELLI, A. S. Dening platform-based design. EEDesign of EETimes, [S.l.], February, 2002. [WAH 03] WAHLEN, O. et al. Instruction scheduler generation for retargetable compilation. IEEE Des. Test, Los Alamitos, CA, USA, v.20, n.1, p.3441, 2003.