RAM ARM. putz

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

Mensagempor msamsoniuk » 19 Out 2009 19:33

arm e pic nao dao nem para o comeco meo! olhae um 68000 debulhando:

http://www.youtube.com/watch?v=0wcWejOAMNU

proex escreveu:
Marcelo Samsoniuk escreveu:entao nao pode usar cada byte da flash/ram do arm com uma funcao diferente de dados e codigo? que lixinho de processador hein...

fabim escreveu:OBS>:
OS LPC´s.
TEM a RAM de dados, e de programa.
A RAM de programa, é como se fosse uma continuação da flash, ou seja o interpretador olha esta ram, como se fosse uma flash.
A ram de dados, é ram de dados ora raios.

Eu tinha confundido a bagaça..



Sim, é um lixo, Eu tambem estou decepcionado com ARM, vou voltar para o PIC 16F84, é muito melhor. Quem sabe até eu aprenda a mexer com o 68000 de 64 pinos DIP, isso sim é processador.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor MarcusPonce » 19 Out 2009 19:52

Pois é, tentar ler um int em qualquer endereço que não seja múltiplo de 4 mesmo em um ARM9 rodando LINUX pode ser realmente interessante.

Acontece que o hardware do ARM9 só vai fazer um único acesso à memória com data bus de 32 bits. Se fosse a leitura de um só byte em qualquer endereço funcionaria sem problemas pois o hardware alinharia o que foi lido, mas um int desalinhado como na função acima não será lido corretamente, por default.
Porém no LINUX podemos escolher o que vai acontecer, existe um ajuste para isso: se desejarmos ler ints em qualquer endereço vai disparar uma exceção quando estiver desalinhado e o problema é resolvido via Linux mesmo, lendo a memória em dois acessos e montando corretamente o int. Portanto, depois de ligar o ajuste, as funções acima vão funcionar corretamente.

Realmente é mais lento que um x86, o qual faria isso no hardware. Porém o mais rápido mesmo (para ambos) é deixar que o compilador alinhe as variáveis ints em endereços múltiplos de 4.
MarcusPonce
Byte
 
Mensagens: 166
Registrado em: 12 Fev 2007 13:58
Localização: Campinas - SP

Mensagempor msamsoniuk » 19 Out 2009 21:43

bom, o 68000 tem essa restricao de alinhamento para operandos e isso nunca foi problema...o povo da intel ateh tentou argumentar na epoca q isso piorava a performance, mas no fim das contas era o contrario. a restricao do 68000 migrou para o x86 quando os compiladores migraram junto e hoje o gcc gera todos os operandos alinhados mesmo no x86.
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Mensagempor vtrx » 19 Out 2009 22:50

marcelo,o 68000 é um processador para sistemas,ja os Pics e afins são µc para sistemas embarcados.
Sou fão do MC68000,pois não achei ainda subistituo,digo,preço baixo,ainda em fabricação,ótimo set de instruções.
Os X86 usam memória seguimentada que eu detesto,acho que foi isso que 'amarrou 'o PC por muito tempo...
Avatar do usuário
vtrx
Dword
 
Mensagens: 2239
Registrado em: 20 Abr 2008 21:01

Mensagempor tcpipchip » 20 Out 2009 07:32

Quanto 'a memória segmentada, eu lembro que tivemos uma dor de cabeça tremenda quando tentamos montar uma plaquinha com core x86....

O problema foi resolvido com o 80188XL, que incluia um decoder interno, mas com CS/ externos representando páginas de memória.

Ai ficava mais fácil...durante o RESET do processador, pulava para o SEGMENTO FFFF offset 0, ou seja, o endereço físico FFFF0, ai o decoder forçava o CS/ (de boot) para low, onde habilitavamos uma EPROM na época.

Usavamos o barramento de dados de 8 Bits e de endereço 16 bits...não os 20 bits.

TCPIPCHIP
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 6560
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Anterior

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x