Qual è la differenza tra l'architettura ARM e il RISC regolare?

RISC è il termine che Dave Patterson ha coniato (erroneamente in realtà) per un modo di progettare i processori a set di istruzioni (ISP) dopo aver letto gli articoli di John Cocke e aver studiato il sistema IBM ACS (più in un minuto). Le due idee principali sono che il processore torna a caricare e memorizzare e se si semplifica e si riduce il numero delle istruzioni necessarie per implementare un processore, i progettisti possono rendere il flusso di dati all'interno del processore più veloce e quindi ne risulterà un sistema più veloce. ARM (precedentemente Advanced RISC Machine, originariamente Acorn RISC Machine), segue principalmente questo stile di progettazione, quindi secondo la definizione di Dave, sono sistemi RISC.

Risposta più lunga. Cocke non ha mai suggerito di ridurre il numero di istruzioni - questa è stata la conclusione di Dave dalla lettura dei suoi articoli, e il concetto centrale dell'architettura Berkeley RISC-I è costruito. Quello che Cocke dice, parafrasando, è "esponiamo il micro-motore del processore sotto le coperture e lasciamo che il compilatore generi il codice per il micro-motore". Se esponiamo il micro-motore saremo più veloci perché il compilatore avrà solo bisogno di generare operazioni per le unità funzionali che abbiamo man mano che sono pronte. Niente sarà sprecato."

Ma significa anche che il compilatore dovrà essere consapevole di come funziona il flusso di dati e tenerne conto quando ordina le istruzioni (cioè quali possono essere sovrapposte, come le 'istruzioni in volo' sono portate a 'completamento' (ritirate nel micro-motore). **

FWIW: Il sistema MIPS di Stanford era più vicino alle idee di Cocke che il processore originale UCB RISC-I. Nel progetto originale MIPS, non ci sono "stalli" o "blocchi" implementati nelle pipeline delle istruzioni - il compilatore doveva stare attento a non tentare di usare un risultato che non era ancora completamente calcolato.

Questa è l'idea centrale nel dibattito RISC vs. CISC. Più complesso è il set di istruzioni, più interazioni ci sono tra le diverse istruzioni. Più profonda è la pipeline (cioè più istruzioni "parziali") che vengono calcolate in parallelo, più attenzione deve essere posta. Ma se si riesce a farlo, il processore accelererà.

C'è stato così tanto dibattito sull'argomento, e l'idea ha preso vita dopo gli articoli originali di Dave; all'interno dell'industria si scherzava sul fatto che tutti i sistemi progettati dopo il 1980 erano sistemi RISC - per definizione. ;-)

La ragione della battuta è che il termine stesso è per lo più privo di senso quando si apre il processore stesso e ci si sbircia dentro (stile RISC classico o CISC classico come un Intel*64). Tutti i processori moderni non sono né l'uno né l'altro in quanto sono macchine a 'flusso di dati' all'interno - Dataflow Architecture. Questo è ciò che li rende veloci e anche ciò che li rende difficili da progettare. Qualsiasi set di istruzioni 'esterne' venga scelto, che sia Intel*64, ARMv8, RISC-V, MIPS, DEC's Alpha, o tornando indietro all'IBM 360/90 e all'ACS - queste istruzioni 'esterne' sono decodificate, poi i componenti delle istruzioni sono 'programmati' all'interno dei diversi registri interni e unità funzionali che compongono il processore. Molte, molte di queste istruzioni di alto livello sono operate allo stesso tempo e sono in diverse posizioni "in volo".

Una buona analogia per pensarci è un modo non dissimile dallo scavo americano del canale di Panama. Tre diverse operazioni sono avvenute allo stesso tempo (lato Atlantico, lato Pacifico, e Culebra Cut). Ognuno di essi utilizza attrezzature simili e per lo più indipendenti, ma condividono una ferrovia, il "bottino" dei diversi siti di scavo sarà usato per costruire una grande diga o per rompere le acque, quindi c'è anche interdipendenza. I motori a corrente non possono scavare roccia e terra, se non ci sono vagoni vuoti per portare il materiale di scarto, ecc. E poi il materiale di scarto deve essere programmato per andare nel luogo in cui sarà utilizzato o in un'area di smaltimento. Penso che abbiate capito l'idea. Il punto è che un master scheduler ha il compito di tenere tutto occupato. BTW, hai anche cose come colate di fango e terremoti (cose inaspettate in un processore come interrupts o eccezioni) quindi lo scheduler deve essere abbastanza flessibile da gestire l'ignoto. Ma se metti troppa 'flessibilità' diventa inefficiente e rallenta.

Un'architettura a flusso di dati funziona proprio così. Facciamo un lavoro parziale e mettiamo in cache il risultato in modo da poterlo usare velocemente, oppure buttiamo via le cose se non sono necessarie. Noi 'ritiriamo' le operazioni nell'ordine in cui le cose sono pronte nel flusso di dati, il che significa che potremmo non essere in grado di iniziare qualche operazione se dipendiamo da qualche altro risultato [pensateci, un treno merci vuoto deve restituire la pala del flusso per portare via la terra da una corsa precedente. Se è ancora in uso, la grande e costosa pala del torrente è inattiva].

I processori hanno risorse costose, lente e limitate, per esempio gli adders, il barrel shifter, e simili (le macchine a vapore che fanno lo scavo). I registri interni sono quei treni merci, devono essere pronti quando lo siamo noi o le costose risorse non saranno utilizzate al meglio.

Perciò torniamo alla tua domanda... ARMv8, Intel*64, et al sono tutte macchine per il flusso di dati all'interno del processore stesso - ecco perché l'argomento RISC vs. CISC ha perso di significato. All'interno di questi chip sono tutti più simili che diversi e come avete visto dal recente exploit GPZ, tutti i sistemi moderni hanno quel particolare problema (come ho detto ereditato da un'idea architettonica di IBM di fine anni '60). Ciò che li rende diversi sono le loro architetture di set di istruzioni (ISA) definite esternamente.

Per rispondere in modo specifico alla tua domanda, l'ISA di ARMv8 segue principalmente uno schema load/store come descritto nei documenti di Dave, e quindi, è per definizione un'architettura 'RISC'. Ma la verità è che l'ISA ARMv8 supporta anche funzioni complesse, non molto diverse dai cosiddetti chip CISC come Intel*64.

** Questa, a proposito, è la chiave degli attuali attacchi di Google Project Zero, noti anche come Meltdown e Spectre, che risalgono tutti al documento IBM ACS, quando la predizione dei rami e l'esecuzione speculativa furono proposti per la prima volta.

Aggiornato il 2/12/18 per correggere un paio di errori di battitura.