se vc usar uma memoria FLASH com tempo de acesso de 60ns, por exemplo, e largura do bus igual a largura das instrucoes (32 bits no ARM e 16 bits no CF), vc vai ter um bandwidth para apenas 16 MIPS. mas um core ARM ou CF rodando a 167 MHz deveria conseguir atingir 167 MIPS, o que significa que temos uma diferenca de 10x.
bom, como nao tem milagre, a primeira vez que o core passar por determinado segmento de codigo ele nao tem o que fazer a nao ser inserir wait-states e rodar efetivamente a 16 MIPS. mas com isso ele aproveita e copia as instrucoes para a cache, assim na proxima vez que rodar este codigo, ele vai rodar a 167MIPS.
a primeira vista parece estranho pq a cache eh muito menor que a memoria! no caso do sistema CF tipico, temos 8KB de cache para algo da ordem de 4MB de FLASH e 8MB de SDRAM, uma diferenca de 1000x e isso indicaria que a probabilidade de acerto seria de 1 em 1000, certo? na verdade nao. para comeco de conversa, a cache nao mapeia simplesmente uma janela de 8KB. ela mapeia multiplas janelas de 16 bytes. isto significa que ela pode mapear 512 pequenas janelas independentes, que podem estar bem espalhadas pela memoria. junte isso ao fato da maioria do codigo ser orientada a pequenos loops e vc tem condicoes ideais para ter um elevado indice de acertos.
mas o negocio nao fica soh nisso, pq alem de instrucoes, vc pode cachear dados. neste caso vc tira vantagem nas escritas tambem, que podem ser do tipo write-back: o processador grava na cache e entao a cache transfere para a memoria externa mais lentamente. se vc gravar e ler em seguida, nao tem galho, pq vc vai ler da cache.
finalmente, a vantagem adicional de ter caches de instrucoes e dados separadas eh que vc consegue ter um core com arquitetura de harvard e o dobro do bandwidth, ou seja, acesso a dados na memoria nao impactam na performance.
bom, daih tem tambem os lados negativos. no caso do CF nao existe espaco para IO separado e as caches interferem no funcionamento de perifericos. eh facil de imaginar com um exemplo simples: vc entra em um loop lendo um flag de um periferico... porem na primeira leitura o flag acabou ficando cacheado! daih vc fica preso no loop. ah sim, e da mesma forma que isso falha com um periferico, pode falhar com uma variavel compartilhada entre duas threads.
para prevenir isso, existem dois descritores de pagina no CF, um para mapear a cache de instrucoes e outra para a cache de dados. com isso vc consegue separar areas para a atuacao de cada cache, de modo que nao mapeie a area de IO. e para resolver problemas de comunicacao interprocesso, eh comum usar a memoria SRAM interna para essa funcao. como ela opera com zero wait-states, nao eh necessario incluir ela na cache.
bom, essa eh a essencia do negocio :)
fabim escreveu:Samsonite.
Me explica uma coisa.
Eu ainda não tive oportunidade de mexer com nada além de 112mhz, que deu de sobra pro que eu necessitava.
Sendo assim, não tive a necessidade de pegar coisa barruda pra mexer, sendo assim não conheci a memoria cache na pratica.
Lendo seu post, à cima, eu vi que você disse que o cache aumenta o processamento por um fator de até 10X. Como assim ? eu tentei entender mais não consegui.
Pode me explicar esse negocio de cache, e velocidade de execução aumentada ?
beijunda
E isso tudo pra duas dimensões, imagina pra 3? Não, não imagina não, senão vc vai ter pesadelos hehehe