Risposte:
TL, DR; Mentre i processori ARM utilizzano concetti simili alle CPU microprogramma (es c'è un blocco hardware che decodifica istruzioni in uno o più micro-operazioni ), essi sono non microprogramma in senso tradizionale che utilizza una ROM per memorizzare ogni micro-istruzione, né queste micro-istruzioni / operazioni possono essere modificate dopo essere state prodotte nell'hardware reale? In effetti, i processori ARM usano il controllo cablato nel decodificatore di istruzione per generare micro-operazioni.
In pratica, tuttavia, la modifica del decodificatore di istruzione può essere simile alla modifica di un processore microcodificato, poiché ARM concede in licenza il codice sorgente del linguaggio di descrizione hardware ( HDL ) delle sue architetture CPU ai singoli produttori, rendendo le modifiche a livello hardware significativamente più facili da implementare. Vedere la sezione Decodificatore di istruzioni nel Wikibook di progettazione a microprocessore per ulteriori differenze tra i decodificatori di istruzioni RISC e CISC tipici.
Sebbene l'architettura ARM stessa non sia microcodificata nel senso tradizionale, le singole istruzioni sono decodificate in micro-operazioni più piccole . Un moderno processore ARM è tutt'altro che "semplice" - sebbene le istruzioni stesse siano molto ortogonali, c'è molta tecnologia moderna (ad esempio pipeline, istruzioni superscalari, esecuzione fuori ordine, memorizzazione nella cache, istruzioni complesse estese come unità a virgola mobile o NEON) che ha un moderno core A9. In effetti, qualsiasi processore può essere abbastanza semplice da eseguire senza la traduzione in micro-operazioni, ma essenzialmente sta mettendo "tutte le uova nello stesso paniere": non è possibile correggere eventuali errata nel set di istruzioni, né espanderlo / modificarlo dopo la produzione.
Tuttavia, se stiamo parlando solo della fase di decodifica delle istruzioni , in effetti molti processori ARM non sono microcodificati in un modo che consente modifiche dopo il fatto, anche se ciò può essere dovuto al fatto che la maggior parte dei produttori che concedono in licenza la tecnologia ARM ha accesso all'effettivo codice sorgente hardware (scritto in un HDL). Ciò riduce il consumo energetico poiché non è necessario uno stadio di microcodice, ma le singole istruzioni vengono "compilate" in blocchi hardware reali. Ciò consente anche la correzione degli errori da parte di ciascun produttore.
Infatti, anche in una CPU basata su CISC (ad es. X86), non è necessario l'uso del microcodice. In pratica, tuttavia, la complessità del set di istruzioni, combinato con varie differenze nelle licenze, nel consumo di energia e nelle applicazioni, rende la scelta del microcodice ideale per il caso di x86. Nel caso di ARM, tuttavia, è meno utile in quanto le modifiche al set di istruzioni (decodificatore) sono molto più facili da implementare e controllare in termini di hardware stesso (in quanto può essere personalizzato dal produttore).
Sebbene avere un microcodice possa effettivamente semplificare la progettazione del processore in alcuni casi (poiché ogni istruzione esiste come un "microprogramma" rispetto all'hardware reale), questo è effettivamente solo un decodificatore di istruzioni (ad esempio l' estensione Thumb-2 , che consente variabili- lunghezza istruzioni esistenti aggiungendo un decodificatore di istruzione separato in linea con il decodificatore di istruzioni ARM). Sebbene funzionalmente queste unità possano essere implementate utilizzando il microcodice, ciò non sarebbe saggio in termini di consumo energetico, poiché è necessario definire l'uscita per ciascun segnale di controllo nella CPU stessa, anche se non necessario. Questo no ha comunque a che fare con la complessità della CPU stessa, dato che i core ARM hanno tutti i costrutti moderni che ci si aspetterebbe (pipelining, cache di istruzioni / dati, buffer micro-TLB, previsione dei rami, memoria virtuale, ecc ... ).
Nel caso di ARM, data l'ortogonalità del set di istruzioni, la complessità implicata nell'implementazione di un tale approccio microcodificato supererebbe i vantaggi della semplice modifica dell'hardware pertinente direttamente nel blocco del decodificatore di istruzione. Sebbene ciò sia certamente possibile, finisce per "reinventare la ruota", per così dire, dato che sei in grado di modificare direttamente (e compilare / testare / emulare) i cambiamenti nell'hardware.
In questo caso è possibile "pensare" al codice sorgente ARM stesso come a un tipo di microcodifica, sebbene invece di memorizzare ogni micro-operazione / micro-programma in una ROM che può essere modificata in seguito, sono implementati direttamente in hardware nel decodificatore di istruzione. Dato che lo stesso decodificatore di istruzioni è scritto in VHDL / Verilog, apportare modifiche alle istruzioni esistenti è semplice come modificare il codice sorgente, ricompilare e testare il nuovo hardware (ad esempio su un FPGA o un simulatore). Ciò contrasta con la complessità del moderno hardware x86, che è molto più difficile da testare / simulare durante lo sviluppo e ancora più difficile da modificare dopo la produzione (poiché le dimensioni in termini di transistor superano di gran lunga ciò che si può eseguire anche all'interno del moderno più costoso FPGA, aggiungendo così un vantaggio all'utilizzo di un negozio di microcodici).hardware fisico utilizzando un FPGA.