[Asm] Progettare una architettura di processore

[cdimauro]

Originariamente inviato da Z80Fan

Non sono un estremista, mi basta che "opcode a lunghezza fissa" significhi "pochi o meglio nessun byte di prefisso o suffisso" (fatta eccezione per i dati immediati). E' per questo che il tuo set mi è piaciuto subito

Grazie.

Un altro vantaggio, rispetto a 68000 e x86, è che dalla decodifica dell'opcode a 32 bit (quello a 16 bit si può sempre vedere come uno a 32 bit, come detto prima) si conosce immediatamente la lunghezza dell'intera istruzione.

Comunque vorrei, sempre per agevolare il decoder, mettere un vincolo alla lunghezza massima di un'istruzione imponendo un massimo di 16 byte (8 word a 16 bit). Attualmente il massimo che si può avere è: opcode a 32 bit + valore immediato a 64 bit + indirizzo assoluto a 64 bit. Non penso che sia una restrizione così grave, perché i casi di istruzioni così lunghe non sono frequenti.

(Poi, tecnicamente, non è detto che un RISC debba avere istruzioni della stessa lunghezza, basta che ogni istruzione sia breve e veloce nell'esecuzione, no?)

La lunghezza, variabile o fissa, degli opcode è proprio LA discriminante fra un CISC e un RISC.

Un altro elemento di netta discriminazione è la presenza delle sole istruzioni di LOAD / STORE per interfacciarsi con la memoria, mentre i CISC permettono di avere istruzioni più complesse (aritmentiche, logiche, ecc.) che possono andare al contempo a leggere / scrivere dalla memoria.

Ma per quello basta una AND a 3 ingressi: se l' and dice di no, allora si possono sparare direttamente i bit nell' opcode direttamente in quelli dello SR, senza bisogno di decodificarli.

Io sono sempre orientato a una LUT per implementare il tutto velocemente e senza pensieri.

Comunque col tuo schema si può effettivamente ricavare la maschera degli IF con pochi gate.

Aspetto con pazienza

Ho aggiornato il primo messaggio con la nuova struttura del registro SR e la spiegazione di come vengono eseguite le istruzione, e il secondo con l'aggiornamento della parte relativa all'istruzione IF.

No no, non mi preoccupavo della religione dell'architettura (), mi preoccupavo come effettivamente implementarla.

Microcodice.

Veramente ho preso ispirazione dalle tue modalità (ops, volevo dire, dalle modalità Motorola ), solo estendendo i campi registro ad un bit in più, in modo da eliminare la distinzione D/A

Sì, ma con opcode a 16 bit ti mangi tutto lo spazio così.

Io con 3 soli bit per i registri ho già la tabella quasi completamente satura (c'è giusto spazio per una decina di istruzioni non dotate di campi).

Edit:
Ops, ho visto ora un'istruzione che mi era sfuggita:

XXX Source EA  *** RESERVED! ***
15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
1    1    1    0    1    1     0    1    1    1   |Source. Mode  |Sour. Reg. |

Bella un'istruzione con solo la sorgente e non la destinazione

Questo è uno spazio che ho lasciato vuoto per un'istruzione a cui serva soltanto un operando che ho supposto essere di sola lettura / sorgente (ma potrebbe essere cambiato in scrittura / destinazione).

Comunque le istruzioni jump hanno tutte una sorgente, ma nessuna destinazione.

Nella letteratura Motorola serve a distinguere in che modo interpretare la modalità d'indirizzamento. Questo perché per la "sorgente" si può sfruttare qualunque modalità, mentre per quella destinazione viene sollevata un'eccezione in presenza di indirizzamento immediato oppure di uno che utilizzi il PC come registro indirizzo.

Edit2: Altra domanda: non si può usare un cmp solo?

In che senso?

Basterebbe solo dopo modificare l'eventuale salto in modo da rispecchiare la differenza degli elementi. A meno che non ci sia qualche codice dove usi un cmp per modificare i flag in modo da variare successive istruzioni (che non siano salti), ma al momento non mi viene in mente nulla.

Negli opcode a 32 bit introdurrò una speciale istruzione di confronto + salto condizionato. Il confronto servirà soltanto per "sbrogliare" il salto, quindi senza modificare i flag.

Inoltre penso a una versione "quick" del confronto + salto, con un valore immediato "corto" (similmente a QCMP, che accetta costanti da -1 a 2).

Questo sempre per includere dei casi comuni e che possono mettere in crisi la pipeline (se un'istruzione deve dipendere dall'analisi dei flag generati da un'altra).

[Z80Fan]

Originariamente inviato da cdimauro

Un altro vantaggio, rispetto a 68000 e x86, è che dalla decodifica dell'opcode a 32 bit (quello a 16 bit si può sempre vedere come uno a 32 bit, come detto prima) si conosce immediatamente la lunghezza dell'intera istruzione.

Comunque vorrei, sempre per agevolare il decoder, mettere un vincolo alla lunghezza massima di un'istruzione imponendo un massimo di 16 byte (8 word a 16 bit). Attualmente il massimo che si può avere è: opcode a 32 bit + valore immediato a 64 bit + indirizzo assoluto a 64 bit. Non penso che sia una restrizione così grave, perché i casi di istruzioni così lunghe non sono frequenti.

Bene, così possiamo provvedere ad un buffer interno di 16 byte, e la seconda lettura a 64 bit viene eseguita durante la decodifica dell'istruzione; sarà poi quest'ultima a dire quanti bit estrarre dal buffer, i rimanenti verranno shiftati in modo da avere già pronta la prossima istruzione.

Originariamente inviato da cdimauro

La lunghezza, variabile o fissa, degli opcode è proprio LA discriminante fra un CISC e un RISC.

Questo perchè tutti i processori risc sono nati così (sempre per semplificare il fetch/decode), ma non è LA principale differenza: nulla vieta di fare un RISC a lunghezza variabile (ovviamente sarebbe una pazzia perchè tutto il tempo risparmiato nelle istruzioni lo perdi nel fetch/decode), e nulla vieta di fare un CISC con opcode a lunghezza fissa (pure i uP moderni sono risc dentro: cisc con una istruzione da 118 bit )

Originariamente inviato da cdimauro

Un altro elemento di netta discriminazione è la presenza delle sole istruzioni di LOAD / STORE per interfacciarsi con la memoria, mentre i CISC permettono di avere istruzioni più complesse (aritmentiche, logiche, ecc.) che possono andare al contempo a leggere / scrivere dalla memoria.

Questo è già più distintivo delle due architetture.

Originariamente inviato da cdimauro

Microcodice.

Il problema è che devo aggiungere logica aggiuntiva per poter eseguire salti condizionati all'interno del microcodice stesso, troppa roba per solo 2 istruzioni; molto meglio creare una unità apposita.

Originariamente inviato da cdimauro

Sì, ma con opcode a 16 bit ti mangi tutto lo spazio così.

Io con 3 soli bit per i registri ho già la tabella quasi completamente satura (c'è giusto spazio per una decina di istruzioni non dotate di campi).

Me ne sono accorto ho dovuto rimuovere le modalità di indirizzamento indiretto in modo da ridurre il bit di scelta modalità a 1 solo...

Originariamente inviato da cdimauro

In che senso?

Nel senso che hai CMP.Size Source EA, Dn e CMP.Size Dn, Destination EA, non basterebbe solo la seconda?

Originariamente inviato da cdimauro

Negli opcode a 32 bit introdurrò una speciale istruzione di confronto + salto condizionato. Il confronto servirà soltanto per "sbrogliare" il salto, quindi senza modificare i flag.

Inoltre penso a una versione "quick" del confronto + salto, con un valore immediato "corto" (similmente a QCMP, che accetta costanti da -1 a 2).

Questo sempre per includere dei casi comuni e che possono mettere in crisi la pipeline (se un'istruzione deve dipendere dall'analisi dei flag generati da un'altra).

Bene. è molto utile poter risolvere tutto con solo un'istruzione.


Cmq, pensavo: ha senso avere l' estensione per le modalità di indirizzamento più complesse? Praticamente l'opcode a 16 bit diventa a 32. Non sarebbe meglio integrare queste istruzioni nella tabella a 32 bit?

[Tommo]

Ho provato a leggere questo thread ma mi è esploso il cervello
Però vi stimo parecchio per la dedizione!

[cdimauro]

Originariamente inviato da Z80Fan

Questo perchè tutti i processori risc sono nati così (sempre per semplificare il fetch/decode), ma non è LA principale differenza: nulla vieta di fare un RISC a lunghezza variabile (ovviamente sarebbe una pazzia perchè tutto il tempo risparmiato nelle istruzioni lo perdi nel fetch/decode), e nulla vieta di fare un CISC con opcode a lunghezza fissa

Beh, nella letteratura informatica la tipologia di opcode è stata sempre considerata la discriminante principale per le due macrofamiglie.

(pure i uP moderni sono risc dentro: cisc con una istruzione da 118 bit )

Questa è una cosa diversa. L'ISA rimane CISC. Mentre l'unità di esecuzione interna è un RISC.

Il problema è che devo aggiungere logica aggiuntiva per poter eseguire salti condizionati all'interno del microcodice stesso, troppa roba per solo 2 istruzioni; molto meglio creare una unità apposita.

Non ho esperienza di design di un'architettura, per cui... va bene così.

Nel senso che hai CMP.Size Source EA, Dn e CMP.Size Dn, Destination EA, non basterebbe solo la seconda?

Il copia & incolla è la principale fonte di bug. La seconda è il sonno. La combinazione dei due, poi, è micidiale.

Grazie per la segnalazione.

A questo punto utilizzo lo spazio della seconda CMP per mappare qui la QMOVEU (così ho una costante a 8 bit a disposizione). Mentre marco come riservato il precedente spazio della QMOVEU, che a questo punto può benissimo mappare un'istruzione tipo la LEA, cioé con un registro e una modalità d'indirizzamento.

Ottimo. Lo spazio nella tabella degli opcode a 16 bit è preziosissimo.

Bene. è molto utile poter risolvere tutto con solo un'istruzione.

Soprattutto è un caso comune, e pure un collo di bottiglia per le prestazioni.

Cmq, pensavo: ha senso avere l' estensione per le modalità di indirizzamento più complesse? Praticamente l'opcode a 16 bit diventa a 32. Non sarebbe meglio integrare queste istruzioni nella tabella a 32 bit?

No, perché, come dicevo prima, ci possono essere due estensioni: una per l'operando sorgente, e l'altro per quello di destinazione.

Inoltre gli opcode a 32 bit hanno modalità d'indirizzamento con estensione a 32 bit (quelle con offset da 23 bit).

Per cui in ogni caso non ci rientreremmo.

@Tommo: grazie.

[Mattyfog]

@Z80Fan: tu non fai ancora l'università giusto? quindi tutte queste cose come le hai imparate?

[Z80Fan]

Originariamente inviato da Tommo

Ho provato a leggere questo thread ma mi è esploso il cervello
Però vi stimo parecchio per la dedizione!

Grazie

Originariamente inviato da cdimauro

Il copia & incolla è la principale fonte di bug. La seconda è il sonno. La combinazione dei due, poi, è micidiale.

Grazie per la segnalazione.

A questo punto utilizzo lo spazio della seconda CMP per mappare qui la QMOVEU (così ho una costante a 8 bit a disposizione). Mentre marco come riservato il precedente spazio della QMOVEU, che a questo punto può benissimo mappare un'istruzione tipo la LEA, cioé con un registro e una modalità d'indirizzamento.

Ottimo. Lo spazio nella tabella degli opcode a 16 bit è preziosissimo.

Che bello, mi piace ottimizzare

Originariamente inviato da cdimauro

Soprattutto è un caso comune, e pure un collo di bottiglia per le prestazioni.

Stavo giusto pensando che il controllo se eseguire o no un salto condizionato si potrebbe far fare all'unità di fetch, in modo da al massimo avere una sola "bolla" (quella che si viene a creare quando il fetch scarta l'istruzione attuale e impiega un altro ciclo per caricare la nuova, mentre la pipeline va avanti). In questo modo possiamo anche evitare che istruzioni eseguite a metà modifichino lo stato dell' architettura, che poi noi dovremmo risettare ecc...

Originariamente inviato da cdimauro

No, perché, come dicevo prima, ci possono essere due estensioni: una per l'operando sorgente, e l'altro per quello di destinazione.

Inoltre gli opcode a 32 bit hanno modalità d'indirizzamento con estensione a 32 bit (quelle con offset da 23 bit).

Per cui in ogni caso non ci rientreremmo.

Accidenti, ora impiegherò giorni e giorni per riuscire a codificare queste istruzioni, e alla fine scarterò tutto il lavoro (perchè non ci sono riuscito), e useremo la tua

Originariamente inviato da Mattyfog

@Z80Fan: tu non fai ancora l'università giusto? quindi tutte queste cose come le hai imparate?

Ehm, veramente non lo so neanche io
Penso attraverso internet, visto che non ho libri che trattano questo argomento, e poi tramite inventiva personale (tante volte mi sembrava di aver inventato qualcosa, per poi vedere che esisteva già )

[cdimauro]

Originariamente inviato da Z80Fan

Che bello, mi piace ottimizzare

A me piacerebbe dormire un po' di più.

Stavo giusto pensando che il controllo se eseguire o no un salto condizionato si potrebbe far fare all'unità di fetch, in modo da al massimo avere una sola "bolla" (quella che si viene a creare quando il fetch scarta l'istruzione attuale e impiega un altro ciclo per caricare la nuova, mentre la pipeline va avanti). In questo modo possiamo anche evitare che istruzioni eseguite a metà modifichino lo stato dell' architettura, che poi noi dovremmo risettare ecc...

Mi sembra che sia l'approccio di Motorola col 68060. Ne ho parlato nell'apposito articolo su AD.

Accidenti, ora impiegherò giorni e giorni per riuscire a codificare queste istruzioni, e alla fine scarterò tutto il lavoro (perchè non ci sono riuscito), e useremo la tua

Sicuro? Non hai ancora visto la struttura degli opcode a 32 bit.

[cionci]

Ora cdimauro mi fucilerà, ma da un punto di vista implementativo un'architettura RISC non sarebbe stata più adatta allo scopo di questo thread ?
Prima di tutto perché la progettazione dell'ISA è più semplice, poi perché ci si può sbizzarrire sulla progettazione delle pipeline senza dover progettare prima unità di decodifica veramente complesse.

[Z80Fan]

Originariamente inviato da cdimauro

Mi sembra che sia l'approccio di Motorola col 68060. Ne ho parlato nell'apposito articolo su AD.

Ecco, ogni volta che ho una buona idea, è già stata pensata!

Originariamente inviato da cdimauro

Sicuro? Non hai ancora visto la struttura degli opcode a 32 bit.

Mi fido

Originariamente inviato da cionci

Ora cdimauro mi fucilerà, ma da un punto di vista implementativo un'architettura RISC non sarebbe stata più adatta allo scopo di questo thread ?
Prima di tutto perché la progettazione dell'ISA è più semplice, poi perché ci si può sbizzarrire sulla progettazione delle pipeline senza dover progettare prima unità di decodifica veramente complesse.

Quello che più mi preoccupa sono le modalità di indirizzamento decisamente complesse, che penso si possano togliere dagli opcode a 16 bit. Sto provando a semplificare questi ultimi usando solo gli indirizzamenti più semplici (troppo semplici per Cesare ), o quelli che mi sembrano più utili o che ho usato più spesso nella mia esperienza assembly; pianifico di lasciare le cose più complesse (tipo trasferimenti memoria-memoria) nella tabella a 32 bit.

[cdimauro]

Originariamente inviato da cionci

Ora cdimauro mi fucilerà, ma da un punto di vista implementativo un'architettura RISC non sarebbe stata più adatta allo scopo di questo thread ?
Prima di tutto perché la progettazione dell'ISA è più semplice, poi perché ci si può sbizzarrire sulla progettazione delle pipeline senza dover progettare prima unità di decodifica veramente complesse.

Questo è senza dubbio vero, ma non mi sembra ci fossero dei requisiti stringenti da questo punto di vista. Sentendomi "in libertà" ho tirato fuori dal cassetto l'ISA a cui sto lavorando da anni.

Comunque l'n-esimo progetto di CPU RISC non mi esalta. Le architetture a opcode fissi sono troppo limitate e uccidono la creatività. Alla fine si arriva a definire architetture abbastanza simili ad altre, che fanno più o meno le stesse cose.

Coi CISC (o, al limite, i CRISP), invece, uno può tirare fuori la propria immaginazione, la creatività che è tipica dei programmatori.

Originariamente inviato da Z80Fan

Quello che più mi preoccupa sono le modalità di indirizzamento decisamente complesse, che penso si possano togliere dagli opcode a 16 bit. Sto provando a semplificare questi ultimi usando solo gli indirizzamenti più semplici (troppo semplici per Cesare ),

In tutta onestà, le 8 modalità d'indirizzamento del 68000 che ho "preso in prestito" mi sembravano decisamente semplici.

Perfino i RISC più moderni hanno la possibilità di utilizzare un registro base, uno indice scalato, a cui viene aggiunto anche un offset. Gli ARM e PowerPC, tra l'altro, hanno anche la possibilità di aggiornare il contenuto del registro base col calcolo dell'indirizzo effettuato (quindi ben più complesso di roba come An+ o -An).

o quelli che mi sembrano più utili o che ho usato più spesso nella mia esperienza assembly; pianifico di lasciare le cose più complesse (tipo trasferimenti memoria-memoria) nella tabella a 32 bit.

Ah, allora stai optando per un CISC: opcode a 16 bit + a 32 bit.

[Z80Fan]

Originariamente inviato da cdimauro

In tutta onestà, le 8 modalità d'indirizzamento del 68000 che ho "preso in prestito" mi sembravano decisamente semplici.

Perfino i RISC più moderni hanno la possibilità di utilizzare un registro base, uno indice scalato, a cui viene aggiunto anche un offset. Gli ARM e PowerPC, tra l'altro, hanno anche la possibilità di aggiornare il contenuto del registro base col calcolo dell'indirizzo effettuato (quindi ben più complesso di roba come An+ o -An).

Si, ma loro hanno parole da 32 bit e possono usare tutti i registri come operandi Io sto cercando di fare il secondo con metà del primo... quindi per "semplice" intendo veramente semplice, come Rx, [Rx], [Rx+Ry], [Rx+off]. Ad esempio ho pensato che gli indirizzamenti più comuni potrebbero essere [Rx+Ry] per i vettori e [FP+off] per accedere a variabili locali. Anche l'indice scalato ecc... sono più complessi, perchè uno può scorrere un vettore di word, e usare il qadd per posizionarsi nell'elemento successivo, senza troppe complicanze.

Originariamente inviato da cdimauro

Ah, allora stai optando per un CISC: opcode a 16 bit + a 32 bit.

No, stò facendo un RISC solo per dimostrarti che anche i RISC possono avere opcode a lunghezza variabile!

[cdimauro]

Originariamente inviato da Z80Fan

Si, ma loro hanno parole da 32 bit e possono usare tutti i registri come operandi Io sto cercando di fare il secondo con metà del primo... quindi per "semplice" intendo veramente semplice, come Rx, [Rx], [Rx+Ry], [Rx+off]. Ad esempio ho pensato che gli indirizzamenti più comuni potrebbero essere [Rx+Ry] per i vettori e [FP+off] per accedere a variabili locali.

OK, così effettivamente sono molto semplici: al più hai una somma da fare.

Anche l'indice scalato ecc... sono più complessi, perchè uno può scorrere un vettore di word, e usare il qadd per posizionarsi nell'elemento successivo, senza troppe complicanze.

Ti serve un'istruzione in più così, quindi è meno performante.

No, stò facendo un RISC solo per dimostrarti che anche i RISC possono avere opcode a lunghezza variabile!

RISC and CISC definitions

At the time of introduction, RISC and "load-store" were often synonymous, but RISC usually referred to a list of features:

• All instructions are a single, fixed length.
• Operations are simple enough to execute in a single cycle, using an execution pipeline.
• Operations are performed on registers only, the only memory operations are load and store.
• No microcode is needed, because of the simpler design.
• A large number of registers are available.
• Register windows are used to speed subroutine calls.

Quindi... CISC rulez.

[Z80Fan]

Originariamente inviato da cdimauro

Ti serve un'istruzione in più così, quindi è meno performante.

Ma l'incremento dell'indice (+1) lo avresti dovuto fare lo stesso no?

Originariamente inviato da cdimauro

RISC and CISC definitions

At the time of introduction, RISC and "load-store" were often synonymous, but RISC usually referred to a list of features:

• All instructions are a single, fixed length.
• Operations are simple enough to execute in a single cycle, using an execution pipeline.
• Operations are performed on registers only, the only memory operations are load and store.
• No microcode is needed, because of the simpler design.
• A large number of registers are available.
• Register windows are used to speed subroutine calls.

Quindi... CISC rulez.

Io rimango dell'idea che quella non è la principale caratteristica che delinea un Risc; se lo fosse stata, li avrebbero chiamati SSISC (single-size instruction set computer)
Quindi, per controprova, oltre a un Risc con opcode a lunghezza variabile ti progetto anche un cisc con opcode a lunghezza fissa!

[ndakota]

Originariamente inviato da cdimauro

la creatività che è tipica dei programmatori.

Ho appena scoperto di non essere un programmatore

Come procede? Nei CISC si usa la pipeline? No, vero?

[cdimauro]

Originariamente inviato da Z80Fan

Ma l'incremento dell'indice (+1) lo avresti dovuto fare lo stesso no?

Certo, ma lo faccio in parallelo grazie a un'ALU dedicata per il calcolo degli indirizzi.

Tu, invece, sei costretto a usare (quindi più spazio) ed eseguire (prestazioni più scarse) un'istruzione in più.

Quanto meno dal punto di vista della compattezza del codice, i CISC vincono a mani basse.

Per le prestazioni, ormai che viaggiamo sui miliardi di transistor, un'unità di decodifica non è un problema né di costi né di consumi.

Io rimango dell'idea che quella non è la principale caratteristica che delinea un Risc; se lo fosse stata, li avrebbero chiamati SSISC (single-size instruction set computer)
Quindi, per controprova, oltre a un Risc con opcode a lunghezza variabile ti progetto anche un cisc con opcode a lunghezza fissa!

Storicamente è così. Al limite chiedi a Pleg, che lavora alla Stanford University.

P.S. Adesso vado a nanna però, che stanotte ho dormito pochissimo a causa del piccolo.

Originariamente inviato da ndakota

Ho appena scoperto di non essere un programmatore

Come procede? Nei CISC si usa la pipeline? No, vero?

Sì: non è esclusiva dei RISC. Anche il buon 68000 ne aveva una, e il 6502 del Commodore Vic 20 pure!

[ndakota]

Originariamente inviato da cdimauro

Sì: non è esclusiva dei RISC. Anche il buon 68000 ne aveva una, e il 6502 del Commodore Vic 20 pure!

E il vostro ne fa uso? Come risolvete il conflitto dei dati nella pipeline? E nei salti condizionati? Provo a imparare qualcosa

[cdimauro]

Mi sembra ancora presto per parlarne. Intanto definiamo l'ISA, e poi vediamo come implementarla e le soluzioni che sono presenti in letteratura per risolvere questi problemi.

[cionci]

Originariamente inviato da cdimauro

Questo è senza dubbio vero, ma non mi sembra ci fossero dei requisiti stringenti da questo punto di vista. Sentendomi "in libertà" ho tirato fuori dal cassetto l'ISA a cui sto lavorando da anni.

Per carità, hai fatto bene. L'ISA è molto bella tra l'altro

[cdimauro]

Il bello verrà dopo, con gli opcode a 32 bit.

[Z80Fan]

Originariamente inviato da cdimauro

Certo, ma lo faccio in parallelo grazie a un'ALU dedicata per il calcolo degli indirizzi.
Tu, invece, sei costretto a usare (quindi più spazio) ed eseguire (prestazioni più scarse) un'istruzione in più.

Forse non mi sono spiegato bene, intendevo dire una situazione del genere:

MOV.L    [A1, D3.Q*4, 2], D0
QADD.Q   1, D3

Questa è la versione tua, la mia la intendevo così:

MOV.L    [R9 + R3], R0
QADD.Q   6, R3

Che secondo me sono equivalenti. Se invece prendiamo gli incrementi di 1 byte ( [An]+ ), allora si che c'è il vantaggio di un'istruzione in meno.

Originariamente inviato da cdimauro

Storicamente è così. Al limite chiedi a Pleg, che lavora alla Stanford University.

Certo, non ho dubbi che tutte le architetture risc usino opcode a lunghezza fissa: il loro obiettivo è proprio quello di semplificare al massimo le istruzioni, e avere opcode a lunghezza variabile le complicherebbe. Quello che volevo intendere è che un Risc non è obbligatorio che abbia opcode a lunghezza fissa, l'importante è che abbia istruzioni molto semplici e veloci (e questo anche preclude gli indirizzamenti complessi).

Originariamente inviato da cdimauro

Sì: non è esclusiva dei RISC. Anche il buon 68000 ne aveva una, e il 6502 del Commodore Vic 20 pure!

Hey, non dimentichiamo lo Z80 che sovrapponeva i cicli macchina tra le istruzioni!

Originariamente inviato da cionci

Per carità, hai fatto bene. L'ISA è molto bella tra l'altro

Già. Mi vergogno un po' a presentare la mia codifica, visto che toglie molto dando solo la possibilità di usare qualsiasi registro

Originariamente inviato da cdimauro

Il bello verrà dopo, con gli opcode a 32 bit.

Visto che in 16 bit ci sto veramente male, appena la finisco pubblico la mia codifica interamente a 32 bit, che oltre a poter usare qualsiasi registro mette a disposizione anche tutte le modalità di indirizzamento; magari possiamo prendere un po' da entrambe.

Originariamente inviato da ndakota

E il vostro ne fa uso? Come risolvete il conflitto dei dati nella pipeline? E nei salti condizionati? Provo a imparare qualcosa

Si, prevedo di usarla sicuramente una pipeline. Come già detto, vedremo in seguito gli stalli e le dipendenze da risolvere. Intanto abbiamo un nuovo "allievo"
Ora che ci penso, dove è finito MaxArt? E' scappato via urlando dopo aver visto il set istruzioni?