PIC32 x ARM

[tcpipchip]

> Someone can make a comparison between the architectures of the
> ARM7 and PIC32?

For all intents and purposes, they are the same. Minor wrinkles are that
ARM has predicated instructions and MIPS has more registers (hence context
switching can be slower). They both have compact instruction sets for
narrow flash and smaller programs (Thumb/MIPS16). Carry is difficult on
MIPS and MIPS will potentially abort on integer overflow. MIPS has delay
slots, ARM not.

Paul Curtis
CROSSWORKS

[Fábio Pereira]

Bom,

Eu não acho que sejam tão similares não. Os PIC32 são muito mais avançados que os ARM7, eles possuem um conjunto de instruções muito mais rico, permitem fazer multiplicação e divisão por hardware, manipulação direta de bits, além de outras operações que não estão disponíveis no conjunto de instruções ARMv4.

Além disso, os PIC32 possuem 32 registradores de 32 bits (contra os 16 disponíveis num modo ARM).

Acho que a comparação real deve ser entre os Cortex-M3 e PIC32, aí sim temos uma certa equivalência (pelo menos das funcionalidades básicas do conjunto de instruções).

Acredito que a Microchip terá uma tarefa árdua no que diz respeito a aceitação do PIC32 no mercado, pois trata-se de uma arquitetura poderosa mas bastante complexa. Claro que a utilização de ferramentas de alto nível tende a minizar o esforço de programação, mas ainda assim acredito que a programação dos PIC32 seja bastante mais complexa que as demais linhas da Microchip.

Neste ponto, ainda não vi nada mais simples do que os Coldfire v1 da Freescale: a facilidade de portar código de um chip de 8 bits (HCS08) para outro de 32 bits (CFv1) é resumida simplesmente a se clicar no botão TARGET do Codewarrior e selecionar a plataforma desejada. Fiz essa experimentação com alguns exemplos do meu livro HCS08 Unleashed escritos para o MC9S08QE128. Bastou mudar o target para o MCF51QE128, recompilar a aplicação e pronto, a aplicação estava rodando em uma plataforma de 32 bits !

T+

[Viktor]

Fabio

Tem certeza qto à divisão por hardware ? O ARM7 também tem instrução de multiplicação e a manipulação direta de bits é, até onde sei, em determinados registradores dos periféricos, o que também existe em ARMs como por exemplo LPCxxxx. O conjunto de registradores maior é realmente, numa primeira analise, uma vantagem, porém a vantagem do conjunto de instruções, a não ser que você programe em assembly, é mais dependente do compilador usado numa primeira análise.

[proex]

Antes de qualquer coisa, acho que para a Microchip conseguir algum sucesso com o PIC32, primeiramente ela tem que coloca-lo no mercado.

Até lá, os ARM já terão dominado ainda mais.

Logo logo, ARM de 200MIPS já serão coisas corriqueiras.

[xultz]

Ué, e já não são? Eu tenho umas plaqunhas em casa já que têm uns 4 anos de idade, com PXA255 que rodam a 400MHz...

[Viktor]

o pic32 tem mesmo divisão por hw

[msamsoniuk]

o problema da ausencia de interlock das instrucoes continua presente nestes cores mips ? quem usa pic hoje, adora programar em asm e quer migrar para mips jah ouviu falar nessa historia ?

[proex]

Bem, eu só programo PIC em Assembler mas nunca ouvi falar nesse tal de interlock. O que seria isso? Talvez eu conheça por outro nome.

Para mim, a grande diferença entre ARM e PIC32 é que o primeiro, encontra-se a venda.

[msamsoniuk]

bom, eh uma historia meio longa mas...

qualquer processador moderno processa uma instrucao em uma sequencia de eventos internos, que chamamos de pipeline, eh tipo uma linha de montagem. vc tem q buscar a instrucao, decodificar um endereco fonte, por exemplo, puxar o operando, tratar o operando e fazer alguma coisa com esse operando. tudo isso faz parte de uma instrucao e cada estagio consome, digamos, um ciclo de clock. entao uma unica instrucao consome varios ciclos! como vc poderia encolher isso ? bom, vc poderia ter varias instrucoes entrando pelo pipeline como em uma linha de montagem, cada uma defasada um clock da outra, assim quando uma instrucao estivesse buscando um operando, outra estaria usando a alu e outra estaria armazenando o operando.

em um exemplo simples, se vc tiver 5 estagios, vc pode ter 5 instrucoes encaminhadas dentro deles e obter 5 resultados em 5 clocks. se o pipeline estiver sempre cheio, vc vai obter o pico de aproximadamente 1 instrucao por clock... o problema eh que as vezes uma instrucao precisa de um operando q esta em uso por outra instrucao, por exemplo, uma instrucao MUL D0,D1 e outra ADD D2,D1, se ambas estao no pipeline, eh de se esperar que um ADD consiga terminar antes de um MUL, mesmo que tenha entrado depois no pipeline! para evitar isso ativam-se automaticamente interlocks q param o pipeline ateh que o resultado esteja disponivel. isso causa uma queda de performance e vc comeca a nao ter aquela relacao de 1 instrucao por 1 clock...

a mips resolveu isso eliminando os interlocks. entao quando se compila algo, o compilador automaticamente reordena as instrucoes de modo que a instrucao ADD vai entrar lah embaixo, bem depois da instrucao MUL ter disponivel o resultado. no meio, ele simplesmente sobe coisas q nao ativam interlocks e que podem ser colocadas em qualquer posicao. com isso vc garante que chega perto de 1 instrucao para 1 clock a maior parte do tempo, aproveitando totalmente o pipeline do processador, em contrapartida torna a ordenacao das instrucoes altamente especializada, ou seja, vc depende de um compilador que conheca profundamente o processador e saiba como se safar da ausencia de interlock.

bom, as coisas existem pq tem um diferencial nao eh ? se o processador mips nao tem mais o diferencial da ausencia de interlock (o q torna impossivel a programacao manual em asm), realmente o destino dele eh ser esquecido e ir para a lata do lixo! sobrevive soh quem tem algum diferencial ou eh muito importante...

[Viktor]

Marcelo

Tanto o ARM como o MIPS tem esse problema e o compilador não pode garantir que isso não vá acontecer. Esse problema eu conheó como STALL.

[Fábio Pereira]

Pelo que li a respeito os interlocks dos MIPS são feitos por hardware há bastante tempo. São estes interlocks por hardware que provocam o STALL que o Viktor mencionou (a paralisação da execução devido à espera por uma unidade de execução que ainda não completou sua tarefa).

T+

[Viktor]

Além disso se não fosse feito por hardware (o tal intelock) o programa teria que ser preenchido com NOPs em diversos pontos ou coisa parecida, portanto é imperativo que esta solução tenha que ser feita por hardware, como aliás , é normalmente feita em todos os microcontroladores onde isto se verifica, portanto é difícil entender o tal referencial ao que o Marcelo se refere, já que todos eles tem este mecanismo que provoca o STALL qdo o dado solicitado na instrução não está disponível

[jeanfernandes]

Traduzindo...
É como o Proex falou...
Até sair no mercado ou chegar aqui...
Só loko vai pensar em usar....
Concordo com o Fábio em parte sobre a arquitetura...
Só que...
6 ou 12 meses esperando algo não poe feijao à mesa.

[Fábio Pereira]

Bom,

Eu não estava defendendo o PIC32 ...

Atualmente, em matéria de 32 bits, tenho preferido trabalhar com os Coldfire V1, pois é extremamente simples migrar as nossas aplicações de 8 bits (HCS08) para 32 bits (CFv1).

Além disso, ainda não vi um sistema de depuração melhor que o dos Coldfire/HCS08.

T+

[mastk]

Dois entre ARM e PIC32 eu fico com Coldfire...