UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMTICA

PROGRAMA DE PS-GRADUAO EM COMPUTAO

LEOMAR SOARES DA ROSA JUNIOR

IMPLEMENTAO DE MULTITAREFA SOBRE ARQUITETURA JAVA EMBARCADA FEMTOJAVA

Dissertao apresentada como requisito parcial para a obteno do grau de Mestre em Cincia da Computao

Prof. Dr. Andr I. Reis Orientador

Prof. Dr. Alexandre S. Carissimi Co-orientador

Porto Alegre, agosto de 2004.

2

CIP CATALOGAO NA PUBLICAO

Rosa Junior, Leomar Soares da Implementao de Multitarefa sobre Arquitetura Java

Embarcada FemtoJava / Leomar Soares da Rosa Junior. Porto Alegre: PPGC da UFRGS, 2004.

85 fl.: il. Dissertao (mestrado) Universidade Federal do Rio

Grande do Sul. Programa de Ps-Graduao em Computao, Porto Alegre, BR-RS, 2004. Orientador: Andr I. Reis ; Co-Orientador: Alexandre S. Carissimi.

1. Sistemas embarcados. 2. Microcontrolador Java. 3. Multitarefa. 4. Escalonadores de tarefas. I. Reis, Andr I. II. Carissimi, Alexandre S. III. Ttulo.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitora: Profa. Wrana Panizzi Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann Pr-Reitora Adjunta de Ps-Graduao: Profa. Joclia Grazia Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux Coordenador do PPGC: Prof. Carlos Alberto Heuser Bibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

3

AGRADECIMENTOS

Agradeo aos meus pais, Leomar Soares da Rosa e Maria Ceclia Machado da Rosa, pela garantia de uma fonte inesgotvel de carinho e compreenso. Agradeo a eles, tambm, pelos incessantes estmulos e incentivos, e por todas as vibraes em cada conquista por mim alcanada.

minha tia, Gilda Maria da Silva Machado, por me acolher e apoiar. Graas a sua ajuda, tive tranqilidade para estudar e desenvolver esse projeto.

Meu muito obrigado aos meus orientadores, Andr Incio Reis e Alexandre da Silva Carissimi que, com muita sabedoria e amizade, desempenharam papel fundamental na realizao deste trabalho e tantos outros.

Aos meus amigos e colegas pelos momentos de reflexo, descontrao, e por me lembrarem, algumas vezes, que na vida no existem apenas computadores.

E a Deus, por ter me dado a oportunidade de concretizar um sonho!

4

SUMRIO

LISTA DE ABREVIATURAS ...................................................................................................... 7 LISTA DE FIGURAS ................................................................................................................. 9 LISTA DE TABELAS............................................................................................................... 11

RESUMO ................................................................................................................................12

ABSTRACT ............................................................................................................................13 1 INTRODUO ..................................................................................................................... 14 1.1 Objetivos do Trabalho ................................................................................................. 15 1.2 Organizao do Trabalho ............................................................................................ 17 2 SISTEMAS OPERACIONAIS E SISTEMAS EMBARCADOS .................................................... 18 2.1 Classificao de Sistemas Operacionais ..................................................................... 18 2.1 Sistemas Operacionais Embarcados ........................................................................... 20 2.2 Sistemas Operacionais de Tempo Real....................................................................... 21 2.3 Estado da Arte em Sistemas Operacionais Embarcados .......................................... 23 2.3.1 Sistema Operacional eCOS ......................................................................................... 23

2.3.2 Sistema Operacional NetBSD ..................................................................................... 24 2.3.3 Sistema Operacional Windows Embarcado ................................................................ 25 2.3.4 Sistema Operacional uClinux ...................................................................................... 25 2.3.5 Sistema Operacional VxWorks ................................................................................... 26 2.3.6 Sistema Operacional MiniRTL.................................................................................... 27

2.4 Resumo .......................................................................................................................... 27 3 DESCRIO DO AMBIENTE DE DESENVOLVIMENTO ........................................................ 28 3.1 Arquitetura Hardware: O Microcontrolador FemtoJava......................................... 28 3.1.1 Arquitetura do Microcontrolador FemtoJava .............................................................. 29 3.1.2 Sistema de Temporizao............................................................................................ 31

5

3.1.3 Sistema de Interrupo ................................................................................................ 32 3.1.4 Registradores Internos ................................................................................................. 32 3.1.5 As Memrias de Programa e de Dados do FemtoJava ................................................ 33 3.2 Arquitetura Software: O Ambiente SASHIMI .......................................................... 36 3.2.1 Regras de Modelagem do Ambiente SASHIMI.......................................................... 37 3.2.2 Gerao do Microcontrolador...................................................................................... 38

3.3 Resumo .......................................................................................................................... 38 4 SUPORTE MULTITAREFA PARA A ARQUITETURA: M-FEMTOJAVA................................. 39 4.1 Possveis Variaes de Implementao de Troca de Contexto ................................. 39 4.1.1 Primeira Estratgia de Implementao ........................................................................ 40 4.1.2 Segunda Estratgia de Implementao ........................................................................ 41 4.1.3 Terceira Estratgia de Implementao ........................................................................ 42

4.2 Novas Instrues Estendidas ....................................................................................... 43 4.2.1 Instruo SAVE_CTX................................................................................................. 44

4.2.2 Instruo REST_CTX.................................................................................................. 44 4.2.3 Instruo INIT_VAL ................................................................................................... 45 4.2.4 Instruo INIT_STK.................................................................................................... 46 4.2.5 Instruo SCHED_THR .............................................................................................. 46 4.2.6 Instruo GET_PC....................................................................................................... 47 4.2.7 Consideraes Gerais Sobre as Instrues Desenvolvidas.......................................... 47

4.3 Resumo .......................................................................................................................... 49 5 ASPECTOS DE IMPLEMENTAO EM SOFTWARE .............................................................. 50 5.1 Implementao dos Escalonadores ............................................................................. 50 5.1.1 Polticas de Escalonamento ......................................................................................... 50 5.1.2 Regras Gerais Definidas para a Implementao de Multitarefa na Arquitetura.......... 52 5.1.3 Estrutura dos Escalonadores para o M-FemtoJava...................................................... 52 5.1.4 Tabela de Tarefas......................................................................................................... 56 5.1.5 Interrupo por Hardware e Chamada para a Rotina de Escalonamento.................... 57 5.2 As Modificaes na Ferramenta SASHIMI ............................................................... 58 5.2.1 As Novas Regras de Modelagem................................................................................. 60 5.3 Relocador de Endereos............................................................................................... 61

6

5.4 Resumo .......................................................................................................................... 63 6 ANLISE DE RESULTADOS................................................................................................. 64 6.1 Metodologia................................................................................................................... 64 6.2 Custos em rea ............................................................................................................. 65 6.2.1 Acrscimo Devido a Incluso das Instrues Desenvolvidas ..................................... 65 6.2.2 Acrscimo Devido a Incluso dos Cdigos dos Escalonadores .................................. 66

6.3 Consumo de Energia e Aumento do Nmero de Ciclos de Execuo...................... 67 6.3.1 Impacto em Nmero de Ciclos de Execuo............................................................... 70 6.3.2 Impacto em Consumo de Energia................................................................................ 72 6.4 Comparao: Implementao em Baixo X Alto Nvel .............................................. 73 6.5 Consideraes Gerais ................................................................................................... 76 6.6 Resumo .......................................................................................................................... 77 7 CONCLUSES FINAIS E TRABALHOS FUTUROS ................................................................ 79 REFERNCIAS ....................................................................................................................... 82

7

LISTA DE ABREVIATURAS

API Application Programming Interface ASIP Application-Specific Instruction Set Processor A/D Analgico / Digital

CACO-PS Cycle-accurate Configurable Power Simulator CG Capacitncia de Gates

CPU Central Process Unit

D/A Digital / Analgico

EDF Earliest Deadline First

E/S Entrada / Sada

FIFO First In First Out

FPGA Field Programmable Gate Array

IMDCT Inverse Modified Discrete Cosine Transform JVM Java Virtual Machine

MP3 Moving Pictures Expert Group Layer 3

PC Program Counter

PDA Personal Digital Assistant

POSIX Portable Operating System Interface RAM Random-Access Memory

ROM Read-Only Memory

R.R. Round-Robin

SASHIMI Systems As Software and Hardware In Microcontrollers SJF Shortest Job First

SP Stack Pointer

8

S.O. Sistema Operacional

TCP/IP Transmission Control Protocol / Internet Protocol

UFRGS Universidade Federal do Rio Grande do Sul

VHDL Very High Speed Integrated Circuit Hardware Description Language

VLIW Very Long Instruction Word

9

LISTA DE FIGURAS

Figura 1.1: Ncleo Enxuto de um Sistema Operacional ...................................................... 16 Figura 2.1: Classificao de Alguns S.O. de Acordo com a Aplicabilidade........................ 19 Figura 3.1: Fluxo de Projeto do Ambiente SASHIMI.......................................................... 28 Figura 3.2: Arquitetura FemtoJava Multiciclo (ITO, 2000)................................................. 30 Figura 3.3: Memria de Programa (a) e Memria de Dados (b) .......................................... 34 Figura 3.4: Exemplo de Memria de Programa ROM.mif................................................... 35 Figura 4.1: Troca de Contexto entre Duas Tarefas............................................................... 40 Figura 4.2: Primeira Estratgia de Salvamento de Contexto................................................ 41 Figura 4.3: Segunda Estratgia de Salvamento de Contexto................................................ 42 Figura 4.4: Terceira Estratgia de Salvamento de Contexto ................................................ 43 Figura 4.5: Instruo Estendida SAVE_CTX ...................................................................... 44 Figura 4.6: Instruo Estendida REST_CTX ....................................................................... 45 Figura 4.7: Instruo Estendida INIT_VAL......................................................................... 45 Figura 4.8: Instruo Estendida INIT_STK ......................................................................... 46 Figura 4.9: Instruo Estendida SCHED_THR.................................................................... 47 Figura 4.10: Instruo Estendida GET_PC .......................................................................... 47 Figura 5.1: Nova Estrutura da Memria de Programa do FemtoJava .................................. 53 Figura 5.2: Mdulos dos Escalonadores............................................................................... 54 Figura 5.3: Nova Estrutura da Memria de Dados do FemtoJava........................................ 55 Figura 5.4: Tabela de Processos para Escalonadores no M-FemtoJava ............................... 57 Figura 5.5: Habilitao do Sistema Temporizador para Escalonador R.R........................... 58 Figura 5.6: Classe Scheduler.Java .................................................................................... 59 Figura 5.7: Novas Regras de Modelagem no Ambiente SASHIMI ..................................... 60 Figura 5.8: Fluxo de Projeto e Utilizao do Relocador ...................................................... 62

10

Figura 6.1: Tempo Total de Execuo de Tarefas................................................................ 67 Figura 6.2: Tempo Total de Execuo de Tarefas com o Escalonador FIFO ...................... 68 Figura 6.3: Tempo Total de Execuo de Tarefas com o Escalonador Round-Robin ......... 69 Figura 6.4: Acrscimo no Nmero de Ciclos de Execuo.................................................. 72 Figura 6.5: Acrscimo do Consumo de Energia................................................................... 73 Figura 6.6: Impacto das Duas Implementaes em Ciclos de Execuo ............................. 75 Figura 6.7: Consumo Total de Energia das Implementaes em Baixo e Alto Nvel.......... 75

11

LISTA DE TABELAS

Tabela 2.1: Alguns Sistemas Operacionais Embarcados e Suas Aplicaes ....................... 21 Tabela 3.1: Algumas Caractersticas do FemtoJava Multiciclo ........................................... 31 Tabela 3.2: Conjunto de Instrues FemtoJava (SASHIMI, 2002)...................................... 31 Tabela 3.3: Registradores Internos do FemtoJava Multiciclo .............................................. 33

Tabela 4.1: Nmero de instrues de Cada Nova Instruo Estendida ............................. 48 Tabela 4.2: Bytecodes e Significados das Novas Instrues ................................................ 48 Tabela 4.3: Exemplo de Operao de Gravao de Valores em uma Posio de Memria.49 Tabela 6.1: Acrscimo de rea em Hardware para a Implementao das Instrues

Estendidas em um Dispositivo FPGA Altera FLEX10K EPF10K70RC240-2 .66 Tabela 6.2: Custos de rea em Memrias RAM e ROM..................................................... 66 Tabela 6.3: Quanta Utilizados para Escalonadores R.R. ..................................................... 70 Tabela 6.4: Nmero de Ciclos Executados pelos Diferentes Escalonadores ....................... 71 Tabela 6.5: Custo em Termos de Nmero de Ciclos de Execuo....................................... 71 Tabela 6.6: Consumo de Energia pelos Diferentes Escalonadores ...................................... 72 Tabela 6.7: Comparao de um Escalonador R.R. Implementado em Baixo e Alto Nvel.. 74 Tabela 6.8: Tarefas e Ciclos de Execuo............................................................................ 76 Tabela 6.9: Ciclos Executados e Consumo de Energia pelos Diferentes Escalonadores ..... 77 Tabela 6.10: Custo em Termos de Nmero de Ciclos de Execuo .................................... 77

12

RESUMO

Cada vez mais equipamentos eletrnicos digitais tm sido fabricados utilizando um sistema operacional embarcado. Por razes de custo, estes sistemas operacionais so implementados sobre um hardware com os requisitos mnimos para atender as necessidades da aplicao. Este trabalho apresenta um estudo sobre a viabilidade de implementao de suporte a multitarefa sobre a arquitetura FemtoJava, um microcontrolador monotarefa dedicado a sistemas embarcados. Para tanto, o suporte de hardware necessrio adicionado arquitetura. Tambm so implementados dois escalonadores de tarefas diretamente em bytecodes Java, visando otimizao de rea e o compromisso com desempenho e consumo de energia. Modificaes no ambiente de desenvolvimento e uma ferramenta de relocao de endereos so propostas, objetivando a utilizao dos escalonadores de tarefas implementados junto ao fluxo de desenvolvimento existente. Por fim, uma anlise realizada sobre o impacto que a capacidade de multitarefa produz no sistema em termos de desempenho, consumo de rea e energia.

Palavras-chave: Sistemas Embarcados, Microcontrolador Java, Multitarefa, Escalonadores de Tarefas

13

MULTITASK IMPLEMENTATION INTO FEMTOJAVA EMBEDDED ARCHITECTURE

ABSTRACT

Most digital electronic equipments are produced using an embedded operating system. Due to economic reasons, these operating systems are implemented on hardware with minimal requirements to support the application needs. This work will present a viability study to implement multitask support on the FemtoJava architecture, a monotask microcontroller dedicated to embedded applications. The support to multitask involves the addition of specific hardware mechanisms to the architecture. Two different scheduling policies are then directly implemented using Java bytecodes, aiming area optimization as well as a good performance/energy-consumption trade-off. Some modifications in the development environment and a code relocation tool were introduced, in order to enable the use of the schedulers in the existing design tool flow. Finally, an analysis is performed to evaluate the impact that the multitask support produces in the system with respect to the final performance, area and energy consumption.

Keywords: Embedded Systems, Java Microcontroller, Multitask, Task Scheduler

14

1 INTRODUO

A utilizao de sistemas operacionais embarcados de fundamental importncia para o funcionamento de vrios equipamentos da vida moderna. Eles so encontrados nos mais variados dispositivos e sistemas, desde simples brinquedos at equipamentos de ltima gerao da indstria eletroeletrnica (WOLF, 2002). Alguns exemplos de aplicao de sistemas operacionais embarcados so os roteadores e switches de redes, as cmeras fotogrficas digitais, os smart cards, as impressoras e mquinas copiadoras, os decodificadores de MP3, os sistemas de automao, os sistemas automotivos computadorizados, os telefones celulares, e at mesmo os brinquedos inteligentes, como por exemplo, o Rob Aibo da Sony. Em geral, qualquer novo sistema ou produto que possui a caracterstica de funcionar automaticamente apresenta um sistema operacional embarcado controlando e gerenciando o funcionamento e o desempenho dos componentes e dispositivos envolvidos (ORTIZ, 2001). Os sistemas operacionais embarcados esto, portanto, cada vez mais presentes nos diversos setores da indstria atual.

A demanda por equipamentos inteligentes e solues dedicadas, capazes de apresentar resultados eficientes para os problemas cotidianos, transforma a utilizao de microprocessadores e sistemas embarcados em uma fatia muito atraente da computao. Dessa forma, a necessidade por sistemas operacionais embarcados, capazes de orquestrar os novos dispositivos e equipamentos, crescente e irreversvel (LEHRBAUM, 2002).

O mercado de sistemas operacionais embarcados possui a particularidade de ser mais competitivo, se comparado ao mercado de sistemas operacionais para computadores pessoais. Isso ocorre porque no existe uma nica empresa que domine uma larga fatia no mercado, como acontece com os sistemas operacionais para computadores pessoais, onde poucos o dominam. Essa peculiaridade tem atrado a ateno de empresas de desenvolvimento j consagradas no ramo de sistemas operacionais, dentre elas a Microsoft, a WindRiver Systems e a Red Hat, por exemplo (SANTO, 2001). Estima-se que o rendimento com a venda de sistemas operacionais embarcados dobrar em poucos anos, passando de 752 milhes de dlares em 2001 para 1.59 bilhes em 2005 (ORTIZ, 2001).

Analisando sob o aspecto do hardware necessrio para sistemas embarcados, nota-se que processadores e sistemas integrados em silcio dedicados a esse propsito esto em

15

franca expanso (TAKAHASHI, 2001). Nesse mesmo caminho, enquanto a tecnologia permite acrescentar mais e mais transistores dentro de um circuito integrado, pesquisadores direcionam seus esforos para achar a melhor maneira para a utilizao dessa crescente capacidade computacional (BAYNES, 2003). Conforme o Roadmap da Semiconductor Industry Association, a quantidade de transistores que podero ser integrados em uma pastilha de silcio chegar, em um futuro no muito distante, a cerca de um bilho (SIA, 2003). Em computadores pessoais, por exemplo, as novas tecnologias e sua capacidade computacional so aplicadas em vrias tcnicas para o aumento de desempenho, tanto para atender ao usurio comum com aplicaes de escritrio e entretenimento, quanto s grandes companhias, que utilizam esse poder computacional para fazer previso de tempo, simulaes subatmicas ou controle de trfego areo. Todavia, em sistemas embarcados, no correto apenas ter o tempo de computao como principal mtrica e objetivo. Principalmente em sistemas embarcados portteis, tem-se que haver uma preocupao equivalente com o consumo de energia, j que, em geral, esses sistemas so dependentes de uma bateria como fonte de alimentao. Alm disso, aspectos relativos ao custo do produto em termos de rea apresentam enorme impacto na eletrnica de consumo. Dessa forma, para aplicaes embarcadas, a tendncia fazer uso da tecnologia no para alcanar o mximo desempenho possvel, mas sim, o desempenho necessrio para atender somente aos requisitos da aplicao.

Observa-se, tambm, que os sistemas embarcados esto, cada vez mais, agregando um maior nmero de funes, oferecendo aos usurios diversos recursos antes inexistentes (WILLIAMS, 2002). Por exemplo, telefones celulares de ltima gerao renem funes como acesso a Internet, jogos eletrnicos, reproduo de udio e vdeo, conexo de dados via infravermelho, cmera fotogrfica, entre outros (LAWTON, 2002) (NOKIA, 2004). Portanto, necessrio que os desenvolvedores de sistemas embarcados explorem a relao custo/benefcio na utilizao de diferentes arquiteturas dedicadas a sistemas embarcados. Desde a escolha do processador at a prototipao final do sistema os custos envolvidos para a obteno do circuito integrado final podem tornar, muitas vezes, o projeto economicamente invivel.

1.1 Objetivos do Trabalho

Uma alternativa para processamento em aplicaes embarcadas a utilizao de microcontroladores. Esses podem apresentar uma boa relao custo/benefcio, podendo ser empregados em sistemas dedicados como, por exemplo, aplicaes do setor automotivo, dispositivos domsticos e sistemas de entretenimento (ITO, 2001). Partindo desse princpio, torna-se interessante explorar a possibilidade de utilizao de um microcontrolador dedicado a sistemas embarcados, menos robusto em capacidade de processamento se comparado a processadores estado da arte da indstria de semicondutores, mas capaz de ser

16

sintetizado em dispositivos FPGA (Field Programmable Gate Array) com um custo relativamente baixo em relao a outras solues disponveis no mercado.

Analisando o estado da arte sobre avaliao de sistemas operacionais embarcados e arquiteturas embarcadas, constata-se que o consumo de energia e o desempenho nesses sistemas foram investigados em diversos trabalhos (ACQUAVIVA, 2001) (CIGNETTI, 2000) (DICK, 2000) (KREUZINGER, 2002) (TAN, 2002). CIGNETTI, por exemplo, fez uma anlise sobre o consumo de energia do sistema operacional PalmOS. J o trabalho de DICK avaliou o consumo de energia do sistema operacional uCLinux sobre a arquitetura Fujitsu SPARCLite. O consumo de energia do sistema operacional eCos foi caracterizado no trabalho de ACQUAVIVA, dando ateno, mais especificamente, para a relao entre o consumo de energia e a freqncia do processador. Por fim, o trabalho de TAN comparou o consumo de energia dos sistemas operacionais Linux e uCLinux sobre as arquiteturas StrongARM e Fujitsu SPARCLite, respectivamente. J KREUZINGER, apresentou um estudo relacionado ao desempenho e rea requerida para uma arquitetura Java dedicada a sistemas embarcados multithread.

A motivao para a realizao deste trabalho surgiu a partir da possibilidade de se investigar a viabilidade da utilizao do microcontrolador FemtoJava (ITO,2000) dedicado a sistemas embarcados, desenvolvido no Grupo de Microeletrnica da Universidade Federal do Rio Grande do Sul, como uma alternativa de multiprocessamento para aplicaes embarcadas. Essa idia atende ao compromisso de minimizar o custo de hardware, eliminando a necessidade de se utilizar um processador mais robusto e mais caro.

Uma vez que o FemtoJava caracteriza-se como uma arquitetura monoprocesso, onde a aplicao do usurio roda diretamente em cima do hardware sem uma camada de software intermediria, a idia inicial deste trabalho analisar a viabilidade de implementao e propor uma alternativa para torn-lo uma arquitetura multitarefa. Posteriormente, este trabalho tem por objetivo avaliar o impacto que esta capacidade de multitarefa traz ao sistema embarcado em termos de rea consumida, consumo de energia e desempenho de processamento.

Figura 1.1: Ncleo Enxuto de um Sistema Operacional

17

Essa soluo para multiprocessamento alcanada com a disponibilizao de uma camada intermediria entre as aplicaes de usurio e a arquitetura do sistema. Essa camada intermediria, apresentada na figura 1.1, seria formada basicamente por um escalonador de tarefas, podendo ser, portanto, considerada como um ncleo enxuto de um sistema operacional.

1.2 Organizao do Trabalho

Este trabalho est organizado em sete captulos incluindo esta introduo. Inicialmente, no captulo 2, apresentada uma reviso bibliogrfica em torno de sistemas operacionais, sistemas embarcados e sistemas de tempo real. Tambm apresentado um rpido panorama sobre o estado da arte de sistemas operacionais embarcados.

O captulo 3 descreve o ambiente de desenvolvimento e o microcontrolador utilizados para a realizao desse trabalho, SASHIMI e FemtoJava respectivamente. A arquitetura software e a arquitetura hardware, alvos deste trabalho, so apresentadas.

O captulo 4 apresenta a explorao do espao de projeto em relao a possibilidade de disponibilizao de multitarefa na arquitetura FemtoJava. So apresentados os detalhes das implementaes e das modificaes realizadas no microcontrolador visando o suporte para a implementao de multitarefa.

O capitulo 5 apresenta as implementaes em software desse trabalho. As caractersticas dos escalonadores, bem como os detalhes de implementao dos mesmos so apresentados. Tambm so discutidas as modificaes na ferramenta SASHIMI e a ferramenta de ligao desenvolvida para auxiliar no projeto.

O capitulo 6 apresenta a descrio dos experimentos e das simulaes realizadas. Uma anlise sobre os resultados obtidos para as implementaes realizada em termos de desempenho, consumo em rea e consumo de energia.

Por fim, no captulo 7 so apresentadas as concluses e consideraes finais sobre o trabalho.

18

2 SISTEMAS OPERACIONAIS E SISTEMAS EMBARCADOS

Qualquer usurio de computador sabe que por trs de seus programas e suas aplicaes favoritas existe um componente chamado de sistema operacional. Pode-se definir um sistema operacional como uma camada de software bsico, encontrada entre o hardware e os programas de usurio, que procura tornar a utilizao de um sistema computacional, ao mesmo tempo, mais eficiente e mais conveniente (OLIVEIRA, 2001).

A utilizao mais eficiente do sistema computacional obtida a partir da distribuio de seus recursos entre os programas. Neste contexto, so considerados recursos quaisquer componentes do hardware disputados pelos programas. J a utilizao mais conveniente obtida a partir da disponibilizao dos recursos do sistema computacional, sem que os usurios necessitem conhecer detalhes especficos de acesso ou programao destes recursos (SILBERSCHATZ, 2000).

2.1 Classificao de Sistemas Operacionais

Basicamente os sistemas operacionais podem ser classificados de acordo com o nmero de usurios, com o nmero de processos de usurio que eles podem executar ou de acordo com o nmero de processadores que o sistema computacional possui. Combinando essas caractersticas pode-se classificar os sistemas operacionais em sistemas operacionais monoprogramados, sistemas operacionais multiprogramados e sistemas operacionais multiprocessados (SHAY, 1996).

Um sistema operacional monoprogramado apresenta as seguintes caractersticas:

executado por um nico processador e capaz de gerenciar a execuo de um nico programa de usurio por vez, por conseqncia, naturalmente monousurio;

Permite que o processador, a memria e os perifricos fiquem dedicados a um nico usurio;

O processador fica ocioso quando o processo espera pela ocorrncia de uma entrada/sada.

19

J os sistemas operacionais multiprogramados, ou multitarefa, apresentam as seguintes caractersticas:

So executados por um ou vrios processadores. No caso de disponibilidade de vrios processadores, so classificados como sistemas operacionais para multiprocessadores (discutido a seguir). No caso de existncia de apenas um processador, permitem que vrios processos disputem os recursos do sistema;

Podem ser monousurio ou multiusurio; Dividem o tempo da CPU entre os vrios processos e entre os vrios usurios; Diminuem a ociosidade, permitindo que durante o tempo de E/S outros

processos sejam executados.

Por fim, os sistemas operacionais para multiprocessadores apresentam as seguintes particularidades:

Executam vrias tarefas simultaneamente e, portanto, so multitarefas; Permitem que mais de um usurio acesse os servios ao mesmo tempo; Possibilitam paralelismo real de processamento; Permitem que cada processador do sistema computacional opere

monoprogramado ou multiprogramado.

Outra forma possvel de classificao de sistemas operacionais est diretamente relacionada com a aplicabilidade dos mesmos (figura 2.1), onde se pode dividi-los em trs grandes grupos: sistemas operacionais convencionais, sistemas operacionais embarcados, e sistemas operacionais de tempo real (OLIVEIRA, 2001). Essa outra maneira de classificao permite localizar o espao de projeto dentre os sistemas operacionais que esse trabalho pretende abordar.

Figura 2.1: Classificao de Alguns S.O. de Acordo com a Aplicabilidade

20

Os sistemas operacionais convencionais so aqueles tradicionalmente encontrados nos computadores pessoais. Dentre eles podemos citar os sistemas operacionais Windows, Linux e MacOS. Os sistemas operacionais embarcados e sistemas operacionais de tempo real so um subconjunto de sistemas operacionais com particularidades e caractersticas prprias que sero discutidas nas prximas sees.

2.1 Sistemas Operacionais Embarcados

Uma viso muito comum sobre sistemas embarcados a afirmao de que se uma aplicao no possui uma interface de usurio, ou se o usurio no interage diretamente com a interface do dispositivo ento, esse dispositivo um sistema embarcado e possui um sistema operacional embarcado por trs do seu gerenciamento (KADIONIK, 2002). Esse conceito simplista no totalmente correto. Por exemplo, um sistema computadorizado de controle de um elevador considerado embarcado, porm o mesmo possu botes para selecionar o andar desejado e indicadores para mostrar em qual andar o elevador est localizado. Pode-se imaginar, tambm, um outro sistema embarcado conectado a Internet que apresente um servidor WEB para monitoramento e controle. Esse servidor pode ser considerado a interface do sistema com o usurio, tornando, ento, a afirmao invlida. Uma definio mais correta, a respeito de sistema embarcado, pode ser alcanada se suas funes e propostas forem corretamente entendidas.

Um sistema operacional embarcado, assim como um sistema operacional convencional, consiste em um conjunto de mdulos, tais como um sistema de arquivos, protocolos de comunicao e de rede, drivers de dispositivos e etc. O nmero de mdulos que podem estar envolvidos em um sistema operacional embarcado depende exclusivamente das necessidades e das limitaes do sistema. Alguns sistemas operacionais embarcados podem trabalhar autonomamente, tais como sistemas que monitoram continuamente o funcionamento de um equipamento, sem a necessidade de interveno humana ou comandos externos. Esses sistemas embarcados possuem mecanismos ou sensores capazes de detectar algum desvio no comportamento do equipamento ou dispositivo e gerar interrupes para que alguma providncia pr-estabelecida seja tomada, interagindo diretamente com o sistema operacional embarcado (DENYS, 2002) (KADIONIK, 2002). Outros sistemas embarcados, por natureza, interagem com o usurio mais seguidamente, como, por exemplo, os telefones celulares. Dessa forma, pode-se notar que sistemas operacionais embarcados so encontrados atualmente nos mais variados equipamentos, desde impressoras, relgios, equipamentos mdicos, sistemas automotivos e, at mesmo, em videogames.

Portanto, um sistema operacional embarcado um subconjunto dos sistemas operacionais, dedicado a execuo de tarefas especficas, disponibilizando apenas as funes e servios necessrios para o dispositivo ou equipamento no qual o mesmo est

21

enquadrado. Partindo dessa premissa, possvel entender que a quantidade de funes oferecidas por um sistema operacional embarcado pode variar de acordo com a necessidade da aplicao, podendo o mesmo conter algum mdulo bsico de servio modificado, ou at mesmo suprimido. Na realidade, isso o que acontece com a grande maioria dos dispositivos e equipamentos que empregam um sistema operacional embarcado. Nesses equipamentos, o sistema operacional atende as necessidades especficas da aplicao, por exemplo, reduzindo o suporte a perifricos de entrada e sada e eliminando a gerncia de memria virtual. Assim possvel economizar rea de memria, tempo de processamento, dissipao de energia e, tambm, diminuir o custo do hardware.

Na prtica, ao longo dos anos, os desenvolvedores de sistemas embarcados tm enfrentado algumas dificuldades para implementarem suas solues devido limitao de recursos dos dispositivos como, por exemplo, pouca memria disponvel e poder de processamento limitado (CLARK, 2002). Isso ocorre, por exemplo, nos sistemas embarcados em brinquedos eletrnicos, onde se pode ter disponvel apenas algumas dezenas de Kbytes de memria, com o intuito de no aumentar o custo final do produto. A tabela 2.1 apresenta alguns sistemas operacionais embarcados comerciais e suas aplicaes em produtos e equipamentos.

Tabela 2.1: Alguns Sistemas Operacionais Embarcados e Suas Aplicaes

Empresa S.O. Embarcado Aplicao / Equipamento

Integrity Gerenciador e Regulador de Banda WaveStar da Lucent Green Hills Software ThreadX Impressoras Jato de Tinta da HP Embedix PDA Zaurus da Sharp Lineo uCLinux Sistema de comunicao Blip da Ericson

Mentor Grafics Corp. VRTX Telescpio Espacial Hubble da NASA WinCE IPAQ da Compaq Microsoft Corp. WinNT Embedded Servidor HiPath 5300 da Siemens

Monta Vista Software Inc. Hard Hat Linux TVs Digitais da Toshiba QNX Software Systems Inc. QNX Servidores de Vdeo sobre demanda da Sony

Red Hat Emb. Linux Playstation 2 da Sony Red Hat Inc. eCos Impressoras Laser da Brother

Wind River Systems Inc. VxWorks Marte PathFinder da NASA

Fonte: (SANTO, 2001)

2.2 Sistemas Operacionais de Tempo Real

Os sistemas operacionais de tempo real so aqueles empregados em dispositivos e equipamentos que necessitam de uma garantia de tempo mximo de resposta, ou seja, so utilizados no suporte s aplicaes submetidas a requisitos de natureza temporal.

22

Vrios produtos, que apresentam processadores embarcados, no necessitam que o tempo de processamento e resposta do sistema seja rigorosamente bem definido, no apresentando, portanto, a necessidade de um sistema operacional de tempo real. Por outro lado, alguns outros dispositivos necessitam que os resultados processados sejam gerados no momento correto, sob pena de comprometer o funcionamento total do sistema caso ocorra algum atraso ou imprevisto durante a execuo e o processamento. Aplicaes com requisitos de tempo real so cada vez mais comuns nos dias de hoje, variando muito com relao ao tamanho e complexidade. Entre os sistemas mais simples esto os controladores embarcados em utilidades domsticas, tais como fornos de microondas e videocassetes. Na outra extremidade do espectro, onde sistemas de real-time so empregados, encontram-se os sistemas militares de defesa e o controle de trfego areo (OLIVEIRA, 2001).

importante notar a diferena entre sistemas de tempo real e sistemas velozes, pois muito comum que um sistema real-time seja confundido com um sistema rpido (ZUBERI, 2001). Atualmente, tem-se a disposio uma grande variedade de processadores com alto poder de desempenho, capazes de trabalhar com freqncias na faixa de GHz. Isso, porm, no implica que, em equipamentos onde sejam empregados esses processadores, o sistema seja real-time. Tipicamente, um sistema de tempo real deve permitir que os processos sejam invocados em intervalos peridicos e fixos, ou que os processos possam ser agendados para comear ou parar depois de um perodo de tempo especfico. Um sistema de tempo real, portanto, no precisa ser necessariamente rpido, ele deve permitir que um processo possa ser escalonado para ocorrer em um tempo pr-determinado, com tolerncias conhecidas. Em outras palavras, um verdadeiro sistema real-time precisa ser determinstico, para que possa garantir um tempo mximo de resposta (BARABANOV, 1996) (KADIONIK, 2002).

Um outro ponto fundamental na conceituao de sistemas de tempo real quanto ao grau de flexibilidade e disponibilidade do sistema operacional. Algumas aplicaes necessitam que os clculos sejam 100% validados e completados dentro de poucos microsegundos. Essas aplicaes, onde existe a rigorosidade e garantia de processamento dentro do tempo estabelecido, so conhecidas como aplicaes hard real-time. Outras aplicaes so menos rigorosas, e necessitam um menor grau de garantia de resposta, podendo ser calculadas dentro de um tempo limite pr-estabelecido e aceitvel. Essas aplicaes so conhecidas como soft real-time (SANTO, 2001) (FARINES, 2000).

A concepo de sistemas operacionais de tempo real no to simples como se parece, pois vrias tcnicas e algoritmos para o atendimento de interrupes e prioridades precisam ser implementados, e em muitos casos, dependendo das necessidades do sistema, precisam ser desenvolvidos ou adaptados. Sistemas operacionais de tempo real constituem-se em uma linha de pesquisa bastante particular na rea de sistemas operacionais, onde muitos pesquisadores concentram seus esforos para encontrarem novas solues e

23

aprimorarem as tcnicas utilizadas, devido necessidade de meios eficazes para controlar e gerenciar os processos envolvidos no sistema.

Ento, a definio mais coerente sobre um sistema operacional real-time parece ser a que o define como um sistema capaz de tratar os eventos do mundo real, com um tempo de resposta definido, previsto e relativamente pequeno.

2.3 Estado da Arte em Sistemas Operacionais Embarcados

Como j apresentado anteriormente, vrios sistemas operacionais embarcados esto disponveis atualmente no mercado, cada qual com suas caractersticas, limitaes, vantagens, desvantagens e aplicabilidades. Alguns desses sistemas podem estar mais direcionados a uma determinada aplicao, enquanto outros atendem melhor uma outra rea, sendo mais indicados e especficos para determinados fins. No se pode dizer que, hoje, exista um sistema operacional embarcado, que seja amplamente superior aos demais, o qual todos os desenvolvedores invejam e copiam para conceberem os seus prprios sistemas. O panorama atual nos demonstra que a escolha por um determinado sistema operacional que ser embarcado em algum produto ou equipamento, muitas vezes est diretamente ligada s caractersticas, s vantagens e s ferramentas que esse sistema pode oferecer para a aplicao, alm da questo time to market, e do custo que o mesmo agregar ao produto final (SANTO, 2001).

Muitos desenvolvedores de sistemas operacionais embarcados tm adotado diferentes estratgias e trabalhado em diferentes linhas de pesquisa para a implementao dos seus sistemas, sempre no esforo de prover um sistema operacional embarcado mais interessante e atrativo para o maior nmero de aplicaes possveis onde o mesmo ser usado. A seguir apresentado um breve resumo sobre o estado da arte em termos de sistemas operacionais embarcados e suas particularidades.

2.3.1 Sistema Operacional eCOS

O sistema operacional eCOS (REDHAT, 2003), embedded configurable operating system, desenvolvido pela Red Hat, foi totalmente concebido como um sistema open-source. Porm, desde o seu surgimento at os dias de hoje, o sistema operacional e a documentao so disponibilizados atravs do pagamento de uma licena para sua utilizao. Aps a aquisio, o usurio tem total acesso ao cdigo fonte para realizar modificaes e customizaes. Atualmente ele encontra-se na verso 2.0.

O eCOS um sistema operacional embarcado real-time direcionado para aplicaes com restries temporais. Ele pode trabalhar com um tamanho limitado de

24

memria, variando desde poucas dezenas at centenas de Kbytes. Por apresentar essa caracterstica, ele empregado em produtos que no dispem de uma grande quantidade de memria, tais como algumas impressoras laser e players de udio.

O pacote comercializado pela Red Hat conta com uma ferramenta de configurao grfica, a qual permite que o usurio personalize e selecione as caractersticas desejadas do sistema operacional, de acordo com suas necessidades. Por exemplo, os escalonadores de processos que estaro presentes no sistema podem ser selecionados.

Esse sistema operacional implementa as polticas de escalonamento definidas pela norma POSIX (GALLMEISTER, 1995). As polticas FIFO (First In First Out), Round-Robin, Mltiplas Filas e Prioridades so encontradas no mesmo.

Uma grande vantagem do eCOS sobre outros sistemas operacionais embarcados comercializados que ele pode trabalhar com vrias arquiteturas, tais como ARM, Hitachi SH3 e SH4, MIPS, NEC V850, Panasonic AM3x, Motorola PowerPC, SPARC e x86.

2.3.2 Sistema Operacional NetBSD

O NetBSD (NETBSD, 2004) um sistema embarcado bastante popular na linha de sistemas operacionais baseados em Unix. Ele tambm se enquadra na categoria de sistemas operacionais embarcados open-source, pois possui seu cdigo fonte aberto. Ao contrrio do sistema operacional eCOS, o NetBSD gratuito, podendo ser obtido atravs do website do projeto NetBSD, mantido pela NetBSD Foundation.

A primeira verso do NetBSD surgiu em meados de 1993, e o principal foco do projeto NetBSD era o de criar um sistema operacional extremamente portvel, permitindo que o sistema operasse com diferentes arquiteturas. Isso realmente acontece nos dias de hoje, pois o NetBSD 1.6.1 pode trabalhar com os processadores Alpha, ARM, i386, Motorola PowerPC, SPARC, Motorola 68k, Hitashi SH3, VAX, MIPS, entre outros.

Uma desvantagem do NetBSD em relao a outros sistemas operacionais, que ele necessita de uma razovel quantidade de memria para trabalhar. O NetBSD precisa, tipicamente, entre 400 Kbytes at 1,5 Mbytes de memria flash, e 2 Mbytes at 16 Mbytes de memria RAM, dependendo da funcionalidade e dos mdulos envolvidos na sua configurao. Por esse motivo, ele utilizado principalmente em roteadores e equipamentos ligados a Internet, os quais possuem uma boa capacidade de memria disponvel.

25

2.3.3 Sistema Operacional Windows Embarcado

O mercado de sistemas operacionais embarcados, carente por um desenvolvedor e por um sistema operacional dominante, chamou, tambm, a ateno da Microsoft que desenvolveu dois sistemas operacionais embarcados com o intuito de conquistar uma boa fatia do mercado. Os dois sistemas no foram lanados com cdigo fonte aberto, assim como os outros sistemas operacionais da Microsoft, no sendo, portanto, considerados open-source. Eles tambm no so gratuitos e utilizam a tecnologia Windows como base de desenvolvimento.

Primeiramente a Microsoft lanou, em 1996, o Windows CE Embedded (MICROSOFT, 2004), o qual incorporava algumas poucas caractersticas de real-time como, por exemplo, suporte a interrupes aninhadas. Em meados de 2000 a Microsoft reescreveu o kernel do Windows CE para transform-lo em um verdadeiro sistema operacional de tempo real. Atualmente esse sistema operacional encontra-se disponvel na verso Windows CE .NET 4.2. Esse sistema suporta processadores x86, Motorola PowerPC, Hitashi Super-H, MIPS, alm daquelas baseadas em tecnologia ARM. Possui um kernel com tamanho relativamente compacto, em torno de 400 Kbytes, podendo ser armazenado em uma ROM.

O outro sistema operacional embarcado desenvolvido pela Microsoft foi o Windows NT Embedded (MICROSOFT, 2004), atualmente substitudo pelo seu sucessor, o Windows XP Embedded. Esse sistema, ao contrrio do Windows CE, apresenta um tamanho consideravelmente grande para aplicaes que dispem de pouca memria. A configurao mnima requerida pelo sistema de 9 Mbytes de memria RAM e 8 Mbytes de espao em disco, isso se o sistema no contar com suporte a rede. Se somado os componentes de rede e os drivers de dispositivos, o sistema passa a requerer 13 Mbytes de memria RAM e 16 Mbytes de espao em disco. Portanto, o Windows XP Embedded no ideal para aplicaes em sistemas embarcados pequenos, tais como dispositivos de mo.

2.3.4 Sistema Operacional uClinux

O uClinux (UCLINUX, 2004) um sistema operacional totalmente voltado para aplicaes em sistemas embarcados. O acrnimo uClinux significa Micro Controller Linux, embora a pronuncia correta para o nome seja You see Linux em aluso ao fato do usurio ter acesso ao seu cdigo fonte.

O projeto uClinux nasceu em janeiro de 1998, sendo concebido a partir do kernel 2.0 do Linux e direcionado para processadores que no possuam uma unidade de gerenciamento de memria. O cdigo foi totalmente revisto e muita coisa foi reescrita para

26

que o kernel pudesse ser otimizado. O resultado foi gerao de um kernel muito menor que o kernel 2.0 do Linux, possuindo menos de 512 Kbytes de tamanho.

O uClinux j incorpora por padro a pilha TCP/IP, assim como o suporte a uma srie de outros protocolos de rede, permitindo acesso Internet para os dispositivos no qual ele est embarcado. Ele tambm suporta alguns sistemas de arquivos diferentes, dentre eles o NFS, o ext2, o MS-DOS e o FAT16/32.

O sistema operacional uClinux um sistema free open-source, ou seja, alm de permitir acesso ao seu cdigo fonte ele gratuito, podendo ser adquirido e utilizado sem a necessidade de pagamento de licenas. Esse sistema, tambm, pode trabalhar com uma srie de arquiteturas, dentre elas os processadores Motorola DragonBall e ColdFire, ARM, NEC V850E e Intel i960. Alm dessas arquiteturas citadas a cima, existem projetos em desenvolvimento para que o uClinux possa ser portado para processadores PRISMA e Atari 68k.

Atualmente o sistema operacional uClinux no se encontra embarcado em muitos produtos eletro-eletrnicos disponveis no mercado. Porm, existem vrios kits sendo comercializados, que servem para o desenvolvimento de novas aplicaes. Esses kits esto disponveis com diversas configuraes de memria e processadores, permitindo que o desenvolvedor possa escolher qual atende melhor a sua necessidade.

2.3.5 Sistema Operacional VxWorks

O sistema operacional VxWorks (WINDRIVER, 2003) desenvolvido pela WindRiver atualmente um dos mais difundidos sistemas operacionais embarcados em produtos e equipamentos disponveis no mercado, por ser um sistema operacional real-time, poderoso e flexvel. Ele encontrado em vrias reas como, por exemplo, sistemas de controle de processos em industrias, cmeras digitais, simuladores de vo, PDAs e sistemas de navegao em automveis. O VxWorks no um sistema open-source nem, to pouco, gratuito.

O seu kernel foi concebido com um grande nmero de funes de tempo real, incluindo, por exemplo, suporte a interrupes, 256 nveis de prioridades, memria compartilhada, polticas de escalonamento FIFO preemptiva e Round-Robin, dentre outras funes que aumentam o desempenho do sistema e oferecem respostas mais rpidas aos processos envolvidos e aos eventos externos.

O VxWorks, na sua verso 5.4, tambm oferece conexo a redes externas atravs de seu suporte TCP/IP, e a capacidade de trabalhar com diferentes processadores da famlia Motorola, dentre eles o ColdFire, o PowerPC e o 68k. Essa verso comumente encontrada nos equipamentos que utilizam o VxWorks como sistema operacional embarcado. J a

27

verso VxWorks AE, recentemente lanada pela WindRiver, conta com suporte a outras arquiteturas, tais como, Intel Pentium, ARM e Hitachi SuperH.

2.3.6 Sistema Operacional MiniRTL

O MiniRTL (GUIRE, 2001) um sistema operacional ainda no implementado em produtos e equipamentos comercializados, porm, promete ser um interessante referencial no meio acadmico para o desenvolvimento de sistemas operacionais real-time embarcados. Concebido pelo Dr. Nicholas Mc Guire, da Universidade de Vienna na ustria, e pela FSMLabs, uma empresa de desenvolvimento e pesquisa que trabalha com sistemas operacionais de tempo real, esse sistema foi baseado no RTLinux, uma variante do Linux com caractersticas de tempo real, com o propsito de atender especialmente a sistemas embarcados.

O MiniRTL um sistema operacional hard real-time, e suporta apenas processadores padro x86, diferentemente de outros sistemas j descritos anteriormente. Ele conta, tambm, com suporte a rede e vrias ferramentas de apoio, como, por exemplo, acesso seguro via SSH, mini-HTTPD e suporte CGI-BIN, entre outras, que o tornam um sistema bastante completo e funcional, mesmo apresentando um tamanho compacto. Nesse sistema operacional, assim como no padro Linux, possvel otimizar e minimizar o kernel, selecionando-se os componentes que sero compilados e incorporados ao sistema. Assim como outros sistemas operacionais Linux, as polticas de escalonamento baseadas em prioridade, FIFO e Round-Robin, esto presentes. Atualmente o MiniRTL disponibilizado na verso 2.3, incorporando o kernel 3.0 do RTLinux.

2.4 Resumo

Esse captulo fez uma reviso em torno de sistemas operacionais, sistemas embarcados e sistemas de tempo real. Duas classificaes possveis sobre sistemas operacionais foram apresentadas, uma quanto ao nmero de processos que esses so capazes de executar e outra de acordo com a aplicabilidade dos mesmos. Tambm foram apresentadas algumas caractersticas de sistemas operacionais embarcados.

Foi visto que, basicamente, os sistemas operacionais embarcados so customizados para oferecerem servios e caractersticas de forma a atender requisitos especficos de uma aplicao. Uma constatao interessante que praticamente todos os sistemas operacionais embarcados, inclusive os de tempo real, disponibilizam as polticas FIFO e Round-Robin para o escalonamento de tarefas.

28

3 DESCRIO DO AMBIENTE DE DESENVOLVIMENTO

Este captulo apresenta sucintamente o ambiente de desenvolvimento para aplicaes embarcadas em linguagem Java associado a uma arquitetura dedicada aplicao, o SASHIMI e o FemtoJava respectivamente. Ambos, ambiente de desenvolvimento e microcontrolador, foram desenvolvidos dentro do Grupo de Microeletrnica da UFRGS (ITO, 2000). A figura 3.1 ilustra o fluxo resumido de projeto do ambiente, desde o cdigo Java da aplicao at o chip do microcontrolador sintetizado.

Como ser visto, esse ambiente de desenvolvimento integrado a uma arquitetura Java embarcada uma maneira rpida, fcil e bastante eficiente de construir a implementao de um sistema embarcado diretamente em linguagem de alto nvel.

Figura 3.1: Fluxo de Projeto do Ambiente SASHIMI

3.1 Arquitetura Hardware: O Microcontrolador FemtoJava

Os processadores dedicados ao mundo dos sistemas embarcados apresentam algumas restries que os tornam diferentes dos processadores para desktop tradicionais.

29

Como j visto anteriormente, aplicaes como consoles de vdeo game, telefones celulares e PDAs, entre outras, necessitam um conjunto hardware e software que demandem baixo consumo de energia e cdigo de programa enxuto. Isso necessrio para aumentar a autonomia de funcionamento do equipamento ou dispositivo eletroeletrnico no qual a arquitetura embarcada est inserida, e possibilitar o uso de uma quantidade de memria relativamente pequena, se comparada memria disponvel nos desktops.

Para o mercado de processadores embarcados no apenas a capacidade de processamento importante, mas a rea consumida e a potncia so fatores de extrema relevncia (ITO, 2001). Isso se deve basicamente a dois fatores. O primeiro deles, j citado, o consumo de energia. Quanto maior o dispositivo e maior a capacidade de processamento do mesmo, provavelmente maior ser o consumo de energia no sistema embarcado. O segundo fator est diretamente relacionado rea ocupada pelo processador concebido. Observando-se pelo ponto de vista tecnolgico, o aumento da densidade dos FPGAs atualmente disponveis permite a integrao dos sistemas embarcados em um nico dispositivo FPGA. Porm, no se pode esquecer que o tamanho da memria disponvel nos FPGAs pode ser limitado. Assim, o desenvolvedor precisa obedecer s restries de tamanho do dispositivo alvo ao escrever programas embarcados. Outro fator relevante a ser analisado ao se utilizar FPGAs como tecnologia alvo para a concepo de sistemas embarcados referente ao custo de produo. Utilizando-se FPGAs menores diminui-se diretamente o custo final de obteno do sistema embarcado. Portanto, cabe ao projetista, mais uma vez, minimizar ao mximo o conjunto hardware e software do sistema embarcado para disponibilizar um produto mais barato e competitivo no mercado.

3.1.1 Arquitetura do Microcontrolador FemtoJava

Uma execuo eficiente de programas Java, mais especificamente em sistemas embarcados, pode ser feita executando-se diretamente bytecodes Java em hardware (ITO, 2001). Essa a principal caracterstica e propsito do microcontrolador FemtoJava, o qual implementa uma mquina de pilha. Ele foi concebido tendo como objetivo a sua aplicao em sistemas embarcados com caractersticas de baixa potncia, direcionado para a sntese em FPGA. Outras caractersticas dessa arquitetura so o seu tamanho reduzido em rea, o nmero reduzido de instrues e ser descrito em VHDL (Very High Speed Integrated Circuit Hardware Description Language), o que facilita a adio e a remoo de instrues na sua arquitetura. Essa ltima caracterstica foi decisiva na escolha desse microcontrolador para a implementao e avaliao do espao de projeto, visto que o desenvolvimento de novas instrues para a arquitetura era indispensvel para incluso do suporte a multitarefa, objetivo deste trabalho.

Ao longo de seu desenvolvimento o FemtoJava sofreu diversas modificaes. Atualmente a verso Multiciclo composta por uma unidade de processamento, memrias

30

RAM e ROM, portas de entrada e sada mapeadas em memria e um mecanismo de tratamento de interrupes com dois nveis de prioridade. A arquitetura da unidade de processamento implementa um subconjunto de 66 instrues da Mquina Virtual Java, e seu funcionamento consistente com a especificao da JVM (ITO, 2000). Alm dessas 66 instrues, mais trs instrues estendidas esto, tambm, disponveis na arquitetura, totalizando um nmero de 69 instrues. Duas dessas instrues estendidas tem por funo permitir a realizao de leitura e escrita s posies de memria da arquitetura. A terceira instruo estendida possibilita que o FemtoJava seja colocado em modo de espera.

Uma caracterstica limitante dessa arquitetura permitir um nico fluxo de execuo. Nessa arquitetura no se tem suporte a mltiplos fluxos de execuo e, to pouco, paralelismo real ou virtual de processamento. Porm, essa caracterstica, segundo ITO, permitiu que diversas simplificaes fossem efetuadas para a concepo da arquitetura.

A figura 3.2 apresenta a arquitetura FemtoJava e as tabelas 3.1 e 3.2 fornecem, respectivamente, algumas informaes adicionais e seu conjunto de instrues.

Figura 3.2: Arquitetura FemtoJava Multiciclo (ITO, 2000)

31

O conjunto de instrues, de acordo com ITO, embora reduzido, porm satisfatrio, foi assim definido visto que o conjunto de instrues Java extenso e apresenta instrues complexas, cuja funcionalidade transcende a possibilidade de implementao a custos aceitveis para as aplicaes embarcadas, pois demandariam a disponibilidade de maiores recursos de hardware.

Tabela 3.1: Algumas Caractersticas do FemtoJava Multiciclo

Algumas Caractersticas do Microcontrolador FemtoJava Multiciclo Mquina de pilha; Ausncia de pipeline; Arquitetura Harvard; Instrues executadas em 3, 4, 7 ou 14 ciclos; Verses 8 e 16 bits disponveis; Otimizado para o FPGA Flex10K da Altera Corporation; Disponibilidade de sistema de temporizao e de interrupo.

Tabela 3.2: Conjunto de Instrues FemtoJava (SASHIMI, 2002)

Tipos de Instruo Mnemnicos Aritmticas & Lgicas iadd, isub, imul, ineg, ishr, ishl, iushr, iand, ior, ixor

Controle de Fluxo goto, ifeq, ifne, iflt, ifge, ifgt, ifle, if_icmpeq, if_icmpne, if_icmplt, if_icmpge, if_icmpgt, if_icmple, return, ireturn, invokestatic

Operaes de Pilha iconst_m1, iconst_0, iconst_1, iconst_2, iconst_3, iconst_4, iconst_5, bipush, pop, pop2, dup, dup_x1, dup_x2, dup2, dup2_x1, swap

Load & Store iload, iload_0, iload_1, iload_2, iload_3, istore, istore_0, istore_1, istore_2, istore_3

Array ialod, baload, caload, saload, iastore, bastore, castore, sastore, arraylenght

Estendido load_idx, store_idx, sleep Outros nop, iinc, getstatic, putstatic

3.1.2 Sistema de Temporizao

Os temporizadores so mecanismos fundamentais para a implementao de aplicaes e programao de um microprocessador. Esses temporizadores podem ser programados como contadores de eventos externos ou como contadores de pulsos de relgio. O FemtoJava possui dois temporizadores chamados de timer 0 e timer 1. Cada temporizador apresenta seu registrador mapeado em memria.

32

Detalhes minuciosos sobre o sistema de temporizao da arquitetura no so apresentados aqui, porm importante saber que o timer 0 possui seu valor mapeado na posio 0CH da memria RAM. Esse valor hexadecimal, multiplicado por cinco, o nmero exato de ciclos para a ocorrncia de uma interrupo. Alterando-se o valor mapeado na memria, pode-se aumentar ou diminuir a freqncia de ocorrncia de interrupes.

Maiores detalhes e informaes sobre o sistema de temporizao do FemtoJava podem ser encontradas em sua documentao (SASHIMI, 2002).

3.1.3 Sistema de Interrupo

O FemtoJava dotado de um sistema de interrupo com dois nveis de prioridade e atendimento a cinco interrupes diferentes. Os registradores que programam o sistema de interrupo esto mapeados em memria RAM e podem ser acessados utilizando os bytecodes estendidos load_idx e store_idx (SASHIMI, 2002). Basicamente existem dois registradores responsveis pelo sistema de interrupo. O primeiro deles, o registrador IE responsvel pela habilitao ou desabilitao das interrupes. Atravs dele possvel habilitar individualmente cada interrupo ou desabilitar todas as interrupes simultaneamente. O segundo, o registrador IP, responsvel pela prioridade da interrupo, sendo essa alta ou baixa.

Maiores detalhes sobre o sistema de interrupo do FemtoJava no sero apresentados neste trabalho, porm relevante saber que o sistema de interrupo que habilita o timer 0 est mapeado na posio 00H da memria de dados, e que o valor para habilitar a interrupo do timer 0 22H.

3.1.4 Registradores Internos

Em funo da sua arquitetura de pilha o microcontrolador FemtoJava no possui registradores diretamente acessveis pelo programador. Entretanto, internamente esses registradores esto disponveis para armazenar informaes de execuo, valores resultantes de operaes e endereos. A seguir, na tabela 3.3, so apresentados os registradores do FemtoJava.

33

Tabela 3.3: Registradores Internos do FemtoJava Multiciclo

Registrador Descrio

PC O registrador PC o registrador responsvel por manter o endereo da prxima instruo a ser executada. As instrues que podem modificar seu contedo so as instrues de desvio condicional, desvio incondicional, chamadas e retorno de mtodos.

SP

O registrador SP mantm o endereo absoluto ao topo da pilha. Na realidade, o endereo poderia ser relativo, pois como ser visto adiante, o registrador FRM mantm o endereo para o frame atual. Entretanto, a estratgia de utilizar endereos absolutos para SP tem o intuito de permitir armazenar posteriormente o valor de PC e de VARS tambm na pilha, utilizando um pequeno cdigo adicional.

MAR

o registrador temporrio que armazena dados antes de serem transferidos para a memria. Todas as operaes que exigem armazenamento na pilha utilizam esse registrador para armazenar os dados resultantes de clculos, leituras memria ou valores imediatos antes da transferncia para a memria.

FRM

O registrador FRM o registrador que mantm o endereo do frame atual. Um frame uma estrutura alocada dentro da memria de dados que contm as informaes relativas ao mtodo, tais como variveis locais e pilha de operandos do mtodo.

IR Registrador que armazena o opcode da instruo sendo executada.

IMMED o registrador que mantm as informaes referentes ao dado imediato das instrues caso a instruo possua mais de um byte, como por exemplo, a instruo bipush.

VARS Registrador que aponta para as variveis locais dentro do frame.

A e B

So os registradores utilizados para armazenar os dados lidos da pilha e que sero operados pela ULA. Esses registradores so necessrios visto que no existem registradores internos de propsito geral para armazenar dados lidos da memria.

3.1.5 As Memrias de Programa e de Dados do FemtoJava

O microcontrolador FemtoJava possui as memrias de programa e de dados fisicamente distintas utilizando espaos de endereamento separados (arquitetura Harvard). A capacidade de ambas as memrias e a largura da palavra da memria de dados so configurveis de acordo com as caractersticas da aplicao. Ambas as memrias so implementadas utilizando a memria interna do prprio FPGA, e possuem barramentos distintos para o acesso s mesmas (ITO, 2000).

A memria de programa implementada como uma ROM, cuja palavra fixa em 8 bits, nica caracterstica no configurvel. Essa restrio foi adotada para simplificar o

34

acesso aos operandos e a decodificao das instrues que so organizadas byte a byte dentro da memria de programa (ITO, 2000).

A organizao da memria de programa apresentada na figura 3.3a, que representa uma memria cujo tamanho mximo 256 bytes, enderevel atravs de um barramento de 8 bits. Esta memria corresponde a verso de 8 bits do microcontrolador FemtoJava.

Durante a inicializao do microcontrolador o PC contm o endereo 00H, que possui uma instruo de chamada de mtodo esttico, correspondente ao incio da aplicao. As posies seguintes da memria de programa, que vo de 03H a 2AH, so reservadas s rotinas de tratamento de interrupes, possuindo 8 bytes cada. O restante da rea disponvel da memria ocupada pelo cdigo da aplicao, a partir do endereo 2BH.

Figura 3.3: Memria de Programa (a) e Memria de Dados (b)

J a memria de dados organizada de acordo com a figura 3.3b. As primeiras 16 palavras da memria de dados so reservadas ao mapeamento dos registradores do sistema de E/S, do sistema de interrupo e dos contadores de eventos. As posies subseqentes de memria so utilizadas para o armazenamento das variveis globais definidas na aplicao. A alocao de frames efetuada na rea de memria de dados restante, e se inicia no endereo de maior valor, devido caracterstica de pilha do microcontrolador. Portanto, durante a inicializao do microcontrolador, o registrador SP contm o valor FFH no caso de uma memria de 256 palavras da verso 8 bits (ITO, 2000).

35

A figura 3.4 apresenta um exemplo de uma memria de programa para o microcontrolador FemtoJava, visando a familiarizao do projetista com o cdigo assembly Java e com o formato de memria ROM utilizada pelo microcontrolador. Nessa ilustrao possvel ver as instrues Java, bem como os espaos de memria reservados para as rotinas de tratamento. Os endereos 03H, 0BH, 13H, 1BH e 23H so os endereos iniciais para as rotinas de tratamento das cinco interrupes diferentes (int0, tf0, int1, tf1 e spi). Os tratamentos tf0 e tf1 so relativos ao sistema de temporizao do FemtoJava. Os tratamentos int0 e int1 so referentes ao sistema de interrupes. O tratamento spi, por sua vez, relativo ao tratamento de interrupo serial do FemtoJava.

Figura 3.4: Exemplo de Memria de Programa ROM.mif

36

3.2 Arquitetura Software: O Ambiente SASHIMI

O SASHIMI (Systems As Software and Hardware In MIcrocontrollers) um ambiente destinado sntese de sistemas embarcados especificados em linguagem Java. Esse ambiente proporciona ao projetista a possibilidade de uma aplicao descrita em linguagem Java ser analisada e otimizada para executar sobre um ASIP (Application-Specific Instruction Set Processor) Java, sintetizado, por exemplo, em um dispositivo FPGA. Portanto, o ambiente SASHIMI utiliza as vantagens da tecnologia Java e fornece ao projetista um mtodo eficiente, simples e rpido para obter solues baseadas em hardware e software para sistemas embarcados.

A abordagem SASHIMI difere-se da prtica convencional de desenvolvimento de sistemas embarcados com microcontroladores em dois aspectos principais. Primeiro, em geral, tais dispositivos tm sido programados diretamente em linguagem assembly, resultando em programas eficientes, mas de alto custo de desenvolvimento e manuteno (SASHIMI, 2002). A abordagem SASHIMI permite a utilizao de uma linguagem de alto nvel no somente para programao, mas para a especificao completa do sistema. Segundo, a modelagem suportada por um conjunto de bibliotecas que representam o comportamento dos componentes mais comumente utilizados em sistemas envolvendo microcontroladores, como, por exemplo, displays, botes, teclados e conversores A/D e D/A. Portanto, a simulao do sistema modelado permite verificar a funcionalidade da aplicao com toda a comodidade do desenvolvimento em um ambiente desktop, tornando factvel a reestruturao ou modificao da aplicao em curto perodo de tempo quando necessrio (SASHIMI, 2002).

As ferramentas do ambiente SASHIMI suportam a extrao automtica do subconjunto de bytecodes Java necessrio para implementar o software da aplicao. Para cada sistema pode-se gerar um microcontrolador especfico, com o conjunto de bytecodes otimizado, e automaticamente adaptar o seu software. Portanto, o resultado a economia de recursos de hardware e a obteno do software otimizado para cada aplicao de usurio.

Atualmente, apenas aplicaes com uma nica thread podem ser sintetizadas utilizando-se as ferramentas do SASHIMI. Uma outra caracterstica desse ambiente a no incluso de simuladores VHDL ou ferramentas de sntese para a realizao da prototipao, sendo necessrio utilizao de ferramentas de sntese adicionais como, por exemplo, o Max+Plus II ou o Quartus II da Altera Corporation para a obteno do dispositivo FPGA final. Outros detalhes conceituais em torno do ambiente SASHIMI esto descritos em (ITO, 2000).

37

3.2.1 Regras de Modelagem do Ambiente SASHIMI

No ambiente SASHIMI a modelagem do sistema deve ser feita em linguagem Java, respeitando algumas restries que sero apresentadas a seguir. O domnio das aplicaes atualmente sintetizveis pelo ambiente restrita a aplicaes embarcadas simples, pois somente um nico fluxo de execuo pode ser executado pela arquitetura. Segundo ITO, a natureza das aplicaes alvo induz a algumas restries no estilo de codificao. Portanto, uma aplicao Java para ser sintetizvel no ambiente SASHIMI deve respeitar as seguintes condies:

operador new no permitido, pois seria necessrio prover servios de gerenciamento de memria virtual;

apenas mtodos e variveis estticas so permitidas, salvo os mtodos das interfaces providas pela API do ambiente SASHIMI e implementadas pela classe sendo modelada;

mtodos recursivos no so permitidos, pois seriam necessrios mecanismos para gerenciamento dinmico de memria;

interfaces no so suportadas, desde que associaes dinmicas (binding) representam um custo adicional em tempo de execuo;

dados do tipo ponto-flutuante no podem ser utilizados na verso disponvel. Contudo, o suporte a esse tipo de dados pode ser obtido atravs da disponibilidade de FPGAs de maior capacidade ou atravs de uma biblioteca adequada;

mltiplas threads no so sintetizadas, desde que grande parte das aplicaes microcontroladas podem ser implementadas em um nico fluxo de execuo, minimizando custos de projeto e hardware;

o comportamento da aplicao modelado a partir do mtodo initSystem, sendo os mtodos main e o construtor utilizados para efeito de inicializao de outros componentes do sistema.

O modelo de simulao do ambiente pode conter todo o comportamento do sistema, incluindo a comunicao atravs de portas de E/S, temporizadores e tratamento de interrupo, encapsulados em classes disponveis no ambiente. No necessrio que o projetista tenha conhecimento da estrutura e do cdigo de programao desses mecanismos para construir o cdigo de interface entre a aplicao e o restante do sistema.

Os principais componentes da biblioteca SASHIMI so as interfaces IntrInterface, TimerInterface e IOInterface, que especificam a estrutura do modelo de simulao quanto utilizao do sistema de interrupo, temporizao e E/S, respectivamente. Existem, ainda, classes auxiliares como FemtoJava, FemtoJavaIO, FemtoJavaTimer e

38

FemtoJavaInterruptSystem, que devem ser utilizadas para a programao e controle do comportamento do sistema a ser modelado. Informaes mais detalhadas sobre a utilizao da ferramenta SASHIMI podem ser encontradas em (ITO, 1999) (ITO, 2000).

3.2.2 Gerao do Microcontrolador

A arquitetura resultante do sistema SASHIMI composta essencialmente por um microcontrolador FemtoJava dedicado aplicao modelada, cuja operao compatvel com a operao da Mquina Virtual Java. Segundo ITO, as informaes extradas na etapa de anlise de cdigo permitem determinar um conjunto de instrues, quantidade de memria de programa e de dados, tamanho da palavra de dados, e demais componentes adequados aos requisitos da aplicao alvo. O modelo do microcontrolador resultante descrito em linguagem VHDL, podendo ser sintetizvel posteriormente por ferramentas externas.

A principal adaptao arquitetural do FemtoJava realizada pela ferramenta SASHIMI consiste em minimizar o nmero de instrues suportadas, de acordo com as necessidades da aplicao do usurio. Assim, apenas o subconjunto de instrues contidas na aplicao disponibilizado pela arquitetura. Um menor nmero de instrues suportadas pela arquitetura permite uma economia significativa de recursos em termos de clulas lgicas ocupadas no dispositivo FPGA.

3.3 Resumo

Este captulo apresentou um ambiente integrado para desenvolvimento de sistemas embarcados formado por uma ferramenta para descrio e programao da aplicao do usurio, o SASHIMI, agregado a arquitetura na qual essa aplicao ir ser executada, o FemtoJava.

Como pode ser constatado, essa metodologia de projeto consiste em uma maneira rpida e fcil de projetar um sistema embarcado. Isso possvel visto que o projetista pode programar seu sistema diretamente em linguagem Java.

Contudo, apesar de toda a facilidade oferecida pelo ambiente, a limitao de apenas um fluxo de execuo poder ser executado no permite que mais de uma aplicao de usurio seja executada na arquitetura concorrentemente. Em outras palavras, no existe multitarefa na verso Multiciclo do microcontrolador FemtoJava.

39

4 SUPORTE MULTITAREFA PARA A ARQUITETURA: M-FEMTOJAVA

A arquitetura FemtoJava, por ser uma arquitetura relativamente simples, no possui mecanismos para realizao de troca de contexto em hardware. Um dos motivos para isso que esse microcontrolador foi inicialmente concebido visando a aplicao em sistemas embarcados onde apenas um nico fluxo de execuo pudesse ser executado.

Para tornar factvel a execuo de mais de uma aplicao concorrentemente, mecanismos para implementar a troca de contexto precisam ser disponibilizados. Neste sentido, novas instrues de suporte precisam estar disponveis na arquitetura.

Neste captulo discute-se, inicialmente, trs estratgias em relao ao salvamento e restaurao do contexto das tarefas, mecanismo imprescindvel para a incluso do suporte a multitarefa. Em seguida introduz-se a proposta de um novo conjunto de instrues para implementar essa troca de contexto.

4.1 Possveis Variaes de Implementao de Troca de Contexto

Toda vez que uma tarefa removida do processador para que outra possa ser executada, informaes suficientes sobre o seu estado corrente de operao devem ser armazenadas. Essas informaes permitem que a tarefa possa prosseguir da mesma posio onde foi interrompida quando esta novamente fizer uso do processador. Esses dados relativos ao estado operacional so conhecidos como contexto da tarefa e o ato de remover a tarefa da CPU, alocando outra para ser executada, conhecido como chaveamento de tarefa ou chaveamento de contexto (TANENBAUM, 2003).

A estratgia para manipulao de contexto dentro de uma arquitetura de fundamental importncia para o desempenho em termos de processamento. Isso se deve a relao entre o tempo gasto pelo microcontrolador para a realizao da troca de contexto com a quantidade de informao que precisa ser manipulada. A figura 4.1 ilustra a troca de contexto entre duas tarefas.

40

Figura 4.1: Troca de Contexto entre Duas Tarefas

Basicamente, os registradores da arquitetura FemtoJava que precisam ter seus contedos armazenados e restaurados a cada troca de contexto so os registradores A, B, VARS, FRM, PC e SP. Os registradores MAR, IR e IMMED no precisam ser salvos. Estes ltimos so registradores auxiliares para a execuo de uma instruo da arquitetura. As informaes contidas neles so relevantes somente no instante em que a instruo executada. O contedo deles no precisa ser salvo, pois a cada nova instruo apontada pelo registrador PC, os valores desses registradores so devidamente modificados de acordo com a necessidade.

Trs estratgias foram investigadas e, por final, optou-se pela estratgia que apresentava o menor custo em termos de manipulao de informaes de registradores para a realizao da troca de contexto. Essas estratgias so apresentadas a seguir.

4.1.1 Primeira Estratgia de Implementao

A figura 4.2 apresenta uma proposta de estratgia para a implementao da troca de contexto na arquitetura FemtoJava. Nessa estratgia todo o contexto de execuo da tarefa (registradores A, B, VARS, FRM, PC e SP) salvo em uma rea de memria RAM especfica para esse fim. Dessa forma, considerando a existncia de duas tarefas no sistema, seriam necessrias duas pilhas de execuo distintas, uma para cada tarefa, bem como duas reas de memria com os seis registradores salvos para cada tarefa.

41

Figura 4.2: Primeira Estratgia de Salvamento de Contexto

Inicialmente essa estratgia demonstrou-se interessante, porm, com a anlise mais detalhada das operaes envolvidas em uma operao de troca de contexto verificou-se uma desvantagem nesta implementao: a quantidade de escritas e leituras na memria RAM para salvamento e restaurao do contexto seria relativamente significativa.

4.1.2 Segunda Estratgia de Implementao

Uma segunda estratgia investigada foi a possibilidade de salvar a pilha de execuo inteira da tarefa, juntamente com o contexto de execuo. Nessa estratgia, toda a pilha de execuo da tarefa, contendo os dados de execuo da tarefa, bem como os registradores envolvidos na operao, deveriam ser salvos em uma posio de memria reservada. A figura 4.3 ilustra essa estratgia.

Nessa segunda abordagem notou-se, tambm, um aumento significativo em termos de quantidade de operaes de leitura e escrita em memria RAM, bem como no nmero de ciclos necessrios para a realizao da troca de contexto. Quanto maior fosse a pilha da tarefa, maior seria a sobrecarga para guardar as informaes dessa tarefa.

Outro ponto importante a ser citado que existiria um custo adicional para o controle do crescimento do tamanho da pilha, no sendo essa, portanto, a melhor soluo a ser adotada.

42

Figura 4.3: Segunda Estratgia de Salvamento de Contexto

Embora essa estratgia aparente uma boa alternativa para garantir a integridade dos dados, visto que toda a pilha e todo o contexto estariam guardados em um local reservado de memria para este fim, na prtica essa no seria a melhor alternativa em termos de desempenho e consumo de energia. O tempo de processamento e o nmero de ciclos necessrios para salvar e restaurar as informaes seria bem maior se comprado com a primeira estratgia apresentada.

4.1.3 Terceira Estratgia de Implementao

Uma terceira estratgia consiste em salvar apenas os SPs das tarefas. Essa estratgia faz uso da caracterstica da arquitetura FemtoJava de realizar o salvamento automtico dos registradores A, B, VARS, FRM e PC toda vez que uma interrupo do timer acontece ou quando um mtodo invocado. Assim, explorando essa propriedade da arquitetura de pilha, a quantidade de escritas e leituras em memria RAM pode ser reduzida, sendo necessrio, apenas, salvar e restaurar os valores dos SPs das tarefas envolvidas no escalonamento corrente. A figura 4.4 apresenta essa terceira abordagem.

43

Figura 4.4: Terceira Estratgia de Salvamento de Contexto

De fato, as pilhas referentes a cada um das tarefas envolvidas na execuo existem e os valores dos registradores so salvos, assim como nas outras estratgias mencionadas anteriormente. Porm, nessa estratgia, a rea de memria necessria para salvar o restante do contexto de execuo menor do que as duas outras abordagens, visto que somente os SPs so salvos fora da pilha. Os outros valores necessrios para a troca de contexto ficam armazenados na prpria pilha da tarefa. No necessrio que sejam guardados em uma tabela de tarefas, por exemplo. Assim, conclui-se que a terceira estratgia a melhor opo por apresentar o menor custo em relao a rea de memria e ao nmero de ciclos de execuo necessrios para o salvamento de contexto.

4.2 Novas Instrues Estendidas

Novas instrues estendidas foram criadas e adicionadas ao cdigo VHDL da arquitetura para oferecer suporte tarefa de troca de contexto e implementao de escalonadores.

Um detalhe importante sobre a disponibilizao e utilizao das novas instrues estendidas precisa ficar claro nesse momento. Das seis novas instrues desenvolvidas, duas delas, referentes ao salvamento e a restaurao do registrador SP, so fundamentais para a implementao dos escalonadores. Sem esse suporte mnimo no seria possvel

44

realizar a troca de contexto na arquitetura. Isso se deve ao fato que a arquitetura no oferece nenhum mecanismo de acesso direto para a manipulao de valores dos registradores.

As outras quatro instrues foram criadas visando minimizar o nmero de ciclos envolvidos na tarefa de escalonamento. Alm disso, essas instrues permitem a implementao de escalonadores diretamente em bytecode Java, o que contribui para a otimizao do cdigo de execuo dos escalonadores. Contudo, cabe ressaltar que possvel implementar o cdigo dos escalonadores diretamente em Java utilizando os recursos originalmente previstos na arquitetura mais as duas instrues estendidas de troca de contexto.

A seguir, as seis instrues estendidas que foram desenvolvidas nesse trabalho so apresentadas.

4.2.1 Instruo SAVE_CTX

O primeiro bytecode concebido, chamado de SAVE_CTX, tem por funo realizar o salvamento do SP da tarefa corrente antes da mesma perder acesso CPU e ser colocada na fila de espera. A figura 4.5 mostra essa nova instruo. Os valores seguintes ao bytecode da instruo referem-se a posio de memria RAM onde dever ser armazenado o valor de SP. Note que essa posio de memria RAM tambm utilizada pela instruo REST_CTX, apresentada a seguir, visto que para uma mesma tarefa a posio de memria onde o valor de SP salvo e restaurado a mesma.

Figura 4.5: Instruo Estendida SAVE_CTX

4.2.2 Instruo REST_CTX

A instruo REST_CTX responsvel pela restaurao do contexto. Ela tem por finalidade restaurar o SP da tarefa escalonada, permitindo, assim, que o processador possa, na seqncia, restaurar o restante do contexto de execuo na pilha especfica daquela

45

tarefa. Essa instruo faz o acesso s posies de memria reservadas do sistema, onde as informaes sobre as tarefas esto armazenadas. Somente aps a restaurao do contexto a tarefa escalonada poder ganhar o processador para ser executada.

A figura 4.6 apresenta a instruo. Os valores seguintes ao bytecode da instruo referem-se a posio de memria RAM onde armazenado o valor de SP a ser restaurado.

Figura 4.6: Instruo Estendida REST_CTX

4.2.3 Instruo INIT_VAL

A terceira instruo estendida que foi implementada chama-se INIT_VAL. Ela tem por funo permitir que um valor seja escrito em uma determinada posio de memria RAM. Tanto o valor que se deseja escrever, bem como o endereo de memria RAM onde o dado ser armazenado, so informaes que podem ser configuradas pelo programador, pois so dados imediatos na instruo. Um endereo de memria ROM ou o valor de um registrador interno so exemplos de informaes que podem ser escritas por essa instruo.

Figura 4.7: Instruo Estendida INIT_VAL

A figura 4.7 mostra as instrues que compem esse bytecode estendido e a forma como ele empregado dentro da memria de programa. Os dois primeiros valores

46

subseqentes ao bytecode da instruo indicam o endereo na memria RAM onde ser armazenada a informao, passada pelos dois ltimos valores da instruo.

4.2.4 Instruo INIT_STK

A quarta instruo estendida, chamada de INIT_STK, responsvel pela inicializao das pilhas para as tarefas. Essa instruo, portanto, permite a criao de todas as pilhas na memria RAM, de acordo com a configurao passada pelo programador.

Figura 4.8: Instruo Estendida INIT_STK

A figura 4.8 mostra as instrues desse novo bytecode, bem como a forma na qual ele utilizado dentro do cdigo de programa do escalonador. importante notar que nessa instruo, o valor do PC, informado pelos dois ltimos valores subseqentes ao bytecode da mesma, salvo na posio de memria fornecida pelos primeiros valores subseqentes instruo diminuda de duas unidades. Isso ocorre devido a propriedade do FemtoJava de salvar os registradores, sempre que ocorre uma interrupo, na seguinte ordem: B, A, PC, FRM, VARS. Devido a essa caracterstica, o PC necessita ser salvo no no topo da pilha, mas sim na posio topo da pilha 2.

4.2.5 Instruo SCHED_THR

A instruo nomeada de SCHED_THR foi desenvolvida tendo como principal objetivo realizar o trabalho de testar e escolher qual rotina de tratamento dever ser executada dentro do cdigo dos escalonadores implementados.

A figura 4.9 mostra as instrues dessa nova instruo. Nela, os dois valores imediatamente seguintes ao bytecode, XXXX, determinam a posio da memria ROM onde um valor a ser testado ser lido. O terceiro valor imediato ao bytecode, YY, determina o tamanho do salto de desvio dentro do cdigo do escalonador.

47

Dessa forma, se o valor testado for zero, a instruo desvia o PC para a rotina de tratamento informada pelo ltimo valor imediato da instruo, YY. Caso contrrio, o PC continua a ser incrementado normalmente, sem a realizao do salto de desvio no cdigo.

Figura 4.9: Instruo Estendida SCHED_THR

4.2.6 Instruo GET_PC

Por fim, a ltima instruo desenvolvida, GET_PC, tem a funo de restaurar o registrador PC com o valor contido na posio de memria informada pelos dois imediatos seguintes ao bytecode. A figura 4.10 ilustra essa instruo. Em outras palavras, o registrador PC ir receber o contedo armazenado no endereo de memria XXXX.

Figura 4.10: Instruo Estendida GET_PC

4.2.7 Consideraes Gerais Sobre as Instrues Desenvolvidas

Um cuidado tomado durante o desenvolvimento das novas instrues para a arquitetura foi o de implement-las da maneira mais otimizada possvel, executando o mnimo de instrues necessrias. Esse cuidado teve por objetivo minimizar o excesso de ciclos de processamento dessas instrues, para que o impacto da troca de contexto e

48

seleo de uma tarefa a executar (escalonamento) fosse o menor possvel. Assim, foi possvel chegar a um nmero bastante satisfatrio de instrues por instruo criada. A tabela 4.1 apresenta esses valores.

Tabela 4.1: Nmero de instrues de Cada Nova Instruo Estendida

Nova Instruo N instrues INIT_VAL 9 INIT_STK 9 REST_CTX 11 SAVE_CTX 7 SCHED_THR 12 GET_PC 7

A tabela 4.2 apresenta os bytecodes das instrues implementadas e o significado de operao de cada uma delas.

Tabela 4.2: Bytecodes e Significados das Novas Instrues

Instruo Bytecode Exemplo Significado INIT_VAL f4 f4 $s1,$s2 Mem[$s2] $s1 INIT_STK f5 f5 $s1,$s2 Mem[$s2] $s1 - 2 REST_CTX f6 f6 $s1 SP Mem[$s1] SAVE_CTX f7 f7 $s1 Mem[$s1] SP SCHED_THR f8 f8 $s1,$s2 if (Mem[$s1]=0) PC PC + $s2 ;

else PC++ GET_PC fa fa $s1 PC Mem[$s1]

Tendo o conhecimento das operaes efetuadas pelas novas instrues, torna-se possvel realizar uma rpida comparao entre uma operao executada por uma nova instruo da arquitetura e a mesma operao executada por um conjunto de instrues j existentes. Tomando-se, por exemplo, a situao em que se deseja armazenar em uma determinada posio de memria um valor contido no topo da pilha da arquitetura. Na arquitetura original do FemtoJava seriam necessrios doze ciclos de execuo, referentes a execuo das instrues da tabela 4.3, ao passo que, utilizando-se a instruo INIT_VAL, a mesma operao poderia ser realizada em apenas nove ciclos.

49

Tabela 4.3: Exemplo de Operao de Gravao de Valores em uma Posio de Memria

Instruo N instruo BIPUSH 3 BIPUSH 3 STORE_IDX 6

4.3 Resumo

Para que fosse possvel implementar multitarefa sobre a arquitetura FemtoJava foi necessrio investigar algumas alternativas para a realizao da troca de contexto. Trs estratgias foram analisadas.

A estratgia escolhida consiste em salvar apenas os registradores SPs referentes execuo das tarefas, visto que a arquitetura FemtoJava empilha os demais registradores relevantes toda a vez que uma interrupo acontece. Essa escolha teve por objetivo minimizar o impacto que a troca de contexto traz ao sistema embarcado, visto que, na execuo dos escalonadores, a troca de contexto realizada vrias vezes para permitir a execuo das n tarefas envolvidas.

O suporte de hardware desenvolvido para a implementao de troca de contexto na arquitetura FemtoJava tambm foi apresentado. Alm das duas instrues fundam