O que há de tão bom no ARM?

Em um comentário a esta resposta, Kortuk pergunta qual é a vantagem do BRAÇO . Acrescentei alguns argumentos em minha resposta, mas acho que a pergunta é interessante o suficiente para ser uma pergunta em si mesma, para que mais respostas sejam possíveis.

O desempenho é uma vantagem. Por ser um processador de 32 bits, ele supera (quase) todos os controladores de 8 bits em termos de DMIPS. O núcleo também passou por várias gerações, leia otimizações.
Essas otimizações não são apenas exibidas em números de desempenho, mas também no consumo de energia . O núcleo mais recente dobrou sua proporção DMIPS / mW em comparação com a geração anterior (consulte também esta resposta ).
O ARM está disponível em muitos fabricantes , mais do que em qualquer outro microcontrolador, e cada um tem várias versões para escolher, com diferentes combinações de periféricos no chip, memória e pacotes. Caso em questão: o NXP oferece nada menos que 35 controladores com Ethernet no chip .
BRAÇOS sãobarato ; O ARM foi provavelmente o primeiro controlador de 32 bits a quebrar a barreira dos US $ 1.

Essa combinação de desempenho , ampla oferta e baixo custo faz com que você simplesmente não possa ignorar o ARM:

Em 2005, cerca de 98% de todos os telefones celulares usam pelo menos um núcleo projetado para ARM em suas placas-mãe, de acordo com pesquisa da empresa de analistas Linley Group. ( fonte )

$^2$

Um ponto ainda não mencionado: em 1908, um cara chamado PL Robertson inventou uma nova cabeça e chave de fenda melhoradas . Ele queria ser a única pessoa a fabricar parafusos e chaves para seu projeto. Décadas depois, alguém chamado Henry F. Phillips apresentou um design alternativo . Ao contrário de Robertson, Phillips estava mais interessado em licenciar seu projeto do que em produzir parafusos e chaves.

Da mesma forma, na década de 1970, a Sony criou uma tecnologia chamada Betamax ; JVC veio com um chamado VHS. A Sony estava interessada em produzir videocassetes; A JVC estava mais interessada em licenciamento.

Parece haver um padrão aqui. (Observação: por algum tempo, a Intel licenciou sua tecnologia 80x86 , mas há décadas se concentra mais no desenvolvimento de tecnologias para uso interno.)

1. O mesmo hardware / software a ser desenvolvido para ARMs de todos os fornecedores. Você compra o JLINK / ULINK e algum Keil IDE uma vez e pode usá-lo para desenvolver, emular e depurar praticamente qualquer ARM do planeta.

2. Não é necessário aprender uma nova arquitetura ao mudar para um novo fornecedor de chips => menos bloqueio de fornecedores => mais concorrência => preços mais baixos

3. Nos processos tecnológicos modernos (0,18um e abaixo), o núcleo do ARM é tão pequeno que sacrificá-lo pelo núcleo de 8 bits não economizaria nenhuma fração visível do preço. Daí a razão de optar pela arquitetura padrão de alto desempenho e barata.

4. Desempenho - somente com o ARM você pode ter 32 * 32-> 32 de clock único e suporte de hardware para 32 * 32-> 64 e divisão para dispositivos sub-1dollar (ou seja, STM32 de extremidade inferior, por exemplo)

5. O ARM não é muito ganancioso e não cobra taxas não razoáveis ​​pelas licenças, para que os fabricantes possam produzir micros baratos.

Estou focado em processadores ARM de gama média por estes motivos:

1. Suporte completo ao Linux

   Isso significa drivers de dispositivo quase de graça. Já fiz bastante host USB e código de dispositivo, não quero mais fazer isso. Também não estou muito empolgado em tentar adicionar TCP / IP a uma plataforma de processador aleatório (embora LwIP / uIP não seja tão ruim). Eu nunca tentei fazer Wi-Fi, uma pilha Bluetooth real, webcams, etc. Usar o Linux significa que uma variedade muito ampla de dispositivos se torna muito mais fácil de conversar.

   Também fiquei realmente impressionado com o quão racional e fácil é escrever drivers de dispositivo Linux. Depois de fazer alguns drivers de dispositivo Windows, o Linux é um sonho. (Para ser justo, a estrutura do driver do Windows melhorou muito desde que eu estava fazendo isso.)

   A plataforma de software também é incrível. Recebo criptografia SSL, sistemas de arquivos, gerenciamento remoto, atualizações fáceis de aplicativos (copie um arquivo em vez de um carregador de inicialização complexo), etc. Ah, e muitos utilitários existentes, se você precisar de algo.

   Também é isento de royalties e muito mais fácil de se adaptar à sua vontade do que seria uma plataforma WinCE de código fechado . (Não que eu seja realmente um idealista de código aberto ... é tudo um raciocínio muito prático para mim.)

   Estou falando de núcleos ARM com MMUs reais , então isso é para chips de médio a alto nível (embora você possa usar o μClinux , suponho).

2. Consumo de energia

   Isso é basicamente uma repetição dos comentários de outros, mas é um grande fator para mim. Minha plataforma ARM atual de 454 MHz consome 1/2 a watt, 1 watt na CPU máxima. Você nem pode se aproximar disso com o x86.

Esse é o meu raciocínio. Não vejo a equação mudando tão cedo.

O ARM passou por uma progressão:

1. Uma arquitetura de instruções de 32 bits, que possuía código mais volumoso do que muitas outras arquiteturas, mas que poderia ser decodificada rapidamente e realizar muitas operações com menos instruções do que as arquiteturas concorrentes
2. Uma arquitetura de formato de instrução dupla, que pode alternar entre o conjunto de instruções ARM agradável e poderoso (mas infelizmente um pouco inchado) e um conjunto de instruções "Thumb" de 16 bits menos poderoso (mas muito mais compacto). Cada instrução Thumb tinha uma instrução ARM correspondente, minimizando um pouco a necessidade dos programadores aprenderem dois conjuntos de instruções.
3. Uma arquitetura Thumb2, que adicionou instruções de duas palavras ao conjunto de instruções Thumb, produzindo o que é em geral uma situação em que todos saem ganhando: o código ARM típico conteria uma mistura de instruções que só estavam disponíveis no ARM e instruções que estariam disponíveis no Thumb mas teve que ser representado como 32 bits de qualquer maneira; no Thumb2, esse código obtém os benefícios de espaço de substituir algumas das instruções de 32 bits pelas de 16 bits.
4. Uma arquitetura somente Thumb, que é mais limitadora do que eu gostaria, mas que é menor e mais barata que qualquer outra.

A arquitetura ARM permite que algumas operações bastante sofisticadas sejam executadas muito rapidamente - muito mais rapidamente do que em qualquer outro chip. Por exemplo (usando o ARM7-TDMI):

  ldrh r0, [r10, # ADDR_BUS_OFS]; Leia o barramento de endereço do sistema de destino (13 bits)
  ldrb r1, [r9, r0, lsr # 8]; Use bits superiores para procurar endereços em uma tabela de manipuladores
  adicione pc, r9, r1 lsl # 2; Vá para o manipulador apropriado

Cada manipulador é armazenado como um byte, que fornece 1/4 do deslocamento do endereço desde o início da tabela. O efeito líquido é que, uma vez que o conteúdo do barramento de endereços foi buscado, são necessários apenas seis ciclos (duas instruções) para pular para um manipulador com base nos cinco bits superiores dos recuperados, usando uma tabela de salto de 32 bytes.

O código THUMB correspondente seria mais como:

; Supondo que não precisamos de r6 / r7 para mais nada, eles são reatribuídos a partir de r9 / r10
  ldrh r0, [r7, # ADDR_BUS_OFS]
  mov r1, r0
  LSR R1, R1, # 8; THUMB requer que a origem e o destino sejam os mesmos
  ldrb r1, [r6, r1]
  LS1 R1, R1, # 1; Poderia usar shift-left-two, se os endereços de destino estivessem alinhados com a palavra completa
  adicionar pc, r1

Tudo bem do ponto de vista da densidade de código, já que as instruções são apenas metade do tamanho dos originais, mas levariam nove ciclos após a busca, em vez de seis. Em um aplicativo em que o barramento sendo monitorado funcionará em sua própria velocidade, independentemente de o ARM ter gerenciado ou não, as instruções mais rápidas do ARM são uma grande vantagem.

Aliás, Thumb2 é binário compatível com Thumb, o que facilita o uso de ferramentas anteriores, mas significa que existem algumas coisas que ela não pode fazer tão bem quanto o ARM original. Por exemplo, no ARM, era possível "rotacionar" um bitmap 8x8 mantido em quatro registradores usando cerca de 3 instruções por dois bits:

  movs r0, r4, lsl # 25; Coloque o bit superior do LSB em C e o próximo bit em N
  orrcs r6, # 0x00000001
  orrmi r6, # 0x00000100

No Thumb2, seria necessário adicionar instruções condicionais explícitas:

  movs r0, r4, lsl # 25; Coloque o bit superior do LSB em C e o próximo bit em N
  itcs
  orrcs r6, # 0x00000001
  itmi
  orrmi r6, # 0x00000100

Redução líquida de 33% na eficiência de tempo e espaço em comparação com o ARM; é provavelmente o pior exemplo de código Thumb menos eficiente que o ARM, e mesmo isso não é exatamente horrível.

Uma outra pequena desvantagem do Thumb2 em comparação com o ARM: no código ARM, todas as instruções começam nos limites da palavra completa, facilitando a análise estática. No Thumb2, as instruções podem iniciar arbitrariamente nos limites da meia palavra e ultrapassar os limites da palavra completa. A análise estática pode, portanto, ser muito mais difícil.

Um pouco da história, a Acorn queria uma CPU personalizada (por exemplo, com controles de memória embutidos etc.) para um novo computador na década de 1980 (o 6502 de 8 bits estava limitando o que eles podiam fazer). Eles conversaram com a Intel, mas a Intel não licenciou uma CPU para eles.

Portanto, a Acorn projetou uma CPU RISC muito simples, mas como eles não eram fabricantes de CPUs, estavam dispostos a licenciá-la para qualquer pessoa (e precisaram de todo o dinheiro rápido que pudessem obter!). (Acredito que a CPU funcionou pela primeira vez, em parte porque era muito simples e também o designer criou muitas CPUs de pesquisa na Universidade de Cambridge.)

Ao longo dos anos, o design da CPU se tornou cada vez mais fácil de incluir no design do chip do cliente.

O fabricante de chips sentiu o licenciamento seguro da Acorn por não serem concorrentes. Também ninguém pensou que eles estavam indo para a cidade natal de um concorrente para obter uma licença, pois a Acorn estava em Cambridge (a verdadeira!) . (A chance de uma viagem de "descoberta de fatos" a Cambridge para visitar a Acorn influencia a lista de opções a qualquer momento ...)

Muitos dos projetos que incluem a CPU da Acorn Risc Machine eram para o sistema de incorporação, quando o uso de energia era importante. Ferramentas de desenvolvimento baratas e boas também foram criadas para a CPU da Acorn Risc Machine.

Então, quando os telefones celulares começaram a precisar de chips personalizados com uma CPU incorporada, a Acorn foi renomeada para ARM e o resto é história. (Talvez também tenha sido um pouco o fato de as outras CPUs serem controladas principalmente pelos EUA, mas os celulares se tornaram normais na Europa)

(Isso lembra a Microsoft e o Dos com uma pequena equipe desconhecida da IBM?)

O fato de o ARM ser uma das melhores CPUs da época (e ainda é) para muitas tarefas também ajudou - mas apenas ter o "melhor" design da CPU não é suficiente.

Questões técnicas à parte, existem muitas razões não técnicas para o ARM. Mas a resposta rápida é a seguinte: não é Intel (ou x86).

Se você observar onde os dólares de P&D em CPU estão sendo investidos no momento, eles se enquadram basicamente em dois campos: ARM e Intel. (Estou ignorando pequenos MCUs e estou agregando a AMD à Intel.) Há muito pouco dinheiro investido em PowerPC, MIPS, SPARC e outras grandes CPUs. ARM e Intel são os únicos que ainda estão de pé.

Com a Intel e outras CPUs x86, você recebe uma enorme quantidade de bagagem herdada. Por exemplo, você precisa de um chipset, um BIOS e outras coisas. Mesmo que a CPU tenha uma super eficiência energética, esses outros dispositivos tendem a sobrecarregar o sistema e torná-lo maior, com mais consumo de energia e mais caro. Desenvolver um PCB com uma CPU Intel é um grande problema, e você precisa negociar com um fornecedor de BIOS etc. Para piorar a situação, muitos fornecedores de chipsets, BIOSs, chips de vídeo etc. simplesmente não querem negociar com pessoas pequenas que não vendem menos de um milhão de unidades por ano.

Com o ARM, você não tem essa bagagem. Existem muitas fontes de chips, desde itens da linha de microcontroladores até monstros de vários núcleos. Você não precisa lidar com o licenciamento de um BIOS (que é como ir a um vendedor de carros usados). E fabricantes e fornecedores geralmente são bons para você.

Compare o ARM7 / ARM9 ao MIPS IV e há pouca vantagem além dos problemas de licenciamento já mencionados. As partes internas do conjunto de instruções MIPS e do barramento interno o tornam superior (desempenho por custo) para certos tipos de projetos; é por isso que muitos roteadores Wi-Fi usam núcleos MIPS em vez de núcleos ARM.

Como os núcleos do ARM foram aplicados principalmente aos dispositivos portáteis, os ASICs adicionaram mais recursos de controle de energia, enquanto o MIPS se concentra mais no desempenho por ciclo, em vez de menos energia. O benefício do RISC sobre o Intel x86 é uma discussão diferente.

Não há vantagens reais. DSP conectado e outros controladores, como o GSM, são o que os tornam tão populares.