In che modo l'architettura ARM differisce da x86? [chiuso]


192

L'architettura x86 è appositamente progettata per funzionare con una tastiera mentre ARM prevede di essere mobile? Quali sono le differenze chiave tra i due?


37
A meno che l'x86 non abbia una porta ps / 2 che non conosco, non è più costruito per le tastiere di un paio di mutande sporche :-)
paxdiablo,

6
Penso che la tastiera si riferisca a un tipico ruolo del PC rispetto al dispositivo fisico.
rumore senza arte

24
Il x86 non è stato progettato; Si è evoluto su un'isola, con uno strano uccello che ha mangiato tutto ciò che ha cercato di pregare su di essa. Ora sembra più strano di un ornitorinco becco d'anatra, e non farebbe bene se arrivasse una nave piena di nuovi animali.
ctrl-alt-delor,

5
@richard - purtroppo, questa è la descrizione storicamente più accurata di x86 che abbia mai visto. Dice molto sull'industria.
Leeor,

6
@Leeor Mi dispiace di aver fatto un piccolo errore nel mio commento, ho detto che l'uccello ha mangiato i predatori del x86, dove non li ha mangiati, si è seduto su di loro. È anche degno di nota che le morbide piume dell'uccello erano così molto, molto ordinate.
ctrl-alt-delor

Risposte:


306

ARMè un'architettura RISC (Reduced Instruction Set Computing) mentre x86è un'architettura CISC (Complex Instruction Set Computing).

La differenza principale tra quelli in questo aspetto è che le istruzioni ARM funzionano solo sui registri con alcune istruzioni per il caricamento e il salvataggio dei dati dalla / alla memoria, mentre x86 può operare direttamente anche sulla memoria. Fino a quando v8 ARM era un'architettura nativa a 32 bit, favorendo operazioni a quattro byte rispetto ad altre.

Quindi ARM è un'architettura più semplice, che porta a una piccola area di silicio e molte funzionalità di risparmio energetico, mentre x86 diventa una bestia in termini di consumo energetico e produzione.

Informazioni sulla domanda " architettura x86 è appositamente progettata per funzionare con una tastiera mentre ARM prevede di essere mobile? ". x86non è appositamente progettato per funzionare con una tastiera né ARMper dispositivi mobili. Tuttavia, ancora una volta a causa delle scelte architettoniche fondamentali, in realtà x86 ha anche istruzioni per lavorare direttamente IOmentre ARM no. Tuttavia, con bus IO specializzati come USB, anche queste necessità stanno scomparendo.

Se hai bisogno di un documento da citare, questo è ciò che la Guida dei programmatori serie Cortex-A (4.0) racconta delle differenze tra le architetture RISC e CISC:

Un processore ARM è un processore RISC (Reduced Instruction Set Computer).

I processori CISC (Complex Instruction Set Computer), come x86, dispongono di un ricco set di istruzioni in grado di eseguire operazioni complesse con una singola istruzione. Tali processori hanno spesso quantità significative di logica interna che decodificano le istruzioni della macchina in sequenze di operazioni interne (microcodice).

Le architetture RISC, al contrario, hanno un numero inferiore di istruzioni più generiche, che potrebbero essere eseguite con un numero significativamente inferiore di transistor, rendendo il silicio più economico e più efficiente dal punto di vista energetico. Come altre architetture RISC, i core ARM hanno un gran numero di registri generici e molte istruzioni vengono eseguite in un singolo ciclo. Ha modalità di indirizzamento semplici, in cui tutti gli indirizzi di caricamento / archiviazione possono essere determinati dal contenuto del registro e dai campi di istruzione.

La società ARM fornisce anche un articolo intitolato Articolo di sviluppo di architetture, processori e dispositivi che descrive come tali termini si applicano al loro business.

Un esempio di confronto tra l'architettura del set di istruzioni:

Ad esempio, se avessi bisogno di una sorta di blocco di confronto di memoria bytewise nell'applicazione (generato dal compilatore, saltando i dettagli), ecco come potrebbe apparire su x86

repe cmpsb         /* repeat while equal compare string bytewise */

mentre nella ARMforma più breve potrebbe apparire (senza controllo errori ecc.)

top:
ldrb r2, [r0, #1]! /* load a byte from address in r0 into r2, increment r0 after */
ldrb r3, [r1, #1]! /* load a byte from address in r1 into r3, increment r1 after */
subs r2, r3, r2    /* subtract r2 from r3 and put result into r2      */
beq  top           /* branch(/jump) if result is zero                 */

che dovrebbe darti un suggerimento su come le serie di istruzioni RISC e CISC differiscono nella complessità.


9
ARMv8-A ha un'architettura a 64 bit chiamata AArch64.
kyrias,

9
Sebbene x86 abbia alcune istruzioni molto potenti, il braccio può comunque batterlo in un combattimento (se entrambi hanno la stessa velocità di clock). Ciò è in parte dovuto al fatto che il braccio ha un buon set di registri, dove mentre x86 impiega 1/2 del suo tempo a spostare i dati dentro e fuori dal suo set limitato di registri (questo è meno vero per x86-64, se ha più registri? ). E in parte perché la semplicità di Arm lascia spazio a una cache più grande e ha tutte le istruzioni condizionate (riducendo la perdita di cache). Inoltre, l'istruzione multipla di arm's move (l'unica istruzione non RISC) consente di spostare rapidamente i dati.
ctrl-alt-delor

4
Potrei scrivere codice ARM più velocemente, anche se più grande, usando più registri. Se guardo a questa implementazione l'x86 impiega 5 + 9 × N clock, il ARM prende 4 × N clock (entrambe le cifre sono per mancare di cache). Il punteggio x86 è migliore per i byte di istruzione in questo esempio: x86 = 2 byte, arm = 16 byte. ARM ottiene punteggi molto migliori su questa metrica in test più realistici, ad esempio all'uscita dal loop r2 avrà informazioni su se le stringhe sono uguali / che è più grande, quindi condizioneranno i codici. Il braccio può eseguire altre istruzioni prima di verificare i codici delle condizioni. Il braccio non deve diramarsi quando si controllano i codici delle condizioni.
ctrl-alt-delor

2
@JeremyFelix Sembra questo stackoverflow.com/questions/13106297/… Esistono diverse pipe per diversi tipi di istruzioni, anche se duplicate. La CPU divide le istruzioni in micro istruzioni e quelle possono essere eseguite in parallelo tra la pipeline.
auselen,

2
Dici "mentre x86 può operare anche direttamente sulla memoria." tuttavia per l'x86 (pre x86-64), ha così pochi registri che non esiste un "pure", è necessario memorizzare tutto in memoria; circa ½ delle istruzioni in un programma in cui solo per spostare le cose. Mentre in ARM sono necessarie pochissime istruzioni per spostare i dati.
ctrl-alt-delor,

94

Né ha nulla di specifico per la tastiera o il cellulare, a parte il fatto che per anni ARM ha avuto un vantaggio piuttosto sostanziale in termini di consumo energetico, che lo ha reso attraente per tutti i tipi di dispositivi a batteria.

Per quanto riguarda le effettive differenze: ARM ha più registri, supporta la previsione per la maggior parte delle istruzioni molto prima che Intel l'abbia aggiunta e ha da tempo incorporato ogni tipo di tecnica (chiamale "trucchi", se preferisci) per risparmiare energia quasi ovunque potesse.

C'è anche una notevole differenza nel modo in cui le due istruzioni codificano. Intel utilizza una codifica di lunghezza variabile abbastanza complessa in cui un'istruzione può occupare da 1 a 15 byte. Ciò consente ai programmi di essere piuttosto piccoli, ma rende relativamente difficile la decodifica delle istruzioni (come in: la decodifica rapida delle istruzioni in parallelo è più simile a un incubo completo).

ARM ha due diverse modalità di codifica delle istruzioni: ARM e THUMB. In modalità ARM, puoi accedere a tutte le istruzioni e la codifica è estremamente semplice e veloce da decodificare. Sfortunatamente, il codice della modalità ARM tende ad essere abbastanza grande, quindi è abbastanza comune per un programma occupare circa il doppio della memoria del codice Intel. La modalità pollice tenta di mitigarlo. Utilizza ancora una codifica di istruzioni abbastanza regolare, ma riduce la maggior parte delle istruzioni da 32 bit a 16 bit, ad esempio riducendo il numero di registri, eliminando le previsioni dalla maggior parte delle istruzioni e riducendo l'intervallo di rami. Almeno nella mia esperienza, questo di solito non dà abbastanzatanto denso di codice quanto può ottenere il codice x86, ma è abbastanza vicino e la decodifica è ancora abbastanza semplice e diretta. Una densità di codice inferiore significa che in genere è necessario almeno un po 'più di memoria e (generalmente più seriamente) una cache più grande per ottenere prestazioni equivalenti.

Un tempo Intel puntava molto più sulla velocità che sul consumo energetico. Hanno iniziato a sottolineare il consumo di energia principalmente nel contesto dei laptop. Per i laptop il loro obiettivo di potenza tipico era dell'ordine di 6 watt per un laptop abbastanza piccolo. Più recentemente ( molto più recentemente) hanno iniziato a rivolgersi a dispositivi mobili (telefoni, tablet, ecc.) Per questo mercato, stanno osservando un paio di watt al massimo. Sembra che stiano andando abbastanza bene, sebbene il loro approccio sia stato sostanzialmente diverso da quello di ARM, enfatizzando la tecnologia di fabbricazione in cui ARM ha principalmente enfatizzato la microarchitettura (non sorprende, considerando che ARM vende i progetti e lascia la fabbricazione ad altri).

A seconda della situazione, il consumo di energia di una CPU è spesso più importante del suo consumo di energia. Almeno mentre sto usando i termini, il consumo di energia si riferisce al consumo di energia su una base (più o meno) istantanea. Il consumo di energia, tuttavia, si normalizza per la velocità, quindi se (ad esempio) la CPU A consuma 1 watt per 2 secondi per fare un lavoro e la CPU B consuma 2 watt per 1 secondo per fare lo stesso lavoro, entrambe le CPU consumano lo stesso importo totale di energia (due watt di secondo) per fare quel lavoro - ma con la CPU B, ottieni risultati due volte più velocemente.

I processori ARM tendono a fare molto bene in termini di consumo energetico. Quindi, se hai bisogno di qualcosa che ha bisogno della "presenza" di un processore quasi costantemente, ma in realtà non sta facendo molto lavoro, possono funzionare abbastanza bene. Ad esempio, se stai effettuando videoconferenze, raccogli alcuni millisecondi di dati, li comprimi, li invii, li ricevi da altri, li decomprimi, li riproduci e li ripeti. Anche un processore molto veloce non può passare molto tempo a dormire, quindi per compiti come questo, ARM fa davvero bene.

I processori Intel (in particolare i processori Atom, che in realtà sono destinati ad applicazioni a bassa potenza) sono estremamente competitivi in ​​termini di consumo energetico. Mentre si avvicinano alla massima velocità, consumano più energia della maggior parte dei processori ARM, ma finiscono anche di lavorare rapidamente, in modo che possano tornare a dormire prima. Di conseguenza, possono combinare una buona durata della batteria con buone prestazioni.

Quindi, confrontando i due, devi stare attento a ciò che misuri, per essere sicuro che rifletta ciò che ti interessa sinceramente. ARM fa molto bene con il consumo di energia, ma a seconda della situazione potresti facilmente preoccuparti di più del consumo di energia che del consumo di energia istantaneo.


è per questo ? RISC ha bisogno di più RAM, mentre CISC pone l'accento sulla dimensione del codice più piccola e utilizza meno RAM in generale rispetto a RISC
Waqar Naeem,

La modalità pollice (lunghezza variabile che consente codifiche brevi) non fa differenza ; è così che x86 funziona sempre (ma più, con una lunghezza delle istruzioni che varia da 1 a 15 byte e molto più difficile da decodificare rispetto a Thumb2). La modalità ARM (codifica a larghezza fissa con istruzioni non distruttive a 3 operandi) è la differenza rispetto a x86!
Peter Cordes,

Avere un processore molto più veloce non è di grande aiuto - la videoconferenza potrebbe essere un esempio migliore: una bassa latenza significa che non puoi semplicemente eseguire una raffica di decodifica in un buffer di dimensioni decenti e tornare in uno stato di sospensione profondo o medio . "Race to sleep" è un concetto chiave nel consumo di energia per una quantità fissa di calcolo, dato che le CPU moderne possono risparmiare energia significativa quando sono completamente inattive (orologio fermo, o addirittura spegnere parti del core. O nei dormi più profondi, anche le cache dopo la riscrittura.) ... ed è questo il punto che farai nel prossimo paragrafo, ovviamente. >. <
Peter Cordes il

@PeterCordes: la codifica in modalità pollice non è molto simile alla codifica x86. Sebbene non sia abbastanza regolare come la codifica ARM, è comunque un formato praticamente fisso. L'aumento della densità è in gran parte dovuto all'eliminazione di bit che sono semplicemente usati raramente nella codifica ARM. Ad esempio, praticamente tutte le istruzioni ARM sono condizionate, ma le condizioni vengono utilizzate solo in una percentuale abbastanza piccola del tempo (quindi la maggior parte delle istruzioni THUMB non-branch sono incondizionate).
Jerry Coffin il

@PeterCordes: Hai ragione: la videoconferenza è un esempio migliore - l'ho modificata. Grazie.
Jerry Coffin il

39

In aggiunta al primo paragrafo di Jerry Coffin . Vale a dire, il design ARM offre un consumo energetico inferiore.

L'azienda ARMconcede in licenza solo la tecnologia CPU. Non fanno chip fisici. Ciò consente ad altre aziende di aggiungere varie tecnologie periferiche, in genere chiamate SOC o system-on-chip. Se il dispositivo è un tablet, un telefono cellulare o un sistema di intrattenimento in auto. Ciò consente ai venditori di chip di adattare il resto del chip a una particolare applicazione. Questo ha ulteriori vantaggi,

  1. Riduzione dei costi di bordo
  2. Potenza inferiore (nota 1)
  3. Produzione più semplice
  4. Fattore di forma più piccolo

ARMsupporta i fornitori SOC con AMBA , consentendo agli implementatori SOC di acquistare moduli di terze parti standardizzati; come una Ethernet, controller di memoria e interrupt. Alcune altre piattaforme CPU supportano questo, come MIPS , ma MIPS non è così attento al potere.

Tutti questi sono utili per un design portatile / a batteria. Alcuni sono buoni ovunque. Inoltre, ARMha una storia di dispositivi a batteria; Apple Newton , Organizzatori di Psion . L' infrastruttura del software PDA è stata sfruttata da alcune aziende per creare dispositivi di tipo smart phone . Tuttavia, un maggior successo è stato ottenuto da coloro che hanno reinventato la GUI per l'uso con uno smartphone .

L'aumento dei Open sourceset di strumenti ha operating systemsanche facilitato i vari SOCchip. Un'organizzazione chiusa avrebbe problemi a provare a supportare tutti i vari dispositivi disponibili per ARM. Le due piattaforme cellulari più popolari, Andriod e OSx / IOS, sono basate su sistemi operativi Linux e FreeBSD, Mach e NetBSD . Open Sourceaiuta i SOCfornitori a fornire supporto software per i loro set di chip.

Spero che il motivo per cui x86 sia usato per la tastiera sia evidente. Ha il software e, soprattutto, le persone addestrate a utilizzare quel software. Netwinder è un ARMsistema originariamente progettato per la tastiera . Inoltre, i produttori stanno attualmente cercando ARM64 per il mercato dei server. Potenza / calore è un problema nei data center 24/7.

Quindi direi che l' ecosistema che cresce attorno a questi chip è importante quanto funzionalità come il basso consumo energetico. ARMè alla ricerca di potenza ridotta e prestazioni più elevate da qualche tempo (da metà alla fine degli anni '80) e hanno un sacco di gente a bordo.

Nota 1: i chip multipli necessitano di driver di bus per comunicare tra loro a tensioni e drive noti. Inoltre, in genere chip separati richiedono condensatori di supporto e altri componenti di potenza che possono essere condivisi in un sistema SOC .


22

Il braccio è come un'auto sportiva italiana:

  • Motore ben bilanciato, ottimizzato. Fornisce una buona accelerazione e velocità massima.
  • Inseguimenti, freni e sospensioni eccellenti. Può fermarsi rapidamente, può angolo senza rallentare.

La x86 è come una muscle car americana:

  • Grande motore, grande pompa del carburante. Fornisce un'eccellente velocità massima e accelerazione, ma consuma molto carburante.
  • Freni spaventosi, devi fissare un appuntamento nel tuo diario, se vuoi rallentare.
  • Sterzo terribile, devi rallentare in curva.

In sintesi: l'x86 si basa su un design del 1974 ed è buono in linea retta (ma consuma molto carburante). Il braccio consuma poco carburante, non rallenta per gli angoli (rami).


Metafora finita, ecco alcune vere differenze.

  • Il braccio ha più registri.
  • Arm ha pochi registri per scopi speciali, x86 è tutti registri per scopi speciali (quindi meno roba in movimento).
  • Arm ha pochi comandi di accesso alla memoria, carica solo / registra registro.
  • Il braccio è internamente l'architettura di Harvard, il mio design.
  • Il braccio è semplice e veloce.
  • Le istruzioni del braccio sono architettonicamente a ciclo singolo (eccetto carico / deposito multiplo).
  • Le istruzioni del braccio spesso fanno più di una cosa (in un singolo ciclo).
  • Laddove è necessaria più di un'istruzione Arm, come il looping store e l'incremento automatico dell'x86, l'Arm lo fa ancora in meno cicli di clock.
  • Il braccio ha più istruzioni condizionali.
  • Il predittore del ramo di Arm è banalmente semplice (se incondizionato o all'indietro poi assume il ramo, altrimenti assume il non-ramo), e funziona meglio di quello molto molto complesso in x86 (non c'è abbastanza spazio qui per spiegarlo, non che potrei ).
  • Arm ha un set di istruzioni semplice e coerente (è possibile compilare manualmente e apprendere rapidamente il set di istruzioni).

7
Questa analogia si interrompe al fatto che le auto sportive italiane si rompono in ogni istante che possono ottenere mentre le CPU ARM non lo fanno e che, sebbene possa essere fatto facilmente, non è possibile acquistare una singola CPU ARM in grado di raggiungere velocità della CPU desktop , figuriamoci con socket e schede madri per inserirle. :)
Evi1M4chine

1
Per quanto riguarda le prestazioni, compete direttamente con alcuni dei processori Xeon più grandi / più veloci (ad es. E5-2690 v3), ma a costi e potenza inferiori. quora.com/…
ctrl-alt-delor

1
Per carichi di lavoro estremamente paralleli come database e server I / O, sicuramente. Per prestazioni a thread singolo, nessuno ha progettato un core ARM ovunque vicino quanto x86. Nessun motivo per cui non potevano, proprio nessuno lo ha fatto. La "tassa x86" sull'area di alimentazione e die non è così grande rispetto alla quantità di silicio utilizzata per i macchinari fuori servizio nei core di CPU ad alta potenza. Ci sono certamente verruche in x86, ma RISC ha uno svantaggio di densità del codice (che di solito non importa molto, ma importa comunque). Questo viene discusso ripetutamente sui forum di realworldtech.com .
Peter Cordes,

1
@richard: ci sono molte cose di cui non "hai bisogno", ma che aumentano la densità del codice. Il trucco sta nel bilanciare la complessità della decodifica con la dimensione del codice / il numero di istruzioni. Aumentare l'ampiezza di un nucleo fuori servizio è estremamente costoso in termini di consumo energetico, quindi è prezioso impacchettare più lavoro in ciascuna istruzione. Un piccolo aumento della complessità della decodifica è molto più economico. Le moderne CPU x86 riescono già a decodificare rapidamente x86. (Non abbastanza in fretta da mantenere un core di OOO a 4 larghezze alimentato dai decodificatori invece di uop-cache o buffer di loop, e ovviamente ad un alto costo di potenza.)
Peter Cordes,

3
@ Evi1M4chine, si rompe anche il fatto che un'auto sportiva italiana è enormemente costosa, mentre un'auto muscolare americana è relativamente economica. E la muscle car è quella che è perché è semplice, mentre qualcosa come una Ferrari è molto molto complicata. Piuttosto il contrario di CISC contro RISC
Lorenzo Dematté,

15

L'architettura ARM è stata originariamente progettata per i personal computer Acorn (vedi Acorn Archimedes , circa 1987 e RiscPC ), che erano altrettanti personal computer basati su tastiera quanto i modelli di PC IBM basati su x86. Solo le implementazioni ARM successive sono state principalmente rivolte al segmento di mercato mobile e embedded.

Inizialmente, semplici CPU RISC con prestazioni approssimativamente equivalenti potevano essere progettate da team di ingegneri molto più piccoli (vedi Berkeley RISC ) rispetto a quelli che lavorano allo sviluppo x86 di Intel.

Al giorno d'oggi, tuttavia, i chip ARM più veloci dispongono di unità di invio di istruzioni fuori servizio multi-problema molto complesse progettate da grandi team di ingegneri e i core x86 possono avere qualcosa come un core RISC alimentato da un'unità di traduzione delle istruzioni.

Pertanto, eventuali differenze attuali tra le due architetture sono più correlate alle esigenze specifiche del mercato delle nicchie di prodotto che i team di sviluppo stanno prendendo di mira. (Opinione casuale: ARM probabilmente incrementa i costi delle licenze dalle applicazioni integrate che tendono ad essere molto più limitati in termini di potenza e costi. Intel ha bisogno di mantenere un vantaggio prestazionale in PC e server per i loro margini di profitto. In questo modo si notano diverse ottimizzazioni dell'implementazione.)


Ci sono ancora enormi differenze architettoniche. Tuttavia Intel ha fatto un ottimo lavoro e ha investito un sacco di soldi, per far funzionare molto bene la CPU scarsamente progettata (ci si chiede cosa si sarebbe potuto fare se tutto questo sforzo fosse stato messo in una CPU ben progettata).
ctrl-alt-delor,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.