KSH: Simulador de memória cache com carregamento dinâmico de módulos e execução de script de configuração

Alessandro Ribeiro da Silva 1 Ramon Duarte Pinho2

Pontifícia Universidade Católica de Minas Gerais A v. Dom José Gmpar, 500- Coração Eucarístico- CEP 30535-610

Belo Horizonte- Minas Gerais r ~pdoido@ hotmail.com}1

- r ramon-duarte-pinho@ boi. com. brl

Resumo

Este trabalho apresenta um software para simulação de memória cache desenvolvido numa disciplina de graduação. Seu propósito é de setvir como ferramellfa didática para análise e aprendizado de d(feremes estruturas de memória cache.

1. Introdução

Memória cache é estudado no tópico Hierarquia de Memória na disciplina de Arquitetura de Computadores. Os exercícios de memória cache apresentam uma diliculdade geral para o estudante pois são extensos, trabalhosos e demorados. Para facilitar o aprendizado seria interessante o uso de simuladores[3], que agilizariam sua análise de desempenho relativos a taxas de acerto e falta, por exemplo de uma seqüência de instruções de uma linguagem.

Analisando alguns simuladores de memória cache observamos pontos positivos e negativos: Uns eram muito técnicos, outros muitos simples, outros pouco didáticos.

Um dos simuladores analisados foi desenvolvido na mesma disciplina há um ano atrás por alunos da PUC cujo artigo sobre o mesmo foi publicado no WSCAD 2002. Ele simulava um único tipo de arquitetura de memória cache e exibia um resultado técnico com as taxas de acerto e tempo total de acesso [4]. Este simulador é simples e de uma interface simples com o usuário.

Outro simulador analisado foi o Xcache32, que apresentou interessantes recursos de interface com usuário[6]. O Xcache é bastante complexo e tem uma interface com outro simulador que é o Dinaro[7]. Este simulador explora poucos recursos didáticos e a princípio não é fácil de utilizar. O Dinaro é um simulador de memória cache para usuário avançado pois não apresenta uma interface amigável para um estudante iniciante.

Após uma análise destes simuladores foi delinido um conjunto de características ideais para um simulador didático. A partir daí foi proposto o desenvolvimento de um simulador vinculado como atividade para a disciplina em curso. O objetivo era mostrar o conteúdo das memórias em seus dois níveis, e o resultado de seus acessos. Foi inicialmente

160

proposto que o simulador teria três tipos de arquitetura de cache com as políticas de substituição FIFO e LRU como estudado no livro do Patterson[l][2].

Uma contribuição de nosso projeto foi a criação de um estrutura na qual fosse possível carregar dinamicamente módulos do software, explicado no tópico 2.2. Foi criado também um processador de scripts, explicado no tópico 2.1. Nosso simulador foi implementado na linguagem Java®[5]na versão 1.4, editado pelo JCreator versão 2.00 e demos a ele o nome de KSH.

Foi utilizado cinco figuras para mostrar as interfaces do simulador. Foi construída três tabelas para mostrar os resultados.

2. A ferramenta

O simulador atualmente pode ser executado em duas interfaces escolhidas pelo usuário: modo gráfico (GU1)3 e modo console (tipo dos). Ambas as interfaces oferecem ao usuário as mesmas opções, dentre elas, abrir um arquivo de seqüência de endereços, entrar com um endereço e escolher uma configuração para as memórias.

Figura 1. Imagem do simulador no modo gráfico para entrada de dados via teclado

.1 - GUI - Graplric User Interface- A Interface v isual com o usuário em contraste com o modo DOS.

Anais WSCAD 2003 O modo gráfico apresenta suas vantagens, é mais

amigável e os dados não devem ser inseridos numa ordem pré-determinada.

Para operar o simulador o usuário deve configurar inicialmente as características das memórias. Por enquanto pode ser con fi gurado para operar com as três arquiteturas básicas (Associativo por Conjunto. Completamente Associativo. Mapeamento Direto), duas políticas de substituição (FIFO, LRU), duas técnicas de escrita (Wrire Back, Wrire Tlmmgh). e o tipo de acesso a memória (Paralelo, Sequencial), estudadas na disciplina[ 1]. O usuário também pode definir o tamanho da memória principal, o tamanho da memória cache, o tamanho do bloco, o tamanho da palavra e o tempo de acesso às memórias.

A execução pode ser fe ita passo a passo ou integral a partir de um arquivo de entrada com uma seqüência de endereços (memory trace), ou através da entrada dos endereços via teclado. O programa irá exibir o que ocorreu durante o acesso considerando acerto ou falta, leitura ou escrita, substituição de bloco e escrita na memória.

ertura do End 1004 tltura do End 1005

. ,.

""---~--~~~~--+.,rl~•cr~a do Valor60 no End 200 eitura do End 1006 eltura do End I 0002 erlur• do End I 0 2 ellura do End 10003 eltura do End I 0 3

Figura 2. Foto da interface gráfica executando leitura de uma arquivo de seqüência de endereços.

Uma das características de implementação do software foi a idéia de carregar dinamicamente alguns módulos permitindo que algumas características sejam independente do programa principal. O carregamento dinâmico foi criado com a finalidade de tornar o simulador nexível e expansível e será explicado com mais detalhes no tópico 2.2.

O processador de script oferece ao usuário uma opção de automatização e personalização de algumas funções do simulador. Atualmente existe apenas um comando de inferência no simulador que define a configuração das memórias do simulador. Contudo a idéia é permitir que o arqui vo de script crie uma verdadeira interação com o simulador. O script seria interessante didaticamente, pois uma seqüência de instruções poderiam ser repetidas numa ordem com padrões diferentes. Ele também seria utilizado para a criação de tutoriais.

2.1. O Processador de Script

161

O processador de script originou de um pr~jeto da disciplina Linguagens de Programação, concluído no início do semestre de 2003. que foi adaptado ao simulador para execução de scripts.

Atualmente uma instrução para o processador de sc:riprs permite a configuração das memórias serem feitas através de um arquivo de script.

O arquivo de scripr é um arquivo externo de texto no padrão ASCII e que poderá ser aberto pelo simulador. No arquivo pode ser definido variáveis que podem ser atribuídas a valores que podem ser computados c alterados. As instruções disponíveis do simulador poderão ser chamadas no sc:ripr com passagens de parâmetro. Existem os mnemônicos (if, for, while) para formar as estruturas de controle de condição e de laços de repetição com as instruções.

Segue um exemplo de uni script para configurar uma memória:

'·proc main() local Str: Str := "1024," + "16," + "AC," + "LRU," + "4," +

"8," + "W-B," + "4, .. + "SEQ," + "5," + "50 .. ; AtivarModulos(Str): Endp" Esse é um exemplo simples que chama uma função

do simulador que é ArivarModulos() que passa como parâmetro uma sequencia de caracteres que representam a configuração da hierarquia de memória.

Na primeira linha. "proc main" representa o escopo principal para o scripr. Logo em seguida é declarada uma variável local, para esse escopo, de nome "Str". O conteúdo dessa variável é a concatenação das strings que seguem após a atribuição ":=". Os valores representam respectivamente: Tamanho da memória principal, tamanho da palavra, tipo de arquitetura da cache, tipo da política de substituição, número de slots, tamanho do bloco da cache, forma de como proceder com uma escrita (Write tl1rough ou Write back), número de conjuntos (para Associati vo por conjunto), tipo de acesso à memória, tempo de acesso à cachc e tempo de acesso à memória. Existe uma vírgula entre as strings para separar o valor para cada atributo quando esta string tor lida dentro da função.

O Processador de scripr oferece opções para operações em cima de valores e variáveis assim como a criação de fluxos de execução.

2.2. O Carregador Dinâmico

O carregador dinâmico foi implementado utilizando-se de alguns recursos do Java®[5] permitindo que algumas classes sejam carregadas apenas quando requisitadas pelo programa, exemplo na figura 3. Apesar de que a atual estrutura do simulador ofereça o carregamento de apenas um tipo de módulo referente a arquitetura da memória cache, a idéia visa a instanciação de classes carregadas durante a execução do programa. Futuras implementações poderiam oferecer o carregamento de interfaces com o usuário. ·

A carga dinâmica pode ser implementada à parte e acrescentada à ferramenta de forma

Figura 3. Estruturas carregadas dinamicamente exibidas no modo console

A tigura 4 é uma ilustração descritiva da estrutura do carregador dinâmico com os três tipos de arquitetura de cache implementadas.

Ç.QQ1P!P,J~tn!J . .rt~N~.9Q<IJI.Y~ 01!~5

AC.r!'i~$

MilDS!.é!IJl~Dl9Qif~lQ.çt~~~

Busca do Módulo para Carregamento

Figura 4. Diagrama da estrutura do Carregador Dinâmico

Uma função do simulador permite a busca de todos os módulos existentes num diretório, no caso ArquiteturaCache. Após a busca de módulos, o Carregador Dinâmico armazena uma referência para cada módulo válido juntamente com seu nome definido internamente no arquivo ".class", assim possibilitando uma instanciação futura. Caso o usuário deseje expandir seu simulador, ele deve adicionar o arquivo correspondente a uma nova arquitetura neste diretório.

Junto com o software existe um arqui vo molde para a classe que irá ser projetada como novos módulos para o software. A criação de novos módulos poderia ser feita por outros programadores ou mesmo estudantes com o fim de aprender mais implementando alguma estrutura nova.

3. Resultados de Testes

Os resultados foram avaliados a partir de simulações feitas com o KSH. A figura 5 exibe a o estado da simulação após execução de uma leitura de endereço de memória. No modo console, cada acesso à memória mostra a taxa de acerto e taxa de faltas, número total de acessos, tempo total e outros aspectos.

162

Figura 5. Exemplo de um acesso de leitura feita no modo console.

Os testes focaram a funcionalidade do simulador de cache e para isso tentou-se muitas contigurações. Para mostrar o resultado foi montado três tabelas. A Tabela I define as siglas utilizadas nas configurações da Tabela 2 as quais são utilizadas na tabela 3 que é o resultado efetivo.

T bel 1 s· I tT d tab I 2 a a . 1g1as u 1 1za as na e a Sigla Significado CF Configuração TM Tamanho da Cache (N.0 de Slots) TC Tipo de Cache PoiS Política de Substituição (LRU. FIFO) NW Número de conjuntos TE Técnica de Escrita TA Ti.J:l.o de Acesso MD Mapeamento Direto CA Completamente Associativo AC Associativo por Conjunto Prll Paralelo Seq S~güencial

WB Write Back WT Write Through X Não importa _gual escolha

- . . As conliguraçoes da Tabela 2 ut1hzaram tamanho

da palavra de 16bits, tamanho da memória principal de 16384 palavras, tempo de acesso a cache de 5ns, e tempo de acesso a memória principal de SOns.

Tabela 2. Confi urações de simulações. CF TM TC PoiS NW TE TA (I) 4 MD X X WT Seq (li) 4 MD X X WT Prll (IIl) 4 MD X X WB Seq (IV) 4 MD X X WB Prll (V) 4 CA X X WT Seq (VI) 4 CA X X WT Prll (VII) 4 CA X X WB Seq (VIII) 4 CA X X WB Prll (IX) 4 AC X 2 WT Prll (X) 4 AC X 2 WB Prll (XI) 2 CA FIFO X WB Prll (Xfl) 2 CA LRU X WB Prll

Anais WSCAD 2003

A seqüência de endereços utilizadas para o teste é a mesma mostrada na Figura 2, escolhida porque a taxa de acerto varia de acordo com o tipo de arquitetura de cache utilizada. O tempo de acesso também pode ser ana lisado. comparando o desempenho que proporciona o uso de acesso à memória para lelo ou seqüencial ou mesmo variações do tempo entre o tipo de escrita (Write bac:k ou write through).

Tabela 3. Resultados de Simulações com as fi - d bel 2 con 1guraçoes a ta a •

Config. N.o N.o Taxa Tempo

Acesso. Acertos Acerto (ns) (I) 20 16 0.8 400 (li) 20 16 0.8 :no (lU) 20 16 0.8 300 (IV) 20 16 0 .8 280 (V) 20 17 0.85 350 (VI) 20 17 0.85 325 (VII) 20 17 0.85 250 (VIII) 20 17 0.85 235 (IX) 20 17 0.85 325 (X) 20 17 0.85 235 (XI) 20 15 0.75 375 (X O) 20 14 0.7 470

4. Conclusão

Concluímos o desenvolvimento do simulador como atividade da discipl ina e muito foi aprendido. Muitas características da proposta inicial não foram implementadas porque foi ocupado muito tempo com o aprendizado do Swing do Java® e com desenvolvimento de uma estrutura na qual o software pudesse carregar dinamicamente seus módulos.

Com o fim do trabalho os testes locaram questões técnicas do simulador e deixaram de lado um pouco o objetivo de verificar a didática do simulador. O teste pode ser visto também como um exemplo de como uma análise de simulações podem ser interessantes ao aprendizado.

Esse pr~jeto deixa muitas idéias para futuras melhorias. O software fo i quase todo modularizado e outros módulos poderiam ser facilmente acoplados a

163

ele. Seria viável a adaptação deste software para uma aplicação via web.

O carregador de módulos e o processador de scripts são nossa contribuição para futuras fe rramentas d idáticas visando nexibilidade. portabilidade e expansibilidade. A utilização deste recurso poderia abranger todo o simulador adic ionando novos padrões de comunicação, novas dimensões de execução e configurações de entrada e saída.

Futuras ferramentas devem buscar uma interface amigável com o usuário e os módulos dinâmicos permitem a tradução do software com grande faci lidade. vencendo barreiras nacionais e educacionais.

5. Referências

[t J Patterson, David A. "Organização e projeto de computadores: A interface Hardware/Software". L TC - Ri o de Janeiro. 2000.

121 Hcnnessy. John L; Patte rson. David A. "Computcr Architcture: A Quantitative Approach". second Edition. Morgan Kaufman. 1996.

13] Martins, Carlos A. P. S., et. ai."A New Learning Method of Micropocessor Architeture". 32nd ASEE/EEE Fronticrs in Education Conference 2002 - FIE 2002, Boston 2002. pp. SI Fl 6-S I F21.

[4] Costa. Alexandra S.; Pousa. Christiane V.; Martins. Carlos A. P. S. "Projeto e desenvolvimento de um simulador de memória cachc: análise funcional e de desempenho". 111 Workshop em Sistemas Computacionais de Alto Desempenho WSCAD'2002. 2002. pp. 152- 153.

[51 Sun Microsystems. "The Source for Java Technology". <http://ava.sun.com >.(Acesso: I I /09/03)

(6] Grünbacher H., "Xcache32". Institui für Technische lnformatik, Vienna University of Technology <http://www.ecs.tuwien.ac.atl >(Acesso: 11109/03)

[7] Edler, J.; Hill, M.D., " Dinero IV Trace-Driven Uniprocessor Cache Simulator", Computer Science Dpt. University of Winscosin, <ht tp://www .cs. wisc.cdu/- markhiii/Di ncrolV> (Acesso: 11 /09/03)