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: Prof
a
. Wrana Panizzi
Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann
Pr-Reitora Adjunta de Ps-Graduao: Prof
a
. 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 fundamentais
para a realizao da troca de contexto, quatro outras instrues foram disponibilizadas
visando facilitar a programao dos escalonadores diretamente em bytecodes Java.
A arquitetura modificada recebeu a denominao M-FemtoJava. Esse codinome
foi atribudo devido ao fato da incluso das novas instrues permitirem suporte a
multitarefa sobre a arquitetura.


50
5 ASPECTOS DE IMPLEMENTAO EM SOFTWARE
Como descrito anteriormente, as rotinas relacionadas com a troca de contexto do
processador no podem ser implementadas diretamente em linguagem Java, basicamente
porque o ambiente SASHIMI no prove meios de manipular os valores dos registradores da
arquitetura FemtoJava.
Por outro lado, a poltica de escalonamento propriamente dita pode ser
implementada em linguagem de alto nvel, sem problema algum, deixando somente as
chamadas de troca de contexto programadas em baixo nvel. Contudo, no intuito de
otimizar o cdigo de execuo dos escalonadores, se props realizar toda a implementao
diretamente em bytecodes Java.
As sees seguintes apresentam as estruturas e os detalhes dos escalonadores
implementados. Tambm so apresentadas as modificaes realizadas na ferramenta
SASHIMI e a implementao de uma ferramenta de relocao de endereos necessria para
ajustar o cdigo dos escalonadores.

5.1 Implementao dos Escalonadores
De acordo com os captulos anteriores, sabe-se que na presena de vrias tarefas
em um sistema computacional torna-se necessrio a presena de um escalonador para
permitir a escolha de qual tarefa ser executada. Contudo, alm da escolha da poltica de
escalonamento que ser implementada no sistema, preciso definir alguns critrios para o
desenvolvimento dos escalonadores. Estes critrios esto relacionados com a forma que os
escalonadores apresentam-se na arquitetura, independentemente da poltica escolhida.

5.1.1 Polticas de Escalonamento
Muitas so as polticas de escalonamento existentes. Porm a escolha de que
polticas seriam efetivamente implementadas dependem do suporte fornecido pelo
microcontrolador em hardware. Inicialmente, foram consideradas quatro polticas para
51
serem implementadas: FIFO, Round-Robin, FIFO com prioridade e Round-Robin com
prioridade. Esta escolha se devia ao fato que estas polticas so bastante conhecidas e
tradicionalmente utilizadas por sistemas operacionais de tempo real e embarcados. Uma
segunda razo para esta escolha, que as polticas FIFO e Round-Robin so recomendadas
pela norma POSIX para sistemas operacionais.
A poltica de escalonamento FIFO caracteriza-se como uma fila onde as tarefas
so executadas na ordem de chegada. Portanto, a primeira tarefa da fila ser a primeira
tarefa a ser executada pelo sistema. Nesse algoritmo, uma tarefa somente libera o
processador quando realiza uma chamada de sistema bloqueante, quando libera
voluntariamente o processador, quando ocorre algum erro de execuo, ou quando ela
termina sua execuo. Ele um algoritmo no-preemptivo.
A poltica Round-Robin uma abordagem preemptiva de revezamento. Nessa
tcnica cada tarefa recebe uma fatia de tempo do processador conhecida como quantum,
onde um relgio em hardware delimita os quanta do sistema atravs da gerao de
interrupes. Uma tarefa ocupa o processador at executar uma chamada de sistema
bloqueante, liberar voluntariamente o processador, terminar sua execuo ou esgotar a sua
fatia de tempo.
Essas duas polticas oferecem diferentes comportamentos em relao as mtricas
normalmente utilizadas para avaliar o desempenho de escalonadores. Portanto, a escolha e a
utilizao de uma delas depende da aplicao do usurio. Como no se sabe o perfil da
aplicao do usurio, essas duas polticas foram implementadas para a arquitetura M-
FemtoJava, permitindo que o usurio escolha qual melhor se aplica a sua necessidade.
Uma forma alternativa de utilizar preempo atravs da definio de prioridades.
Nesse caso, as tarefas recebem uma ordem de execuo em funo de sua importncia.
Enquanto uma tarefa de prioridade mais alta estiver em condio de executar, ela passar a
ocupar o processador. As prioridades auxiliam na sobreposio de operaes de E/S com
processamento. Nesse caso, pode-se imaginar que enquanto uma tarefa de prioridade maior
espera pela execuo de uma operao de E/S, uma de menor prioridade assume a CPU.
Assim que a operao de E/S concluda, a tarefa de maior prioridade preempta a de menor
prioridade. Diz-se nessa situao que a tarefa de maior prioridade est bloqueada a espera
da ocorrncia de um evento de E/S.
Porm, considerando o suporte de hardware fornecido pelo M-FemtoJava, a
implementao das polticas com prioridade deixou de fazer sentido. Isso se deve ao fato
que o mecanismo de E/S da arquitetura baseado em polling, ou seja, no bloqueante. Essa
caracterstica implica que nenhuma tarefa fica bloqueada esperando pela ocorrncia de
eventos de E/S. Uma outra razo para a no implementao de algoritmos com prioridade
que no existe criao dinmica de tarefas no sistema, o que elimina a possibilidade de uma
tarefa em execuo criar outra tarefa de maior prioridade. Outro ponto em que a preempo
52
se justifica na presena de primitivas de sincronizao entre tarefas, onde uma tarefa de
maior prioridade pode ficar bloqueada a espera da liberao de um recurso do sistema. A
ausncia de primitivas bloqueantes no M-FemtoJava, tanto para E/S como para
sincronizao, faz com que polticas de escalonamento baseadas em prioridades no se
justifiquem na prtica.

5.1.2 Regras Gerais Definidas para a Implementao de Multitarefa na Arquitetura
Algumas regras foram adotadas para permitir que duas ou mais tarefas pudessem
ser executadas dentro da mesma memria de programa e de dados da arquitetura.
Obedecendo-se essas regras durante a implementao dos escalonadores consegue-se,
ento, oferecer uma certa garantia para a integridade das informaes das aplicaes de
usurio. Essas regras so descritas a seguir:

Cada tarefa envolvida deve possuir sua prpria pilha de execuo;
Cada SP relativo ao topo da pilha de cada tarefa deve ser salvo em um local de
memria especfico, garantindo, assim, que os valores dos registradores salvos
possam ser restaurados quando a aplicao de usurio for escalonada para
tomar posse do processador;
As pilhas de execuo das diversas tarefas devem possuir um tamanho
razoavelmente significativo, permitindo que dados no sejam perdidos pela
sobreposio de informaes;
O local na memria de dados onde os SPs das diversas pilhas existentes sero
salvos deve localizar-se em uma posio que no seja alcanada pelas
variveis globais e nem pelo crescimento abrupto da pilha de alguma outra
aplicao.

importante notar que na prtica, a soluo adotada para a implementao no
garante proteo real de memria. Caso ocorra um crescimento abrupto da pilha de alguma
aplicao concorrente, essa poder sobrepor as informaes da pilha de outra. Para permitir
uma garantia real da integridade dos dados, impossibilitando que pilhas crescessem sem
controle e invadissem a rea de memria de outras, seria necessrio um maior suporte do
hardware, como, por exemplo, registradores de base e limite para proteo de memria.

5.1.3 Estrutura dos Escalonadores para o M-FemtoJava
Como visto no captulo 3, a memria de programa do microcontrolador FemtoJava
possui um intervalo de endereos reservados para o tratamento de interrupes. Esse
53
intervalo vai desde o endereo 00H at o endereo 2BH. A partir da posio 2BH, o
restante da memria est disponvel para a aplicao do usurio. Na prtica, o cdigo da
aplicao do usurio, programado no ambiente SASHIMI, ser sintetizado na memria de
programa da arquitetura a partir do endereo 2BH, podendo chegar at o limite mximo
de 64K bytes na verso 16 bits do microcontrolador.
Para a implementao dos escalonadores, essa estrutura nativa da memria de
programa foi preservada. Como pode ser visto na figura 5.1, o cdigo do escalonador
implementado a partir do endereo 2BH, indo at um endereo de memria dependente
do tamanho do cdigo do escalonador implementado.
A partir do endereo final do cdigo do escalonador, as aplicaes do usurio
podem ser implementadas at a capacidade mxima da memria. Optou-se em utilizar essa
estrutura de organizao dentro da memria devido a necessidade do cdigo do escalonador
ser executado antes de qualquer outra aplicao para realizar a inicializao das pilhas das
diversas aplicaes de usurios contidas no sistema.


Figura 5.1: Nova Estrutura da Memria de Programa do FemtoJava

Na figura 5.1 tambm se nota a presena de um pequeno cdigo entre cada tarefa
descrita na memria de programa. Esse cdigo tem por finalidade informar ao sistema que
a tarefa terminou sua execuo, no precisando mais ser escalonada. Esse cdigo
introduzido automaticamente pela ferramenta de ligao que ser apresentada mais tarde.
Basicamente o cdigo dos escalonadores implementados pode ser dividido em dois
grandes mdulos. A figura 5.2 apresenta a diviso desses dentro da memria ROM da
arquitetura.
54
No primeiro mdulo esto localizadas as rotinas de inicializao do sistema que
definem as pilhas de cada tarefa e identificam as tarefas a serem escalonadas. Tambm,
caso o escalonador necessite utilizar o relgio do sistema para gerar interrupes, nesse
trecho de cdigo que esse procedimento programado. Esse primeiro mdulo executado
apenas uma nica vez pelo sistema, quando esse inicializado.
O segundo mdulo que compe o escalonador apresenta o cdigo responsvel
pelas decises de escalonamento e pelas rotinas de tratamento para salvamento e
restaurao de contexto. Portanto, esse trecho de cdigo executado todas as vezes que o
escalonador acionado.


Figura 5.2: Mdulos dos Escalonadores

55

Figura 5.3: Nova Estrutura da Memria de Dados do FemtoJava

A memria de dados original da arquitetura FemtoJava, por sua vez, tambm
possui um intervalo de endereo reservado as rotinas de tratamento do microcontrolador.
Esse intervalo inicia na posio 00H e vai at o endereo 10H. Aps esse intervalo a
memria de dados pode ser utilizada para as aplicaes do usurio, sendo que as variveis
globais so alocadas a partir do endereo 10H. A pilha da tarefa, por sua vez, inicia na
ltima posio de memria, podendo crescer de acordo com a necessidade.
Para que a implementao dos escalonadores fosse possvel, tornou-se necessrio
realizar um particionamento na memria de dados, e reservar, tambm, uma rea especfica
para armazenar as informaes referentes a execuo das tarefas pelo escalonador.
Basicamente, essas informaes so valores que compem a tabela de tarefas no sistema,
como ser visto na seo 5.1.4.
Como apresentado na figura 5.3, definiu-se, inicialmente, o intervalo de endereos
a partir da posio F1H at 12FH como rea reservada para as informaes do
escalonador. Esse intervalo no rigoroso, podendo ser alterado pelo programador de
acordo com a necessidade. Como o microcontrolador no dispe de um mecanismo de
proteo de memria, a utilizao desse intervalo de endereos para guardar as informaes
dos escalonadores fornece uma certa garantia de que a tabela de tarefas no ser sobrescrita
pelas variveis globais do sistema e nem pelo crescimento abrupto da pilha de alguma
tarefa. Ainda assim, caso esse intervalo de memria no seja adequado, o programador tem
a liberdade de mover esse intervalo para posies de memria que possibilitem a execuo
correta do escalonador. Essa alterao realizada no trecho de cdigo de inicializao dos
56
escalonadores na memria ROM, onde os endereos reservados para a tabela de tarefas so
programados.
A pilha do FemtoJava, por sua vez, precisa ser dividida. Essa diviso se faz
necessrio visto que cada tarefa deve ter sua prpria pilha de execuo. Como pode ser
visto na figura 5.3, pode-se utilizar o intervalo que vai da posio 130H at o endereo de
memria FFFFH para as pilhas das tarefas. Essas pilhas, por sua vez, podem apresentar
um tamanho configurvel de memria, cabendo ao programador determinar o tamanho das
mesmas. Portanto, o tamanho de cada pilha de tarefas envolvidas pode ser configurado de
acordo com a necessidade, ou utilizando-se o principio de diviso igualitria.
Essa liberdade de manipular o tamanho da pilha das tarefas, bem como a
facilidade de mover a rea de memria de dados reservada para o escalonador para um
outro intervalo de memria mais adequado, torna-se factvel graas ao cdigo configurvel
dos escalonadores desenvolvidos.

5.1.4 Tabela de Tarefas
Dentro da rea de memria de dados reservada para o escalonador localiza-se a
tabela de tarefas. Nessa tabela de tarefas ficam guardadas quase todas as informaes
relevantes para a execuo das tarefas. Apenas os valores dos registradores A, B, PC,
VARS e FRM do M-FemtoJava no ficam armazenados dentro dela, visto que eles so
armazenados na prpria pilha da tarefa, antes de perderem o processador durante a troca de
contexto. Da mesma forma, esses registradores so restaurados da prpria pilha da tarefa
toda vez que essa escalonada para ganhar o processador.
Na tabela de tarefas, as informaes armazenadas, para cada tarefa, so as
seguintes:

SP da tarefa;
Estado da tarefa;
Informao para salvamento de contexto.

O primeiro campo da tabela armazena o SP da tarefa. Esse dado necessrio para
que o registrador SP do microcontrolador M-FemtoJava possa apontar para a pilha correta
da tarefa, permitindo que os outros valores dos registradores sejam restaurados
corretamente, e que a pilha correta seja utilizada.
O campo estado da tarefa, como o prprio nome diz, informa o estado da tarefa ao
sistema. Um valor zero indica que a tarefa terminou sua execuo. Qualquer outro valor
informa ao escalonador que a tarefa est apta a executar.
57
Por ltimo, a informao para salvamento de contexto permite ao escalonador
saber em qual posio da tabela de tarefas o registrador SP da tarefa corrente dever ser
salvo. O valor zero indica a posio correta.
A figura 5.4 apresenta a tabela de tarefas, para os escalonadores da arquitetura.
possvel verificar que os endereos utilizados para os campos da tabela de tarefas
encontram-se dentro do espao de memria RAM reservado para o escalonador, iniciando
em F1H e terminando em 12FH.


Figura 5.4: Tabela de Processos para Escalonadores no M-FemtoJava

5.1.5 Interrupo por Hardware e Chamada para a Rotina de Escalonamento
Para que o escalonador Round-Robin pudesse ser implementado, decidiu-se
utilizar um dos temporizadores da arquitetura para gerar uma interrupo de hardware
peridica, fazendo com que o escalonador pudesse preemptar, e assim assumir o controle
do processador. Esse temporizador da arquitetura, chamado de timer 0, configurado
logo no inicio do cdigo do mdulo de inicializao do escalonador, juntamente com a
habilitao da interrupo. Dessa forma, sempre que o nmero de ciclos programado for
atingido, a tarefa corrente preemptada, deixando a CPU para uso do cdigo do
escalonador. A figura 5.5 apresenta esse trecho de cdigo.
Para garantir que o escalonador no seja interrompido por uma outra tarefa, a
primeira operao realizada, quando esse recebe o processador, a desabilitao do sistema
58
de interrupes. Dessa forma, garante-se que o cdigo do escalonador no sofrer
intervenes at que sua execuo termine. Aps a deciso de qual tarefa dever ganhar a
CPU, novamente o sistema de interrupo habilitado e o processador entregue a tarefa
escalonada.
Na prtica, essa soluo eficiente para o funcionamento dos escalonadores,
porm, ela adiciona uma restrio ao cdigo da aplicao do usurio. necessrio que o
programador no utilize o timer 0 em suas aplicaes, sob pena do no funcionamento
correto das mesmas, visto que a rea reservada para o tratamento de interrupes do timer
0 utilizado para a chamada do cdigo do escalonador. Contudo, isso no inviabiliza a
utilizao do sistema de temporizao, visto que a arquitetura possui um outro
temporizador que poder ser utilizado para a aplicao.


Figura 5.5: Habilitao do Sistema Temporizador para Escalonador R.R.

Para a outra poltica implementada, FIFO, o escalonador s acionado para
decidir qual tarefa tomar posse da CPU quando a tarefa corrente terminar sua execuo.
Porm, por uma questo de praticidade, o cdigo para a chamada dos escalonadores fica
localizado na rea reservada para o tratamento de interrupes do timer 0. Dessa forma, a
utilizao do timer 0 deve ser evitada.

5.2 As Modificaes na Ferramenta SASHIMI
Para tornar vivel a utilizao dos escalonadores desenvolvidos diretamente em
bytecodes Java, decidiu-se incorpor-los de alguma forma ferramenta SASHIMI,
possibilitando, assim, que o usurio pudesse programar em alto nvel suas aplicaes e
59
utilizar os escalonadores previamente implementados, sem precisar saber detalhes internos
do funcionamento dos cdigos dos mesmos. Partindo dessa idia, fez-se uso de algumas
caractersticas da ferramenta SASHIMI para a gerao dos cdigos, tornando factvel a
total programao do sistema e a utilizao de um escalonador dentro da ferramenta.
A primeira modificao realizada no SASHIMI foi a incluso das novas instrues
dedicadas aos escalonadores. Essa pequena alterao teve como objetivo tornar possvel a
manipulao do cdigo dos escalonadores pela ferramenta.
Posteriormente, criou-se uma classe chamada Scheduler.Java, a qual formada
por trs mtodos referentes a utilizao dos escalonadores. Essa classe apresentada na
figura 5.6.
Os dois primeiros mtodos esto relacionados com os dois escalonadores
implementados. O ltimo mtodo se refere ao trecho de cdigo do escalonador necessrio
ao trmino da execuo de uma aplicao de usurio, para informar ao escalonador que
essa tarefa no precisa mais disputar a CPU. Em outras palavras, ele informa ao
escalonador que a tarefa terminou, removendo a mesma da fila de tarefas aptas.


Figura 5.6: Classe Scheduler.Java

Uma vez implementada a classe Scheduler.Java, atravs da facilidade de
substituio de mtodos oferecidos pela ferramenta SASHIMI tornou-se possvel incluir o
cdigo dos escalonadores desenvolvidos diretamente em bytecodes Java no cdigo final das
aplicaes do usurio. Essa incluso feita na etapa de gerao dos bytecodes das
aplicaes do usurio.




60
5.2.1 As Novas Regras de Modelagem
Para que os escalonadores desenvolvidos possam ser utilizados junto as aplicaes
de usurio algumas regras de modelagem precisam ser obedecidas. A figura 5.7 apresenta o
cdigo Java com um exemplo de utilizao de duas aplicaes e um escalonador.


Figura 5.7: Novas Regras de Modelagem no Ambiente SASHIMI

Todas as regras de modelagem j existentes no ambiente continuam vlidas. Alm
dessas, para a incluso dos escalonadores, necessrio incluir as chamada referentes a
utilizao dos mesmo dentro do mtodo initSystem().
Para tanto, como exemplificado na figura 5.7, deve-se sempre:

i) no mtodo initSystem() chamar primeiramente o mtodo do escalonador
escolhido para utilizao (linha 9). Isso necessrio visto que o escalonador
precisa ser executado antes de qualquer aplicao de usurio para poder inicializar
o sistema e, assim, gerenciar a execuo do mesmo;
61
ii) chamar os mtodos das aplicaes de usurio intercalados com os mtodos
endOfProcess() (linhas 11 e 13), tantas vezes quanto necessrio.

Incluindo-se a classe Scheduler.Java no mesmo diretrio das aplicaes do
usurio e obedecendo as regras de modelagem, a ferramenta SASHIMI ir gerar o cdigo
Java com os bytecodes do escalonador e das aplicaes.

5.3 Relocador de Endereos
Sabe-se que as linguagens de alto nvel surgiram, inicialmente, para facilitar a
programao de cdigos cada vez mais elaborados e complexos. Porm, quando se deseja
obter cdigos extremamente eficientes, vrios programadores utilizam a linguagem de
montagem como linguagem de programao (AHO, 1995). Geralmente esses cdigos so
pequenas rotinas do sistema, ou ento trechos crticos de cdigo, os quais so executados
vrias vezes durante a operao do mesmo.
Como visto nas sees anteriores, os escalonadores foram implementados
diretamente em bytecode Java. Essa caracterstica tornou-os mais eficientes em termos de
cdigo de execuo. Porm, essa caracterstica tornou, tambm, extremamente trabalhosa a
tarefa de ajuste dos mesmos de acordo com a necessidade, devido quantidade de
endereos e rotinas de tratamento contidas neles. A complexidade de ajuste de endereos,
por exemplo, cresce com o aumento do nmero de tarefas de usurios que estaro
envolvidos no sistema, visto que esses devero ser resolvidos em tempo de projeto e
embarcados na memria ROM do microcontrolador para poderem ser executados
posteriormente.
Seguindo a premissa de facilitar a programao de um sistema embarcado, alm
das modificaes realizadas na ferramenta SASHIMI, decidiu-se, tambm, implementar
uma ferramenta de ligao e ajuste de cdigo capaz de resolver todas as configuraes
necessrias no cdigo do escalonador, de acordo com o tamanho e o nmero de tarefas
envolvidas. Dessa forma, no se torna necessrio ao programador do sistema embarcado
ajustar detalhes finais no cdigo dos escalonadores manualmente, detalhes esses que no
so manipulados pela ferramenta SASHIMI, visto que a ferramenta de auxlio capaz de
realizar todos esses ajustes automaticamente.
importante esclarecer que os endereos absolutos e relativos das aplicaes do
usurio estaro resolvidos pela ferramenta SASHIMI. Contudo, a memria de programa
estar parcialmente organizada, visto que os valores de inicializao de pilhas, quantum, e
demais informaes necessrias ao escalonador no estaro ajustados.
62
A figura 5.8 mostra o fluxo de projeto e utilizao da mesma. Como pode ser
visto, a ferramenta tem como entrada a memria de dados do microcontrolador, fornecida
pela ferramenta SASHIMI. Como sada, a ferramenta gera uma outra memria ROM, com
os endereos de memria devidamente ajustados, podendo esta ser sintetizada juntamente
com a arquitetura em uma ferramenta de sntese externa como, por exemplo, o Max+Plus II
da Altera. A ferramenta garante que todos os endereos de pilha e valores de registradores
sejam inicializados com os valores corretos, para permitir a execuo das aplicaes e o
devido escalonamento.


Figura 5.8: Fluxo de Projeto e Utilizao do Relocador

Como pode ser visto na figura 5.8, a memria ROM de entrada, rom.mif gerada
pelo SASHIMI, manipulada pela ferramenta de ligao, sendo gravada em um arquivo de
sada chamado de rom2.mif ao trmino da execuo.
63
Uma caracterstica da ferramenta que a mesma opera automaticamente aps ser
executada. No necessria nenhuma interferncia por parte do programador, visto que a
mesma capaz de fazer a varredura no cdigo, identificar trechos que precisam ser
ajustados e realizar o ajuste automaticamente. A interao com o programador se d apenas
quando escalonadores Round-Robin so identificados na memria ROM. Nesses casos, a
ferramenta solicita ao programador a informao do quantum desejado para a execuo das
tarefas.

5.4 Resumo
Nesse captulo as implementaes realizadas em software para a disponibilizao
de multitarefa sobre a arquitetura M-FemtoJava foram discutidas.
Inicialmente foram introduzidas algumas regras para a implementao de
multitarefa na arquitetura. Essas regras so referentes a forma como devem ser tratados os
dados e as informaes das tarefas de usurio na memria de dados da arquitetura. Tambm
foram discutidas as estruturas internas dos escalonadores desenvolvidos para o M-
FemtoJava, as modificaes na ferramenta SASHIMI para permitir o projeto do sistema
embarcado utilizando-se os escalonadores desenvolvidos tambm foram descritas e as
novas regras de projeto necessrias para gerao correta do cdigo das aplicaes.
Por ltimo, a ferramenta de ligao desenvolvida para ajustar automaticamente os
cdigos dos escalonadores, resolvendo todos os endereos necessrios referentes a
operao dos escalonadores, foi apresentada.
Como pode ser constatado, mesmo tendo sido desenvolvidos diretamente em
bytecodes Java, os escalonadores podem ser utilizados e agregados ao fluxo de projeto do
Java ao chip de uma maneira simples.
64
6 ANLISE DE RESULTADOS
Como proposta de realizao deste trabalho, desejava-se adicionar multitarefa na
arquitetura FemtoJava e analisar seu impacto, no apenas em termos de rea devido a
disponibilizao do suporte necessrio, mas tambm em termos de consumo de energia e no
desempenho de execuo de tarefas.
Esse captulo apresenta a metodologia empregada para a obteno dos resultados,
bem como a anlise dos mesmos.

6.1 Metodologia
Para analisar o impacto da incluso de multitarefa na arquitetura FemtoJava trs
eixos so considerados: custo em rea, custo em consumo de energia e custo em
desempenho de processamento.
O custo em rea basicamente analisado sob duas ticas diferentes: acrscimo de
rea devido a incluso das instrues desenvolvidas para o suporte a multitarefa e
acrscimo em rea de memrias de dados e de programa em funo da presena do cdigo
dos escalonadores.
Uma maneira de analisar o custo de rea a partir da realizao da sntese do
microcontrolador em um dispositivo FPGA. Atravs da sntese possvel obter o nmero
de clulas lgicas que o microcontrolador ocupa no dispositivo FPGA. Neste caso pode-se
sintetizar o microcontrolador FemtoJava com a incluso das instrues de suporte a
multitarefa e verificar quantas clulas lgicas adicionais elas representam em relao ao
projeto original. Esse aumento do nmero de clulas lgicas reflete o impacto da incluso
de multitarefa na arquitetura, sendo uma boa maneira de apresentar o custo agregado s
modificaes da arquitetura. Para realiza a sntese utiliza-se a ferramenta o Max+Plus II
v.10.2 da Altera Corporation (ALTERA, 2004).
Por outro lado, para analisar o custo em rea devido a incluso dos cdigos dos
escalonadores uma outra abordagem empregada. Visto que os escalonadores de tarefas
foram implementados em software, esses ocupam rea em memria de dados e de
65
programa. Dessa forma torna-se necessrio avaliar a quantidade de bytes de memria
necessria para a utilizao dos mesmos.
Os custos em termos de consumo de energia e desempenho podem ser medidos a
partir da simulao da arquitetura. Atravs de simulao obtem-se os valores para cada
escalonador empregado, podendo-se comparar, posteriormente, com o custo zero. Esse
custo zero, por sua vez, nada mais do que os valores de referncia tambm obtidos por
simulao, porm, sem a utilizao de escalonadores de tarefas. A simulao feita com o
auxilio da ferramenta CACO-PS que consiste em um simulador de cdigo compilado,
baseado na execuo em ciclos de relgio, que calcula a energia consumida em cada
componente arquitetural (registradores, multiplexadores, entre outros), de acordo com a
atividade de chaveamento nas entradas desses componentes. Assim, a partir desses dados,
tendo-se o nmero de portas chaveadas, ele retorna a quantidade de potncia dinmica
dissipada na arquitetura, bem como o nmero de ciclos executados.
As sees seguintes apresentam e discutem os resultados obtidos nos
experimentos.

6.2 Custos em rea
Nessa seo so apresentados os resultados em termos de rea ocupada devido a
adio de suporte a multitarefa e a utilizao dos escalonadores.

6.2.1 Acrscimo Devido a Incluso das Instrues Desenvolvidas
Foi realizada a sntese do microcontrolador FemtoJava atravs da ferramenta
Max+Plus II sobre um dispositivo FPGA FLEX10K modelo EPF10K70RC240-2. Nessa
sntese, todas as 69 instrues disponibilizadas pela arquitetura foram includas.
Posteriormente repetiu-se o experimento para o microcontrolador modificado, o qual era
composto pelas 69 instrues originais mais as 6 novas instrues desenvolvidas nesse
trabalho. Esse experimento tinha por intuito apontar o acrscimo em hardware devido a
incluso das novas instrues de suporte a troca de contexto e ao desenvolvimento dos
escalonadores.
A tabela 6.1 apresenta o custo em rea de hardware obtido, em nmero de clulas
lgicas, quando se fez uso das instrues implementadas.



66
Tabela 6.1: Acrscimo de rea em Hardware para a Implementao das Instrues
Estendidas em um Dispositivo FPGA Altera FLEX10K EPF10K70RC240-2
Escalonadores # de Instrues Adicionais CLs % rea
FemtoJava 0 2.057 100%
M-FemtoJava 6 (f4, f5, f6, f7, f8, fa) 2.173 105.6 %

Como pode ser visto na tabela 6.1, o custo de rea em relao ao nmero de
clulas lgicas para expandir o conjunto de instrues da arquitetura FemtoJava e permitir
suporte a implementao dos escalonadores foi da ordem de 120 clulas lgicas, o que
representa um aumento em torno de 5,6% em relao a arquitetura original.

6.2.2 Acrscimo Devido a Incluso dos Cdigos dos Escalonadores
Com a incluso dos escalonadores no sistema embarcado, um aumento em termos
de rea em memria de dados e de programa tambm adicionado devido ao cdigo dos
mesmos. Nesse sentido, para cada um dos escalonadores, mediu-se a rea ocupada. Esses
valores so apresentados na tabela 6.2.

Tabela 6.2: Custos de rea em Memrias RAM e ROM
Escalonador RAM ROM
FIFO 41 bytes 1.567 bytes
Round-Robin 41 bytes 1.596 bytes

Observa-se um consumo na rea em memria RAM devido a alguns dados e
informaes internas dos escalonadores. Esse custo em memria RAM contabilizado pela
rea reservada para a tabela de tarefas dos escalonadores. Contudo, a rea necessria em
memria ROM maior.
importante notar que estas reas ocupadas, para ambos escalonadores, no se
alteram de acordo com o nmero de tarefas incorporadas no sistema, pois os cdigos dos
escalonadores implementados so estticos e possuem sempre o mesmo tamanho.
O escalonador Round-Robin ocupa poucos bytes a mais se comparado com o
escalonador FIFO. Essa caracterstica se explica devido a incluso do trecho de cdigo que
ativa e desativa o sistema de temporizao da arquitetura, tornando possvel a gerao de
interrupo quando os quanta das tarefas expiram.


67
6.3 Consumo de Energia e Aumento do Nmero de Ciclos de Execuo
Para avaliar o consumo de energia e o aumento do nmero de ciclos de execuo,
devido a incluso de multitarefa na arquitetura, algumas consideraes podem ser feitas.
Primeiramente, pode-se considerar a existncia de n tarefas no sistema sem a
existncia de um escalonador de tarefas para gerenciar a execuo das mesmas. Nesta
hiptese, o tempo total de execuo ser o somatrio do tempo de execuo de cada uma
das tarefas existentes. A figura 6.1 ilustra essa condio.


Figura 6.1: Tempo Total de Execuo de Tarefas

Considerando, agora, a incluso de um escalonador FIFO no sistema embarcado, o
tempo total de execuo passa a ser o somatrio dos tempos de execuo de cada uma das
tarefas existentes e dos tempos de execuo das intervenes do escalonador de tarefas. A
figura 6.2 ilustra essa outra condio.

68

Figura 6.2: Tempo Total de Execuo de Tarefas com o Escalonador FIFO

A partir das situaes apresentadas, duas informaes podem ser obtidas em
relao ao emprego de um escalonador FIFO no sistema. A primeira delas refere-se
proporo de aumento do tempo de execuo. Essa proporo reflete o aumento no nmero
de ciclos de execuo pela execuo do cdigo do escalonador, visto que o tempo de
execuo diretamente proporcional ao aumento do nmero de ciclos. Esse aumento
definido da seguinte forma:

r escalonado sem execuo de total tempo
FIFO r escalonado com execuo de total tempo
proporo aumento = ) (
Alm disso, pode-se, tambm, definir a eficincia do escalonador de tarefas FIFO
como sendo:

r escalonado custo tarefas de nto processame de tempo
tarefas de nto processame de tempo
eficincia
+
=

A eficincia uma informao relacionada a utilizao do escalonador no sistema
em termos do nmero de ciclos que esse agrega ao mesmo. Quanto maior for o tempo de
execuo do escalonador no sistema proporcionalmente a execuo das tarefas, menor ser
a eficincia.
Pode-se realizar o mesmo tipo de anlise de aumento proporcional no tempo de
execuo e de eficincia para um escalonador do tipo Round-Robin. Nesse caso o tempo
total de execuo passa a ser definido pela relao apresentada na figura 6.3.

(Eq. I)

(Eq. II)

69

Figura 6.3: Tempo Total de Execuo de Tarefas com o Escalonador Round-Robin

A partir da figura 6.3 pode-se considerar dois casos. O primeiro, supe-se que o
tempo de execuo das tarefas seja maior do que o quantum definido para execuo dessas
tarefas. Sob essa condio, o tempo total de execuo do sistema dado pela seguinte
equao:

+ =
n
i
s
q
ti
ti execuo de total tempo
1
) (

onde ti o tempo de durao da tarefa Ti, q o quantum e s o tempo necessrio
para a troca de contexto. A parcela ti/q representa, portanto, o nmero de trocas de contexto
necessrios para que a tarefa Ti seja completada.
O segundo caso considera que o tempo de execuo das tarefas seja igual ou
inferior ao quantum definido para processamento das mesmas. Nessa condio, a tarefa
consegue executar dentro do seu quantum, no necessitando ser escalonada outra vez para
terminar sua execuo. Nesse caso, a poltica Round-Robin apresenta o mesmo
comportamento da poltica FIFO.
Para simplificar a anlise supe-se ainda que todas as tarefas a serem executadas
possuem a mesma durao. Nessa hiptese, pode-se reescrever as equaes I e II para um
escalonador Round-Robin da seguinte forma:

q
s q
s
t n
q
t
s n t n
proporo aumento + =
+
=
+
= 1
1
1
) * (
) * ( ) * (
) (
(Eq. III)

(Eq. IV)

70
s q
q
q
t
s n t n
t n
eficincia
+
=
+
=
) * ( ) * (
) * (


onde (n * t) o tempo de processamento das n tarefas do sistema, s o tempo
necessrio para a troca de contexto e q o quantum.
A partir das equaes IV e V conclui-se que possvel estimar a eficincia e o
aumento do custo introduzido pelo escalonamento independentemente do nmero de
tarefas. Partindo desse pressuposto, para analisar de forma experimental o impacto dos
escalonadores, arbitrou-se a execuo de dez tarefas idnticas. A tarefa empregada a
implementao do algoritmo BubbleSort para ordenar um vetor de dez elementos.
Para investigar o impacto que a utilizao de escalonadores Round-Robin com
diferentes quanta agregaria ao sistema embarcado, algumas variaes de quantum foram
investigadas. A tabela 6.3 apresenta os valores dos quanta utilizados nessas simulaes.
Esses quanta foram assim definidos visto que as tarefas de ordenamento apresentavam
6.753 ciclos para suas execues.

Tabela 6.3: Quanta Utilizados para Escalonadores R.R.
Quantum # de ciclos
Q1 7.000 ciclos
Q2 5.000 ciclos
Q3 3.000 ciclos
Q4 2.500 ciclos

Cinco simulaes foram efetuadas nesta etapa, uma para o escalonador FIFO e
quatro para o escalonador Round-Robin com os quanta descritos acima. Cabe ressaltar que
os resultados so obtidos atravs do simulador CACO-PS, apresentando um
comportamento determinstico, isto , para uma mesma entrada obtm-se uma mesma
sada. Essa caracterstica elimina a necessidade de executar a aplicao um certo nmero de
vezes para valid-la estatisticamente.

6.3.1 Impacto em Nmero de Ciclos de Execuo
O nmero de ciclos para a execuo das dez tarefas apresentado na tabela 6.4.
Como pode ser observado, a poltica de escalonamento FIFO obteve o melhor resultado em
desempenho, necessitando menos ciclos para a execuo das tarefas.
(Eq. V)

71
Como esperado, possvel notar que a penalidade em ciclos de execuo para o
escalonador Round-Robin aumentou com a diminuio do quantum. Um quantum pequeno
resulta em um maior compartilhamento de CPU. Por outro lado, diminuindo-se o quantum
diminui-se a eficincia do sistema. Isso ocorre porque a CPU passa uma proporo maior
de tempo executando o escalonamento do que aplicaes do usurio.
Aqui se tem um ponto importante a ser considerado em um sistema operacional
embarcado. Um escalonador FIFO ou um Round-Robin com um quantum relativamente
grande iro apresentar melhores resultados em termos de ciclos de execuo e consumo de
energia, porm, a qualidade de servio poder ser degradada devido ao tempo excessivo
que a tarefa ter que aguardar para receber o controle da CPU.

Tabela 6.4: Nmero de Ciclos Executados pelos Diferentes Escalonadores
Escalonador Quantum Ciclos
Nenhum - 67.530
FIFO - 73.228
Q1 73.498
Q2 78.436
Q3 85.552
R.R.
Q4 88.054

A tabela 6.5 apresenta o custo em termos de ciclos de execuo agregado pelo
emprego de cada um dos escalonadores.

Tabela 6.5: Custo em Termos de Nmero de Ciclos de Execuo
Escalonador Quantum % de Custo
FIFO - 8,4%
Q1 8,8%
Q2 16,1%
Q3 26,7%
R.R.
Q4 30,4%

O nmero total de ciclos executados apenas pelas tarefas de usurio foi de 67.530.
O escalonador FIFO adicionou um custo de 8,4% ao sistema. O escalonador Round-Robin
agregou apenas 8,8% quando se utilizou um quantum de 7.000 ciclos. Esse comportamento,
similar ao obtido para o escalonador FIFO, explicado devido as tarefas conseguirem
executar at a sua finalizao, visto que cada uma elas possui menos ciclos do que o
quantum definido. J para os valores menores de quantum, o custo adicionado ao sistema
72
foi maior, saindo de 16,1% para um quantum de 5.000 ciclos, 26,7% para um quantum de
3.000 ciclos e 30,4% para um quantum de 2.500. A figura 6.4 ilustra esse comportamento.

0%
5%
10%
15%
20%
25%
30%
35%
FIFO R.R. Q1 R.R. Q2 R.R. Q3 R.R. Q4
% de Custo

Figura 6.4: Acrscimo no Nmero de Ciclos de Execuo

6.3.2 Impacto em Consumo de Energia
O consumo de energia para a execuo das dez tarefas apresentado na tabela 6.6.
Esses valores so fornecidos em capacitncias de portas chaveadas (CGs) em trs mdulos
distintos da arquitetura: memrias RAM, ROM e ncleo da arquitetura.
Como pode ser visto, a estratgia FIFO obteve o menor consumo de energia dentre
todas as alternativas, 383.987K CGs. O maior consumo foi obtido na simulao do
escalonador Round-Robin utilizando-se um quantum de 2.500. Nessa simulao o consumo
subiu para 458.317K CGs, um aumento de consumo em torno de 19% em relao a
simulao com o escalonador FIFO.

Tabela 6.6: Consumo de Energia pelos Diferentes Escalonadores
Escalonador Q. RAM ROM Ncleo Total
Nenhum - 207.920.000 4.232.000 127.828.100 339.980.100
FIFO - 223.629.000 4.667.390 155.690.829 383.987.219
Q1 224.319.000 4.688.090 156.501.276 385.508.366
Q2 238.625.000 5.078.170 166.783.785 410.486.955
Q3 258.106.000 5.614.300 182.147.846 445.868.146
R.R.
Q4 265.535.000 5.787.950 186.994.410 458.317.360

73
A figura 6.5 ilustra o acrscimo de consumo de energia total para as simulaes
realizadas.

0
50.000
100.000
150.000
200.000
250.000
300.000
350.000
400.000
450.000
500.000
Nenhum FIFO R.R. Q1 R.R. Q2 R.R. Q3 R.R. Q4
Consumo Energia
(Kilo CGs)

Figura 6.5: Acrscimo do Consumo de Energia

Duas constataes podem ser feitas nessas simulaes. A primeira delas que
existe uma relao evidente entre a quantidade de nmero de ciclos executados e o
consumo de energia na arquitetura. Quanto maior o nmero de ciclos necessrios para a
execuo das tarefas, maior o consumo de energia. A segunda constatao est
relacionada com o aumento significativo de consumo de energia obtido entre o melhor e o
pior resultado. Uma escolha adequada da poltica de escalonamento a ser empregada pode
reduzir o consumo de energia significativamente. Contudo, essa escolha do uso de um
escalonador precisa levar em conta as necessidades e os requisitos das aplicaes do
usurio.

6.4 Comparao: Implementao em Baixo X Alto Nvel
Para avaliar a eficincia da implementao em baixo nvel (bytecodes Java) e
verificar se as novas instrues estendidas desenvolvidas ofereciam vantagem sobre uma
implementao de escalonadores em alto nvel (linguagem Java), uma comparao entre
duas implementaes diferentes de um escalonador Round-Robin foi realizada. Essa
comparao consistiu em avaliar os resultados de consumo de energia e desempenho de
uma implementao em linguagem de baixo nvel contra uma implementao em
linguagem de alto nvel do mesmo escalonador, desenvolvida por Alexandre Gervini em
74
um trabalho correlato, a ser publicado, na UFRGS. Para tanto, fez-se uso do escalonador
Round-Robin com um quantum de 2.000 ciclos para realizar o escalonamento de dez
tarefas distintas de ordenamento. Na tabela 6.7 os resultados obtidos so apresentados.
Esses resultados esto organizados de acordo com os mdulos internos dos escalonadores.

Tabela 6.7: Comparao de um Escalonador R.R. Implementado em Baixo e Alto Nvel
Implementao Mdulo Ciclos RAM ROM Ncleo Total
Inicializao 724 2.277.000 59.570 1.503.182 3.839.752
Baixo Nvel
Execuo 480 1.380.000 37.260 1.008.363 2.425.623
Inicializao 1038 2.001.000 106.490 2.735.575 4.843.065
Alto Nvel
Execuo 544 1.706.000 39.100 1.208.420 2.953.520

Como pode ser visto o nmero total de ciclos necessrios para execuo na
implementao realizada em baixo nvel, 1204 ciclos, foi menor do que o nmero de ciclos
obtidos no escalonador implementado em linguagem de alto nvel, 1582. Os valores de
potncia, conseqentemente, tambm foram melhores para a implementao em baixo
nvel.
Embora as diferenas de ciclos de execuo e de consumo de energia total para os
mdulos de inicializao sejam significativas, 314 ciclos e 1.003K CGs consecutivamente,
as diferenas mais relevantes encontram-se no mdulo de execuo. Esse mdulo
executado toda vez que o escalonador acionado, podendo ser chamado diversas vezes
durante a operao do sistema, ao contrrio do mdulo de inicializao que executado
apenas uma nica vez. Assim, o impacto mais importante a ser analisado refere-se aos
mdulos de execuo das duas implementaes. Da mesma forma, a implementao em
baixo nvel obteve uma leve vantagem sobre a implementao em alto nvel, cerca de 21%
em termos de consumo total de energia para essa simulao.
A figura 6.6 ilustra o impacto em termos de ciclos de execuo para as
implementaes em baixo e alto nvel do mesmo escalonador. A figura 6.7 mostra o
consumo total de energia das duas implementaes em KCGs.

75
0
200
400
600
800
1000
1200
C
i
c
l
o
s
I
n
i
c
i
a
l
i
z
a

o
E
x
e
c
u

o
I
n
i
c
i
a
l
i
z
a

o
E
x
e
c
u

o
Baixo Nvel Alto Nvel
Implementao

Figura 6.6: Impacto das Duas Implementaes em Ciclos de Execuo


0
500
1.000
1.500
2.000
2.500
3.000
3.500
4.000
4.500
5.000
P
o
t

n
c
i
a

(
K
C
G
s
)
I
n
i
c
i
a
l
i
z
a

o
E
x
e
c
u

o
I
n
i
c
i
a
l
i
z
a

o
E
x
e
c
u

o
Baixo Nvel Alto Nvel
Implementao

Figura 6.7: Consumo Total de Energia das Implementaes em Baixo e Alto Nvel

A constatao que se chega a partir dessa comparao realizada que a
implementao em baixo nvel mais custosa em rea, pois, como visto na tabela 6.1, um
pequeno acrscimo de rea introduzido devido a disponibilizao das seis instrues
estendidas. Porm, na implementao em alto nvel, apenas duas instrues desenvolvidas
foram utilizadas, SAVE_CTX e REST_CTX, diminuindo assim a rea necessria em
hardware.
Por outro lado, na implementao em baixo nvel, utilizando as seis instrues
desenvolvidas, obteve-se melhores resultados em consumo e desempenho.
76
Desta forma conclui-se que, na soluo apresentada, para economizar energia e
ganhar em desempenho acaba-se pagando em rea.

6.5 Consideraes Gerais
Nos resultados apresentados na seo 6.3, utilizou-se um conjunto de dez tarefas
idnticas de ordenamento para a realizao das simulaes. Contudo, decidiu-se verificar o
comportamento do sistema quando as tarefas possussem diferentes tempos de execuo e,
assim, analisar o impacto dos escalonadores sobre esse conjunto. Essas tarefas so
apresentadas na tabela 6.8, com seus respectivos ciclos de execuo.

Tabela 6.8: Tarefas e Ciclos de Execuo
# Processo Ciclos
1 Insert 40 110.911
2 Select 50 107.163
3 Select 20 18.628
4 Bubble 10 6.727
5 Crane 2 161.820
6 Select 70 205.268
7 IMDCT 194.545
8 Bubble 50 214.200
9 Select 10 5.288
10 Bubble 30 73.740

Como pode ser visto, alm dos algoritmos de ordenamento InsertSort, SelectSort e
BubbleSort, utilizados para ordenar vetores com diferentes nmeros de elementos, tambm
se fez uso de um filtro IMDCT. Esse filtro consiste em uma rotina que calcula o inverso da
transformada discreta do coseno, bastante empregada em operaes de decompresso,
como, por exemplo, em decodificadores de MP3 (SALOMON 2000). Por ltimo, utilizou-
se uma aplicao conhecida como Crane. Essa aplicao consiste em um carrinho de
transporte que se desloca sobre um trilho carregando uma carga suspensa, a qual no pode
sofrer uma acelerao e inclinao maior do que um certo ngulo permitido pelo sistema
(MOSER, 1999). Para a simulao fez-se uso do algoritmo de controle dessa aplicao.
Para a realizao da simulao com o escalonador Round-Robin, optou-se em
utilizar um quantum de 30.000 ciclos. Esse valor foi selecionado devido ao fato de que
assim algumas tarefas poderiam executar uma nica vez, enquanto outras seriam
escalonadas um maior nmero de vezes at conclurem seu processamento.
A tabela 6.9 apresenta os resultados obtidos na simulao. Na tabela 6.10 so
apresentados os custos em termos de ciclo de execuo agregado pelos escalonadores.
77
Tabela 6.9: Ciclos Executados e Consumo de Energia pelos Diferentes Escalonadores
Escalonador Ciclos RAM ROM Ncleo Total
FIFO 1.104.187 4.423.958.000 73.846.330 2.379.351.485 6.877.155.815
R.R. 1.128.505 4.493.234.000 75.685.870 2.442.459.682 7.011.379.552


Tabela 6.10: Custo em Termos de Nmero de Ciclos de Execuo
Escalonador % de Custo
FIFO 0,54%
R.R. 2,73%

A tabela 6.10 apresenta o impacto dos escalonadores sobre o conjunto de tarefas
da tabela 6.8. Esse impacto foi calculado somando-se o nmero de ciclos de execuo das
tarefas (1.098.290) e comparando-se com o nmero total de ciclos de execuo do
escalonador FIFO (1.104.187) e do Round-Robin (1.128.505). O aumento no nmero de
ciclos corresponde ao acrscimo introduzido pela execuo do cdigo dos escalonadores.
Com base nesses valores verifica-se que o custo em nmero de ciclos de execuo para esse
grupo de aplicaes aumentou cerca de 0,54% para o escalonador FIFO e 2,73% para o
escalonador Round-Robin. Esse impacto foi menor, se comparado com os resultados
obtidos nas simulaes da seo 6.3, devido ao grupo de tarefas apresentar uma
composio heterognea em relao aos ciclos de execuo. Algumas dessas tarefas
conseguem terminar sua execuo mais rapidamente, disputando menos vezes a posse da
CPU. Alm disso, conforme as equaes I e II, quanto maior for o tempo de execuo das
tarefas em relao ao tempo gasto para escalonamento e troca de contexto, melhor ser a
eficincia do sistema. Em outros termos, o impacto do escalonamento menor visto que o
tempo de processamento til das tarefas maior do que o tempo de execuo do
escalonador.

6.6 Resumo
A anlise da soluo proposta para implementar multitarefa na arquitetura Java
embarcada demonstrou que os objetivos iniciais foram alcanados. Conseguiu-se
implementar o suporte a troca de contexto com um pequeno acrscimo de rea em
hardware. Tambm foram implementados dois escalonadores com custos aceitveis em
memria de dados.
Os resultados das simulaes mostraram que factvel ter uma camada de sistema
operacional enxuto, formada por um escalonador, trabalhando junto a arquitetura para
78
prover multitarefa sem comprometer o sistema em termos de consumo de energia e
desempenho de processamento.

79
7 CONCLUSES FINAIS E TRABALHOS FUTUROS
Este trabalho apresentou uma proposta de implementao de multitarefa para a
arquitetura FemtoJava dedicada a sistemas embarcados. Essencialmente essa proposta
contempla a incluso de novas instrues na arquitetura para suportar troca de contexto
entre tarefas, a implementao de duas polticas de escalonamento, alteraes no ambiente
SASHIMI e a implementao de uma ferramenta de relocao de endereos para permitir,
de forma simples, o uso desses recursos.
Os resultados obtidos mostram que a incluso de multitarefa no microcontrolador
factvel em termos de custo, condizendo com o compromisso de no aumentar
significativamente o consumo em rea, energia e desempenho.
Um pequeno aumento em termos de rea de hardware foi introduzido pelos
escalonadores implementados. Esse resultado em torno de 5% atende ao compromisso
assumido, visto que desejvel minimizar ao mximo a rea necessria para o
desenvolvimento do sistema embarcado, visando assim a minimizao do custo final do
produto.
Em termos de desempenho, os escalonadores introduziram, tambm, um custo
aceitvel no sistema embarcado.
Em relao ao consumo de energia, o escalonador Round-Robin apresentou um
maior impacto que o escalonador FIFO. Esse impacto explicado pela execuo mais
freqente do cdigo do mesmo, visto que esse acionado um maior nmero de vezes
devido ao quantum de execuo dedicado a cada tarefa.
Os resultados obtidos nas avaliaes mostraram que a escolha de uma poltica de
escalonamento no est apenas relacionada com o melhor desempenho ou com o menor
consumo. preciso considerar as necessidades do sistema computacional embarcado onde
o escalonador ser includo. Para determinados sistemas, um escalonar FIFO pode ser ideal,
para outros, onde existe uma necessidade de maior compartilhamento de CPU, o
escalonador Round-Robin pode ser mais apropriado, cabendo ao projetista definir qual a
melhor opo.
80
Para que os escalonadores desenvolvidos em linguagem de baixo nvel pudessem
ser utilizados junto ao ambiente SASHIMI, algumas modificaes foram realizadas no
mesmo. Essas pequenas modificaes implicaram em algumas novas regras de projeto para
o ambiente, tornando possvel a utilizao de escalonadores descritos em baixo nvel com
aplicaes desenvolvidas em Java.
Dentro desse contexto, foi realizada a implementao de uma ferramenta de
relocao de endereos para ajustar detalhes do cdigo dos escalonadores junto s
aplicaes do usurio. Essa ferramenta torna factvel o emprego dos escalonadores
implementados em bytecodes Java junto ao fluxo de desenvolvimento do SASHIMI.
Assim, fazendo-se uso do ambiente SASHIMI e da ferramenta de relocao de endereos
desenvolvida torna-se vivel, fcil e rpida a implementao de um sistema embarcado
composto por algum dos escalonadores desenvolvidos.
Uma outra constatao obtida na realizao do trabalho est relacionada com a
caracterstica da arquitetura FemtoJava ser uma arquitetura no-bloqueante, onde as
operaes de E/S so feitas via polling em registradores especficos mapeados em portas de
E/S. Essa caracterstica est ligada a idia inicial de apenas uma aplicao ser executada
sobre o mesmo. Porm, para que todas as funcionalidades de um sistema multitarefa
possam ser exploradas, seria necessrio realizar uma adequao da arquitetura. Essa
adequao teria que levar em conta a existncia de vrias tarefas em execuo, que podem
estar utilizando as mesmas portas de E/S para leitura e escrita de dados. Isso permitiria,
tambm, que as tarefas pudessem entrar em uma fila de tarefas bloqueadas, ficando fora da
disputa pela alocao da CPU enquanto a sua requisio de E/S no fosse atendida. Na
atual implementao isso no levado em considerao.
Quanto a proteo de memria, a arquitetura FemtoJava no apresenta nenhum
mecanismo para esse controle. Dessa forma, dividiu-se a rea de memria de dados do
escalonador e as pilhas das tarefas de maneira que nenhuma dessas reas pudesse ser
sobrescrita por outra. Para todas as simulaes essa medida foi eficiente. Porm, para
trabalhos futuros poderia-se pensar em algum sistema de proteo de memria para novas
verses da arquitetura. Um exemplo seria a utilizao de registradores para controle do
crescimento da pilha. Nesses registradores ficariam armazenados os endereos base e limite
da pilha. Caso a mesma crescesse alm do tamanho mximo permitido, a execuo seria
interrompida. Evidentemente, para que esse controle seja possvel, mudanas arquiteturais
precisam ser realizadas.
Outro ponto a ser futuramente explorado analisar o comportamento das polticas
FIFO e Round-Robin segundo as mtricas tradicionalmente usadas na avaliao de
escalonadores, tais como turnaround, tempo de resposta, troughput e etc.
Tambm, como trabalho futuro, pode-se pensar na implementao de
escalonadores de tarefas em hardware ao invs de software, como apresentado nesse
81
trabalho. Toda a tarefa de escalonamento poderia ser realizada por hardware auxiliar,
deixando somente a realizao da troca de contexto para a arquitetura M-FemtoJava.
Por fim, acredita-se que contribuies foram dadas no decorrer dessa dissertao,
tanto na reviso e na anlise das necessidades bsicas para permitir suporte a multitarefa,
assim como nas implementaes e avaliaes realizadas.
82
REFERNCIAS

ACQUAVIVA, A.; BENINI, L.; RICCO, B. Energy Characterization of Embedded Real-
Time Operating Systems. In: WORKSHOP COMPILERS & OPERATING SYSTEMS
FOR LOW POWER, 2001, Barcelona. Proceedings... Los Alamitos: [s.n.], 2001. p. 13
18.
AHO, A. V.; SETHI, R.; ULLMAN, J. D. Compiladores: Princpios, Tcnicas e
Ferramentas. Rio de Janeiro, LTC, 1995.
ALTERA. Disponvel em: <http://www.altera.com>. Acesso em: 2004.
BARABANOV, M.; YODAIKEN, V. Real-Time Linux. [S.l.]: New Mexico Institute of
Technology, 1996.
BAYNES, K. et al. The Performance and Energy Consumption of Embedded Real-Time
Operating Systems. IEEE Transactions on Computers, New York, v. 52, n. 11, p. 1454
1469, Nov. 2003.
BECK, A. C. F.; WAGNER, F. R.; CARRO, L.; MATTOS, J. C. B. de. CACO-PS: A
General Purpose Cycle-Accurate Configurable Power Simulator. In: SYMPOSIUM ON
INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 16., 2003, So Paulo.
Proceedings... Los Alamitos: IEEE Computer Society, 2003. p. 349 354.
CIGNETTI, T. L.; KOMAROV, K.; ELLIS, C. S. Energy Estimation Tools for the Palm.
In: INTERNATIONAL WORKSHOP ON MODELING, ANALYSIS AND
SIMULATION OF WIRELESS AND MOBILE SYSTEMS, 3., 2000, Boston.
Proceedings... Los Alamitos: ACM, 2000.
CLARK, D. Mobile Processors Begin to Grow Up. IEEE Computer, New York, v. 35, n.
3, p. 22 25, Mar. 2002.
83
DENYS, G.; PIESSENS, F.; MATTHIJS, F. A Survey of Customizability in Operating
Systems Research. ACM Computing Surveys, New York, v. 34, n. 4, p. 450 468, Dec.
2002.
DICK, R. P. et al. Power Analysis of Embedded Operating Systems. In: DESIGN
AUTOMATION CONFERENCE, 37., 2000, New Orleans. Proceedings... Los Alamitos:
IEEE Computer Society, 2000. p. 312 315.
FARINES, J.; FRAGA, J. S.; OLIVEIRA, R. S. Sistemas de Tempo Real. Florianpolis:
Departamento de Automao e Sistemas, Universidade Federal de Santa Catarina, 2000.
GALLMEISTER, B. O. POSIX.4: Programming for the Real World. Sebastopol: OReilly
& Associates, 1995.
GUIRE, N. Mc. MiniRTL Hard Real Time Linux for Embedded Systems. Dedicated
Systems Magazine, [S.l.], 2001. Disponvel em: <http://www.dedicated-
systems.com/2001/Q3>. Acesso em: 2001.
ITO, S. Projeto de Aplicaes Especficas com Microcontroladores Java Dedicados.
2000. Dissertao (Mestrado em Cincia da Computao) - Instituto de Informtica,
UFRGS, Porto Alegre.
ITO, S.; CARRO, L.; JACOBI, R. Making Java Work for Microcontroller Applications.
IEEE Design & Test of Computers, California, v. 18, n. 5, p. 100-110, Sept./Oct. 2001.
KADIONIK, P. Linux Embarqu: Le Project uClinux. Linux Magazine, France, n. 36, p.
16-23, Fv. 2002.
KREUZINGER, J. et al. Performance Evaluations and Chip-Space Requirementes of a
Multithreaded Java Microcontroler. 2002. Disponvel em:
<http://citeseer.nj.nec.com/384138.html>. Acesso em: 2002.
LAWTON, G. Moving Java into Mobile Phones. IEEE Computer, New York, v. 35, n. 6,
p. 17 20, 2002.
LEHRBAUM, R. Bully in the (embedded) playground. Linux Journal, [S.l.], 2002.
Disponvel em: <www.linuxjournal.com/article.php?sid=5698>. Acesso em: 2002.
MICROSOFT CORPORATION. Windows Embedded Home. Disponvel em:
<http://msdn.microsoft.com/embedded>. Acesso em: 2004.
84
MOSER, E.; NEBEL, W. Case Study: System Model of Crane and Embedded Control. In:
DESIGN, AUTOMATION AND TEST IN EUROPE, 1999, Munich. Proceedings... Los
Alamitos: IEEE Computer Society, 1999. p.721 723.
NETBSD. NetBSD Manual Pages. Disponvel em: <http://www.netbsd.org>. Acesso em:
2004.
NOKIA. N-Gage Home Page. Disponvel em: <http://www.n-gage.com>. Acesso em:
2004.
OLIVEIRA, R.; CARISSIMI, A; TOSCANI, S. Sistemas Operacionais. 2.ed. Porto
Alegre: Sagra Luzzatto, 2001.
ORTIZ, S. JR. Embedded OSs Gain the Inside Track. IEEE Computer, New York, v. 34,
n. 11, p. 14 16, Nov. 2001.
REDHAT. eCos | Embedded Configurable Operating System. Disponvel em:
<http://www.redhat.com/explore/goembedded>. Acesso em: 2003.
SALOMON, D. Data Compression: The Complete Reference. 2nd ed. New York:
Springer, 2000.
SANTO, B. Embedded Battle Royale. IEEE Spectrum, New York, v. 38, n. 12, p. 36
41, Dec. 2001.
SASHIMI: Manual do Usurio. Verso 0.8b. Porto Alegre: PPGC-UFRGS, 2002.
SHAY, W. A. Sistemas Operacionais. So Paulo: Makron Books, 1996.
SIA: Semiconductor Industry Association Home Page. Disponvel em:
<http://public.itrs.net/Files/2003ITRS/Home2003.htm> Acesso em: 2004.
SILBERSCHATZ, A.; GALVIN, P.; GAGNE, G. Applied Operating System Concepts.
New York: John Wiley, 2000.
STALLINGS, W. Operating Systems. 4th ed. Upper Saddle River: Prentice-Hall, 2001.
TAKAHASHI, D. Java Chips Make a Comeback. [S.l.]: Red Herring, 2001.
TAN, T.K.; RAGHUNATHAN, A.; JHA, N.K. Embedded Operating System Energy
Analysis and Macro-Modeling. In: IEEE INTERNATIONAL CONFERENCE ON
COMPUTER DESIGN: VLSI IN COMPUTERS AND PROCESSORS, ICCD, 2002,
Freiburg. Proceedings... Los Alamitos: IEEE Computer Society, 2002. p. 515 522.
TANENBAUM, A. S. Sistemas Operacionais Modernos. 2. ed. So Paulo: Prentice-Hall,
2003.
85
UCLINUX PROJECT. Embedded Linux / Microcontroller Project. Disponvel em:
<http://www.uclinux.org/index.html>. Acesso em: 2004.
WILLIAMS, J. Embedding Linux in a commercial product. Linux Journal, [S.l.], Oct.
2002. Disponvel em: <www.linuxjournal.com/article.php?sid=3587>. Acesso em: 2002.
WINDRIVER. VxWorks 5.x Real-Time Operating System. Disponvel em:
<http://www.windriver.com/corporate/rtsystems>. Acesso em: 2003.
WOLF, W. What Is Embedded Computing? IEEE Computer, New York, v. 35, n.1, p.
136 137, Jan. 2002.
ZUBERI, K. M.; SHIN K. G. Emeralds: A Small-Memory Real-Time Microkernel. IEEE
Transactions on Software Engineering, New York, v. 27, n. 10, p. 909 928, Oct. 2001.