Cosa c'è di così bello in ARM?

In un commento a questa risposta Kortuk chiede quale sia il vantaggio ARM . Ho prima aggiunto alcuni argomenti nella mia risposta, ma penso che la domanda sia abbastanza interessante da essere una domanda in sé, in modo che siano possibili più risposte.

Le prestazioni sono un vantaggio. Essendo un processore a 32 bit, supera (quasi) tutti i controller a 8 bit DMIPS. Il nucleo ha anche attraversato diverse generazioni, leggere le ottimizzazioni.
Queste ottimizzazioni mostrano non solo i numeri delle prestazioni, ma anche i consumi energetici . Il core più recente ha raddoppiato il suo rapporto DMIPS / mW rispetto alla generazione precedente (vedi anche questa risposta ).
ARM è disponibile da molti produttori , più di qualsiasi altro microcontrollore, e ognuno ha un numero di versioni tra cui scegliere, con diverse combinazioni di periferiche e memoria su chip e pacchetti. Caso in questione: NXP offre non meno di 35 controller con Ethernet su chip .
ARMs sonoeconomico ; ARM è stato probabilmente il primo controller a 32 bit a infrangere la barriera USD 1.

Questa combinazione di prestazioni , ampia offerta e basso costo lo rende tale da non poter semplicemente ignorare ARM:

Nel 2005 circa il 98 percento di tutti i telefoni cellulari utilizza almeno un core progettato da ARM sulle loro schede madri, secondo una ricerca della società di analisi Linley Group. ( fonte )

Anche il mercato della telefonia mobile ha un altro effetto. I telefoni cellulari sono molto limitati dallo spazio e richiedono piccoli pacchetti. LPC1102 di NXP è disponibile in un pacchetto WLP-16 di soli 5 mm , una scala precedentemente utilizzata solo da microcontroller a 8 bit a basso numero di pin.$^2$

Un punto non ancora menzionato: nel 1908, un ragazzo di nome PL Robertson inventò una nuova testa e un cacciavite migliorati . Voleva essere l'unica persona a produrre viti e driver per il suo design. Decenni dopo, qualcun altro di nome Henry F. Phillips ha escogitato un design alternativo . A differenza del signor Robertson, il signor Phillips era più interessato a concedere in licenza il suo design che a produrre viti e driver.

Allo stesso modo, negli anni '70, la Sony sviluppò una tecnologia chiamata Betamax ; JVC ne ha inventato uno chiamato VHS. Sony era interessata alla produzione di videoregistratori; JVC era più interessato alle licenze.

Sembra esserci uno schema qui. (Nota: per un certo periodo, Intel ha concesso in licenza la sua tecnologia 80x86 , ma per decenni si è concentrata maggiormente sullo sviluppo di tecnologie per il suo uso interno.)

1. Stesso hardware / software da sviluppare per ARM di tutti i fornitori. Acquistate JLINK / ULINK e alcuni IDE Keil una volta, e potete usarlo per sviluppare, emulare ed eseguire il debug di quasi tutti i ARM su un pianeta.

2. Non è necessario apprendere nuove architetture quando si passa a un nuovo fornitore di chip => meno blocco del fornitore => maggiore concorrenza => prezzi più bassi

3. Nei moderni processi tecnologici (0,18 um e inferiori) il core ARM è così piccolo che sacrificarlo per core a 8 bit non risparmierebbe una frazione visibile di un prezzo. Da qui il motivo di optare per un'architettura standard ad alte prestazioni ma economica.

4. Prestazioni: solo con ARM è possibile avere un clock multiplo 32 * 32-> 32 e supporto hardware per 32 * 32-> 64 e divisione per dispositivi sub-1dollar (ad esempio, gli STM32 di fascia bassa, ad esempio)

5. ARM non è troppo avido e non addebita commissioni irragionevoli per le licenze, quindi i produttori possono produrre micro a buon mercato.

Mi sto concentrando su processori ARM di fascia media per questi motivi:

1. Supporto completo per Linux

   Ciò significa che i driver di dispositivo sono quasi gratuiti. Ho fatto abbastanza host USB e codice dispositivo, non voglio più farlo. Io non sono anche troppo entusiasta di cercare di aggiungere il protocollo TCP / IP per una piattaforma del processore casuale (anche se LwIP / uIP non è poi così male). Non ho mai nemmeno provato a fare il Wi-Fi, un vero stack Bluetooth, le webcam, ecc. L'uso di Linux significa che una vasta gamma di dispositivi diventa molto più facile parlare.

   Sono stato anche davvero sorpreso da quanto sia razionale e facile scrivere driver di dispositivi Linux. Dopo aver eseguito alcuni driver di dispositivo Windows, Linux è un sogno. (Ad essere onesti, il framework dei driver di Windows è migliorato molto da quando lo facevo.)

   Anche la piattaforma software è fantastica. Ottengo crittografia SSL, filesystem, gestione remota, facili aggiornamenti delle applicazioni (copia un file anziché un bootloader complesso), ecc. Oh, e molte utility esistenti se hai bisogno di fare qualcosa.

   È anche privo di royalty e molto più facile da piegare alla tua volontà che dire che sarebbe una piattaforma WinCE a sorgente chiuso . (Non che io sia davvero un idealista open source ... è tutto un ragionamento molto pratico per me.)

   Sto parlando di core ARM con MMU effettivi , quindi questo è per i chip di fascia medio-alta (anche se si potrebbe usare μClinux, suppongo).

2. Consumo di energia

   Questa è sostanzialmente una ripetizione dei commenti degli altri, ma è un grande fattore per me. La mia attuale piattaforma ARM a 454 MHz assorbe 1/2 watt, 1 watt alla CPU massima. Non puoi nemmeno avvicinarti a questo con x86.

Questo è praticamente il mio ragionamento. Non vedo l'equazione cambiare presto.

Il ARM ha subito una progressione:

1. Un'architettura con istruzioni a 32 bit, che aveva un codice più voluminoso rispetto a molte altre architetture, ma che poteva essere decodificata rapidamente e poteva eseguire molte operazioni con meno istruzioni rispetto alle architetture concorrenti
2. Un'architettura in formato a doppia istruzione, che potrebbe alternare tra il set di istruzioni ARM bello e potente (ma purtroppo un po 'gonfio) e un set di istruzioni "Thumb" a 16 bit meno potente (ma molto più compatto). Ogni istruzione Thumb aveva un'istruzione ARM corrispondente, minimizzando in qualche modo la necessità per i programmatori di apprendere due set di istruzioni.
3. Un'architettura Thumb2, che ha aggiunto istruzioni di due parole al set di istruzioni Thumb, producendo ciò che è per lo più un win-win: il tipico codice ARM conterrebbe un mix di istruzioni che erano disponibili solo nel ARM, e istruzioni che sarebbero state disponibili in Thumb ma doveva comunque essere rappresentato come 32 bit; in Thumb2, tale codice ottiene i vantaggi in termini di spazio della sostituzione di alcune delle istruzioni a 32 bit con quelle a 16 bit.
4. Un'architettura solo per il pollice, che è più limitante di quanto mi piacerebbe, ma che è più piccola ed economica di tutte le altre.

L'architettura ARM consente di eseguire alcune operazioni piuttosto sofisticate molto rapidamente, molto più rapidamente rispetto a qualsiasi altro chip. Ad esempio (utilizzando ARM7-TDMI):

  ldrh r0, [r10, # ADDR_BUS_OFS]; Lettura bus indirizzo sistema di destinazione (13 bit)
  ldrb r1, [r9, r0, lsr # 8]; Utilizzare i bit superiori per cercare l'indirizzo in una tabella di gestori
  aggiungi pc, r9, r1 lsl # 2; Vai al gestore appropriato

Ogni gestore è memorizzato come byte, che fornisce 1/4 dello spostamento dell'indirizzo dall'inizio della tabella. L'effetto netto è che una volta recuperati i contenuti del bus degli indirizzi, sono necessari solo sei cicli (due istruzioni) per passare a un gestore basato sui cinque bit superiori del recuperato, utilizzando una tabella di salto a 32 byte.

Il codice THUMB corrispondente sarebbe più simile a:

; Supponendo che non abbiamo bisogno di r6 / r7 per nient'altro, sono riassegnati da r9 / r10
  ldrh r0, [r7, # ADDR_BUS_OFS]
  mov r1, r0
  lsr r1, r1, # 8; THUMB richiede che la sorgente e la destinazione siano uguali
  ldrb r1, [r6, r1]
  lsl r1, r1, # 1; Potrebbe usare shift-left-two, se gli indirizzi target fossero allineati a una parola intera
  aggiungi pc, r1

Va bene dal punto di vista della densità del codice, dato che le istruzioni sono grandi solo la metà degli originali, ma richiederebbero nove cicli dopo il recupero anziché sei. In un'applicazione in cui il bus monitorato funzionerà alla propria velocità indipendentemente dal fatto che ARM sia riuscito a gestirlo, le istruzioni ARM più veloci sono un grande vantaggio.

Per inciso, Thumb2 è binario compatibile con Thumb, il che facilita l'uso di strumenti precedenti, ma significa che ci sono alcune cose che non può fare così come il ARM originale. Ad esempio, in ARM, si potrebbe "ruotare" una bitmap 8x8 contenuta in quattro registri usando circa 3 istruzioni per due bit:

  mov r0, r4, lsl # 25; Inserisci il bit superiore di LSB in C e il bit successivo in N
  orrcs r6, # 0x00000001
  orrmi r6, # 0x00000100

In Thumb2, sarebbe necessario aggiungere istruzioni condizionali esplicite:

  mov r0, r4, lsl # 25; Inserisci il bit superiore di LSB in C e il bit successivo in N
  ITC
  orrcs r6, # 0x00000001
  ITMI
  orrmi r6, # 0x00000100

Riduzione netta del 33% in termini di tempo ed efficienza dello spazio rispetto a ARM; questo è probabilmente un esempio nel caso peggiore in cui il codice Thumb sia meno efficiente di ARM, e anche questo non è esattamente orribile.

Un altro piccolo svantaggio di Thumb2 rispetto a ARM: nel codice ARM, tutte le istruzioni iniziano a confini di parole intere, facilitando l'analisi statica. In Thumb2, le istruzioni possono iniziare arbitrariamente a limiti di mezza parola e a cavallo di limiti di parole intere. L'analisi statica può quindi essere molto più difficile.

Un po 'è storia, Acorn voleva una CPU personalizzata (ad esempio con controlli di memoria integrati, ecc.) Per un nuovo computer negli anni '80 (l'8 bit 6502 stava limitando ciò che potevano fare). Parlarono con Intel, ma Intel non avrebbe concesso loro la licenza di una CPU.

Così Acorn ha progettato una CPU RISC molto semplice, ma poiché non erano un produttore di CPU, erano disposti a concederla in licenza a chiunque (e avevano bisogno di tutti i soldi veloci che potevano ottenere!). (Credo che la CPU abbia funzionato per la prima volta, in parte perché era così semplice e anche il progettista ha creato molte CPU di ricerca durante la Cambridge University.)

Nel corso degli anni il design della CPU è diventato sempre più facile da includere nella progettazione dei chip dei clienti.

Il produttore di chip si è sentito sicuro delle licenze di Acorn in quanto non erano concorrenti. Inoltre nessuno pensava che sarebbero andati nella città natale di un concorrente per ottenere una licenza, dato che Acorn era a Cambridge (quello vero!) . (La possibilità di un viaggio di "accertamento dei fatti" a Cambridge per visitare Acorn ha influenzato la messa a corto di elenchi di opzioni in qualsiasi momento ...)

Molti dei progetti che includono la CPU Acorn Risc Machine erano per il sistema di incorporamento in cui il consumo di energia era importante. Sono stati creati anche strumenti di sviluppo economici e buoni per la CPU della macchina Acorn Risc.

Quindi, quando i telefoni cellulari hanno iniziato a richiedere chip personalizzati con una CPU integrata, Acorn è stato rinominato ARM e il resto è storia. (Forse è stato anche un po 'che le altre CPU erano principalmente controllate dagli Stati Uniti, ma i cellulari sono diventati normali in Europa)

(Qualcuno di questi ti ricorda Microsoft e Dos con un piccolo team sconosciuto di IBM?)

Il fatto che l'ARM fosse una delle migliori CPU del momento (e lo è ancora) per molte attività ha aiutato anche - ma avere il design "migliore" della CPU non è sufficiente.

Problemi tecnici a parte, ci sono molte ragioni non tecniche per ARM. Ma la risposta rapida è questa: non è Intel (o x86).

Se guardi dove vengono investiti i dollari di R&S della CPU in questo momento, essi rientrano sostanzialmente in due campi: ARM e Intel. (Sto ignorando i piccoli MCU e sto inserendo AMD con Intel.) Ci sono pochissimi soldi in PowerPC, MIPS, SPARC e altre CPU di grandi dimensioni. ARM e Intel sono gli unici rimasti in piedi.

Con Intel e altre CPU x86 ottieni un'enorme quantità di bagaglio legacy. Ad esempio, hai bisogno di un chipset, un BIOS e altre cose. Anche se la CPU era ad alta efficienza energetica, quegli altri dispositivi tendono a appesantire il sistema e renderlo più grande, più affamato di energia e più costoso. Lo sviluppo di un PCB con una CPU Intel è un grosso problema, quindi devi negoziare con un fornitore del BIOS, ecc. Per peggiorare le cose, molti dei fornitori di chipset, BIOS, chip video, ecc. Semplicemente non vogliono fare affari con i piccoli che non venderanno meno di un milione di unità all'anno.

Con ARM, non hai quel bagaglio. Esistono molte fonti di chip, dai microcontrollori ai mostri multi-core. Non è necessario occuparsi della licenza di un BIOS (che è molto simile a un venditore di auto usate). E i produttori e i venditori sono generalmente gentili con te.

Confronta ARM7 / ARM9 con MIPS IV e ci sono pochi vantaggi oltre ai problemi di licenza già ben menzionati. Gli interni del set di istruzioni MIPS e il bus interno lo rendono superiore (prestazioni per costo) per alcuni tipi di progetti; motivo per cui molti router Wi-Fi utilizzano core MIPS anziché core ARM.

Poiché i core ARM sono stati applicati principalmente ai dispositivi portatili, gli ASIC hanno aggiunto più funzioni di controllo della potenza, mentre il MIPS si concentra maggiormente sulle prestazioni per ciclo piuttosto che sulla potenza inferiore. Il vantaggio di RISC su Intel x86 è una discussione diversa.

Non ci sono vantaggi reali. DSP collegato e altri controller, come il GSM, sono ciò che li rende così popolari.