Codici operativi ISA --- Da dove vengono?

Quando gli ingegneri progettano un'architettura di set di istruzioni, secondo quale procedura o protocollo, se ne verificano, seguono quando designano determinati codici binari come istruzioni. Ad esempio, se ho un ISA che dice 10110 è un'istruzione di caricamento, da dove proviene quel numero binario? È stato modellato da una tabella di stato per una macchina a stati finiti che rappresenta un'operazione di caricamento?

Modifica: dopo aver fatto ulteriori ricerche, credo che ciò che sto cercando di chiedere riguardi come vengono assegnati gli opcode per le varie istruzioni della CPU. ADD potrebbe essere designato con un codice operativo di 10011; un'istruzione di caricamento potrebbe essere designata come 10110. Quale processo di pensiero passa nell'assegnazione di questi codici binari per il set di istruzioni?

In molti casi, la scelta è piuttosto arbitraria o basata su "ovunque si adatti meglio" man mano che gli ISA crescono nel tempo. Tuttavia, il MOS 6502 è un meraviglioso esempio di chip in cui il design ISA è stato fortemente influenzato dal tentativo di spremere il più possibile da transistor limitati.

Guarda questo video che spiega come il 6502 è stato progettato al contrario , in particolare da 34:20 in poi.

Il 6502 è un microprocessore a 8 bit introdotto nel 1975. Sebbene avesse il 60% di porte in meno rispetto allo Z80, era due volte più veloce e sebbene fosse più vincolato (in termini di registri, ecc.), Compensò quello con un set di istruzioni elegante.

Contiene solo 3510 transistor, che sono stati disegnati a mano da una piccola squadra di persone che strisciava su alcuni grandi fogli di plastica che successivamente sono stati ridotti otticamente, formando i vari strati del 6502.

Come puoi vedere di seguito, il 6502 passa il codice operativo dell'istruzione e i dati di temporizzazione nella ROM di decodifica, quindi li passa in un componente "logica di controllo casuale" il cui scopo è probabilmente quello di sovrascrivere l'output della ROM in determinate situazioni complesse.

Alle 37:00 nel video puoi vedere una tabella della ROM di decodifica che mostra quali condizioni devono soddisfare gli ingressi per ottenere un "1" per un dato output di controllo. Puoi trovarlo anche su questa pagina .

Puoi vedere che la maggior parte delle cose in questa tabella ha X in varie posizioni. Prendiamo ad esempio

011XXXXX 2 X RORRORA

Ciò significa che i primi 3 bit del codice operativo devono essere 011 e G deve essere 2; Non importa nient'altro. In tal caso, l'uscita denominata RORRORA diventerà vera. Tutti i codici operativi ROR iniziano con 011; ma ci sono altre istruzioni che iniziano anche con 011. Questi probabilmente devono essere filtrati dall'unità "random control logic".

Quindi, in sostanza, sono stati scelti gli opcode in modo che le istruzioni che dovevano fare la stessa cosa l'una con l'altra avessero qualcosa in comune attraverso il loro modello di bit. Puoi vederlo guardando una tabella di codici operativi ; tutte le istruzioni OR iniziano con 000, tutte le istruzioni Store iniziano con 010, tutte le istruzioni che utilizzano l'indirizzamento a pagina zero sono nel formato xxxx01xx. Naturalmente, alcune istruzioni non sembrano "adattarsi", perché l'obiettivo non è di avere un formato di codice operativo completamente regolare, ma piuttosto di fornire un potente set di istruzioni. Ed è per questo che era necessaria la "logica di controllo casuale".

La pagina che ho menzionato sopra dice che alcune delle linee di output nella ROM appaiono due volte: "Supponiamo che questo sia stato fatto perché non avevano modo di instradare l'output di una linea dove volevano, quindi hanno messo la stessa linea in un altro posizione di nuovo ". Posso solo immaginare gli ingegneri che disegnano a mano quei cancelli uno per uno e improvvisamente realizzano un difetto nel design e provano a trovare un modo per evitare di riavviare l'intero processo.

Dipende da quanti anni ha l'ISA.

All'inizio della progettazione manuale, e ancora di più quando le CPU erano assemblate da una logica discreta, la progettazione logica sarebbe venuta prima, e sarebbe stata ampiamente minimizzata, e quindi i pattern di bit ISA sarebbero stati tutti i valori necessari per rendere quel minimo lavoro logico.

Quindi potrebbe esserci un particolare schema di segnali di controllo che consente ad alcuni multiplexer di collegare l'uscita ALU all'input del file di registro GP, alcuni segnali di controllo in più che indicano all'ALU di aggiungere, sottrarre, AND, OR ecc. E alcuni indirizzare i bit nel file di registro. Questi tre gruppi di segnali formeranno campi all'interno dell'istruzione. Ogni gruppo verrà tenuto insieme e il loro significato dettagliato deriva dal progetto per quell'unità (ALU ecc.) Ma i gruppi possono essere in qualsiasi ordine, fino a quando non si progetta il decodificatore delle istruzioni. (x86 è abbastanza vecchio da poterne rilevare un po 'se guardi nel posto giusto - non era un design totalmente nuovo, ma attingeva al vecchio 8080)

Gli ISA successivi possono essere "ripuliti" e resi più regolari e più semplici da utilizzare, con l'hardware da tradurre tra loro e i segnali di controllo a livello hardware effettivo, a volte tramite "microcodice". Questi sono chiamati "CISC" o "Codifica set di istruzioni complesse". Il prefisso dell'istruzione "Rep" x86 ne è un semplice esempio: fa sì che le seguenti istruzioni vengano ripetute più volte, per evitare di dover scrivere un ciclo FOR.

Più tardi (negli anni '80) tornò a un semplice stile di codifica diretta (RISC - Reduced Instruction Set Coding) che puoi vedere nei processori ARM. Ciò era guidato dalle dimensioni ridotte degli ASIC all'epoca e dal desiderio di mettere CPU a 32 bit su di essi, quindi non c'era spazio libero per decodificatori complessi di istruzioni, per portare la CPU completa a circa 20.000 gate. (C'è stato anche un aumento temporaneo delle prestazioni, perché le persone non avevano ancora sviluppato tecniche per rendere veloci i decodificatori CISC - questo è accaduto nel 1995 con il Pentium Pro)

E al giorno d'oggi non importa: le CPU leggono più istruzioni contemporaneamente e dedicano milioni di transistor a decodificarle, riordinarle ed eseguirne il più possibile contemporaneamente, per accelerare i programmi che potrebbero essere stati scritti per i più vecchi stile di ISA.

Se si raggruppano istruzioni simili, emergeranno dei motivi. Questo è molto ovvio in ARM, dove il manuale ISA mostra effettivamente quale bit di una parola di istruzione corrisponde alla funzione, alla scelta del registro, ecc. Ma può anche essere dedotto per X86 .

Alla fine, la parte "funzione" degli opcode arriva in un decodificatore binario a uno che attiva effettivamente una particolare funzione o sequenza di operazioni pipeline. Di solito non sono correlati al contenuto di nessuna macchina a stati, a meno che non stiamo prendendo in considerazione istruzioni a lunghezza variabile che richiedono una macchina a stati per decodificare.

Qualcuno ad un certo punto si è seduto e li ha definiti.

Un buon ISA renderà il decoder il più semplice possibile.

Ad esempio con un'istruzione ALU è possibile inviare alcuni bit del codice operativo direttamente nelle linee di controllo dell'ALU.

In genere, si divide l'ISA in gruppi funzionali. Ha senso (o per l'ottimizzazione della logica o semplicemente per essere in ordine) che le coppie complementari sono differenziate da un singolo cambio di bit (carico vs archivio) e che si dispone di una gerarchia di bit che influisce sull'albero decisionale della decodifica.

Alla fine della giornata, un'allocazione arbitraria di bit per il blocco funzione (invece di posizionare i campi "dati" nell'istruzione avrà solo un piccolo impatto sull'efficienza complessiva del progetto - ma hai molte scelte su come 'ottimizza' la tua codifica ISA in base a ciò che ritieni sia un parametro importante.

La codifica delle istruzioni è un brutto compromesso tra.

Semplificando la decodifica, per questo si desidera un semplice insieme di campi ciascuno dei quali può essere decodificato separatamente e instradato verso una parte separata del motore di esecuzione.

Comprimendo quante più funzionalità possibile in una dimensione limitata della parola dell'istruzione. Questo porta a cose come formati costanti speciali che possono codificare una varietà di numeri comuni.

Compatibilità avanti e indietro. Se si assegna la funzionalità a ogni possibile codice operativo non si dà spazio per espandere l'architettura in un secondo momento. Se si sta aggiungendo un'architettura esistente, è necessario inserire le nuove istruzioni nei codici operativi di riserva.

L'eccellente (se un po 'datato) di Randy Hyde The Art of Assembly si trova nel set di istruzioni x86 in dettaglio nel capitolo 3.3.4 Unità di controllo e set di istruzioni e seguenti.

I programmi nei primi sistemi informatici (pre-Von Neumann) erano spesso "cablati" nei circuiti. Cioè, il cablaggio del computer ha determinato quale problema avrebbe risolto il computer. Uno ha dovuto ricablare i circuiti per cambiare il programma. Un compito molto difficile. Il successivo progresso nella progettazione del computer fu il sistema programmabile, che permise a un programmatore di computer di "ricablare" facilmente il sistema utilizzando una sequenza di prese e cavi. Un programma per computer consisteva in una serie di file di fori (prese), ciascuna delle quali rappresentava un'operazione durante l'esecuzione del programma. Il programmatore può selezionare una delle numerose istruzioni inserendo un filo nella presa specifica per l'istruzione desiderata.

Dimostra quindi abbastanza accattivante e alla lunga come la prima coppia di prese rappresenta l'istruzione, le prese successive codificano sorgente e destinazione. Naturalmente, oggi nessuno "si collega" più, ma per gli ISA veramente vecchi, i bit nell'opcode fanno sostanzialmente lo stesso lavoro dei plugs precedenti.

Si finisce con qualcosa del genere: