[Asm] Progettare una architettura di processore

[cdimauro]

Originariamente inviato da Z80Fan

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.

Parlavo di questa, ma anche della versione presente negli opcode a 32 bit, che alla fine dell'operazione aggiorna An con l'indirizzo calcolato (quindi An <- A1 + D3.Q*4 +2).

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).

Ho capito, ma guarda che per i RISC non vale nemmeno questo da tempo: basti vedere PowerPC e ARM, ad esempio, col primo che ha pure del microcodice che esegure per le istruzioni di Load/Store multiple.

Quindi istruzioni complesse e lente anche per i RISC.

Diciamo che finora è la prima volta che sento parlare di un RISC con opcode a lunghezza variabile, ma dopo il Thumb di ARM mi sono dovuto ricredere.

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

Io sono un MOSsiano. 6502 rulez.

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

Era normale che finisse così: c'è troppo poco spazio con 16 bit. Ecco perché, sembrerà una stupidaggine, ma con registri indirizzi e dati separati il risparmio anche di un solo bit si fa sentire ed è decisamente pesante.

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.

Io intanto vorrei finire la mia ISA aggiungendo gli opcode a 32 bit, però. Ormai che mi hai provocato facendola uscire dal cassetto, devi prenderti le tue responsabilità.

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?

Mi spiacerebbe. Se servono spiegazioni su punti oscuri / dubbi, io sono a disposizione (nei limiti di tempo che ho).

[cionci]

Dopo aver letto la news su Tilera... Pensare a qualche ISA VLIW con obiettivo il massimo sfruttamento delle unità di esecuzione ?
Il mercato si sta spostando fortemente verso il multi-threading. Costruire un core semplice RISC o VLIW con sincronizzazione esplicita fra thread non sarebbe secondo me un brutta idea.

[Z80Fan]

Originariamente inviato da cdimauro

Parlavo di questa, ma anche della versione presente negli opcode a 32 bit, che alla fine dell'operazione aggiorna An con l'indirizzo calcolato (quindi An <- A1 + D3.Q*4 +2).

Mi rimane ancora oscuro come tu riesca a fare il primo esempio con solo un'istruzione (ovviamente aumentando solo l'indice e non tutto il puntatore).

Originariamente inviato da cdimauro

Ho capito, ma guarda che per i RISC non vale nemmeno questo da tempo: basti vedere PowerPC e ARM, ad esempio, col primo che ha pure del microcodice che esegure per le istruzioni di Load/Store multiple.
Quindi istruzioni complesse e lente anche per i RISC.

Già, al giorno d'oggi non è che si riesca più tanto a parlare di CISC e RISC, solo di "mescolanze", ovviamente parlando dal lato tecnico; poi se il marketing decide, riuscirebbe a etichettare "CISC" anche un PIC

Originariamente inviato da cdimauro

6502 rulez.

Argh !!!

Originariamente inviato da cdimauro

Io intanto vorrei finire la mia ISA aggiungendo gli opcode a 32 bit, però. Ormai che mi hai provocato facendola uscire dal cassetto, devi prenderti le tue responsabilità.

Certo, fai pure. Mi piacerebbe vedere anche la 32 completa

Originariamente inviato da cionci

Dopo aver letto la news su Tilera... Pensare a qualche ISA VLIW con obiettivo il massimo sfruttamento delle unità di esecuzione ?
Il mercato si sta spostando fortemente verso il multi-threading. Costruire un core semplice RISC o VLIW con sincronizzazione esplicita fra thread non sarebbe secondo me un brutta idea.

VLIW forse no, ma una serie di istruzioni per implementare facilmente semafori ecc... le mettiamo sicuramente. Se poi ci rimane spazio per le sincronizzazioni interprocessore, ben venga

[Z80Fan]

Vi faccio un'anteprima sul set istruzioni a 32 bit:
Poiché volevo semplificare il design ed evitare la parola di estensione, ho inglobato nell' opcode alcuni campi che erano su quest'ultima (come ad esempio il registro indice e la scala). Il problema è che in tutte le altre modalità di indirizzamento questi campi rimanevano inutilizzati, quindi per sfruttarli al massimo ho aperto la fantasia e ho riempito una nuova tabella di modi di indirizzamento.

Mode| Index Reg. |Operand Reg | Syntax
000 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale]          | Indirect address with scaled index
001 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale]+         | Indirect address with scaled index and writeback
010 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt16]  | Indirect address with scaled index and signed 16 bits offset
011 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt16]+ | Indirect address with scaled index, writeback  and signed 16 bits offset
100 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt32]  | Indirect address with scaled index and signed 32 bits offset
101 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt32]+ | Indirect address with scaled index, writeback and signed 32 bits offset
110 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt64]  | Indirect address with scaled index and signed 64 bits offset
111 |       0000 |Op. Reg. no | Rn + Uint3                | Register plus Uint3 (in the "scale" field)		<--- potentissima feature
111 |       0001 |Op. Reg. no | Rn - Uint3                | Register less Uint3 (in the "scale" field)
111 |       0010 |Op. Reg. no | [Rn] + Uint3              | Indirect address with postadd of "Uint3" 
111 |       0011 |Op. Reg. no | [Rn] - Uint3              | Indirect address with postsubtract
111 |       0100 |Op. Reg. no | Uint3 + [Rn]              | Indirect address with preadd
111 |       0101 |Op. Reg. no | Uint3 - [Rn]              | Indirect address with presubtract
111 |       0110 |Op. Reg. no | [Rn, Uint3]               | Indirect address with 3 bits unsigned offset
111 |       0111 |Op. Reg. no | [Rn, Uint3]+              | Indirect address with 3 bits unsigned offset and writeback
111 |       1000 |Op. Reg. no | [Rn, SInt16]              | Indirect address with signed 16 bits offset
111 |       1001 |Op. Reg. no | [Rn, SInt16]+             | Indirect address with signed 16 bits offset and writeback
111 |       1010 |Op. Reg. no | [Rn, SInt32]              | Indirect address with signed 32 bits offset
111 |       1011 |Op. Reg. no | [Rn, SInt32]+             | Indirect address with signed 32 bits offset and writeback
111 |       1100 |Op. Reg. no | [Rn, SInt64]              | Indirect address with signed 64 bits offset
111 |       1101 |Op. Reg. no | [Rn, SInt64]+             | Indirect address with signed 64 bits offset and writeback
111 |       1110 |Op. Reg. no | ****                      | Reserved
111 |       1111 |       0000 | ****                      | Reserved
111 |       1111 |       0001 | [PC, SInt16]              | Indirect PC with signed 16 bits offset
111 |       1111 |       0010 | [PC, SInt32]              | Indirect PC with signed 32 bits offset
111 |       1111 |       0011 | [PC, SInt64]              | Indirect PC with signed 32 bits offset
111 |       1111 |       0100 | [SP]+                     | Indirect SP with postincrement		<--- potentissima feature (POP)
111 |       1111 |       0101 | [SP, UInt16]              | Indirect SP with unsigned 16 bits offset
111 |       1111 |       0110 | [SP, UInt32]              | Indirect SP with unsigned 32 bits offset
111 |       1111 |       0111 | -[SP]                     | Indirect SP with predecrement		<--- potentissima feature (PUSH)
111 |       1111 |       1000 | [FP, UInt3]               | Indirect FP with UNsigned 3 bits offset
111 |       1111 |       1001 | [FP, SInt16]              | Indirect FP with signed 16 bits offset
111 |       1111 |       1010 | [FP, SInt32]              | Indirect FP with signed 32 bits offset
111 |       1111 |       1011 | [FP, SInt64]              | Indirect FP with signed 64 bits offset
111 |       1111 |       1100 | [UInt16]                  | Absolute zero-extended 16 bits address
111 |       1111 |       1101 | [UInt32]                  | Absolute zero-extended 32 bits address
111 |       1111 |       1110 | [UInt64]                  | Absolute 64 bits address
111 |       1111 |       1111 | Value                     | Immediate

E questo è il Super MOV:

MOV.s	Md, Ms
|31  30 |29  28  27 |26  25  24 |23  22  21  20 |19  18 |17  16  15 |14  13  12 |11  10   9   8 | 7   6   5   4 | 3   2   1   0 |
| 0   0 |  Scale s  | modalità s| Registro i s  | Size  |  Scale d  | modalità d|  Registro i d |  Registro s   |  Registro  D  |
# Muove qualsiasi cosa in qualsiasi cosa :D

Alla faccia del CISC !

[cionci]

Il mio intervento era per dire che, vista l'esperienza che mi sembra che abbiate, sarebbe bene provare ad implementare qualcosa di innovativo che una architettura CISC, comoda per il programmatore, ma scomoda per il progettista
Anche solo per vedere qualcosa che almeno io non ho mai visto. Nei vari corsi di studio ho sia progettato processori CISC (x86) che RISC, ma mai un VLIW.
Tra l'altro quella CPU Tilera dovrebbe avere una feature molto interessante, cioè una specie di SMT al contrario: più core possono lavorare contemporaneamente sullo stesso thread. Sarebbe quindi interessante esplorare questi lidi

[Z80Fan]

Originariamente inviato da cionci

Il mio intervento era per dire che, vista l'esperienza che mi sembra che abbiate, sarebbe bene provare ad implementare qualcosa di innovativo che una architettura CISC, comoda per il programmatore, ma scomoda per il progettista
Anche solo per vedere qualcosa che almeno io non ho mai visto. Nei vari corsi di studio ho sia progettato processori CISC (x86) che RISC, ma mai un VLIW.
Tra l'altro quella CPU Tilera dovrebbe avere una feature molto interessante, cioè una specie di SMT al contrario: più core possono lavorare contemporaneamente sullo stesso thread. Sarebbe quindi interessante esplorare questi lidi

Mmmh... potrei provare a mettere giù un set di istruzioni decisamente risc, che poi possiamo inglobare in una parola lunga magari da 128 bit. Sarebbe molto semplice da realizzare il circuito e anche la pipeline, perchè possiamo tralasciare il controllo di dipendenza dei dati e lasciarlo fare al compilatore (cioè come fanno tutti i VLIW ), ma in questo caso dovremo aprire un'altro thread: "Costruire un compilatore"
Una specie di "VLIW" (che "very long" non è, però ci sono più istruzioni in un bundle da 32 bit) è questo: http://www.6502.org/users/dieter/tinst/tinst_0.htm

Oppure, possiamo fare una cpu che usa la pipeline allo stesso modo dell' ELEA 9003: ogni blocco della pipeline non lavora su un pezzo dell'istruzione seguente dello stesso thread, ma lavora su istruzioni di thread diversi (l'ELEA, che aveva 3 stadi di pipeline, poteva lavorare su 3 thread contemporaneamente).

[cdimauro]

Originariamente inviato da cionci

Dopo aver letto la news su Tilera... Pensare a qualche ISA VLIW con obiettivo il massimo sfruttamento delle unità di esecuzione ?
Il mercato si sta spostando fortemente verso il multi-threading. Costruire un core semplice RISC o VLIW con sincronizzazione esplicita fra thread non sarebbe secondo me un brutta idea.

Bisogna definire un obiettivo preciso, allora, perché un VLIW è fortemente orientato all'esecuzione parallela (e assistita dal compilatore), mentre una CPU tradizionale (sia essa CISC o RISC) decisamente no (è più orientata al calcolo general purpose con ottimizzazione a runtime).

Originariamente inviato da Z80Fan

Mi rimane ancora oscuro come tu riesca a fare il primo esempio con solo un'istruzione (ovviamente aumentando solo l'indice e non tutto il puntatore).

Se l'obiettivo è quello di scorrere una struttura, non c'è bisogno di incrementare l'indice, che rimane invariato, ma soltanto il puntatore.
Basta porre A0 = Indirizzo di inizio + 2 (era questo l'offset che avevi messo prima), e sfruttare poi quell'istruzione con l'update di A0 con l'indirizzo calcolato dall'AGU.

Già, al giorno d'oggi non è che si riesca più tanto a parlare di CISC e RISC, solo di "mescolanze", ovviamente parlando dal lato tecnico; poi se il marketing decide, riuscirebbe a etichettare "CISC" anche un PIC

Proprio per questo la lunghezza degli opcode rimane uno dei punti di riferimento per distinguere le due macrofamiglie.

Sul resto concordo.

Certo, fai pure. Mi piacerebbe vedere anche la 32 completa

Mi ci vuole ancora un po' di tempo. Mancano un po' di istruzioni.

VLIW forse no, ma una serie di istruzioni per implementare facilmente semafori ecc... le mettiamo sicuramente. Se poi ci rimane spazio per le sincronizzazioni interprocessore, ben venga

Hum... Non sono molto convinto. Al momento ho strutturato l'ISA in modo da avere al più 1 lettura e 1 scrittura in memoria.

Queste saranno le ultime istruzioni a cui penserò.

Originariamente inviato da Z80Fan

Vi faccio un'anteprima sul set istruzioni a 32 bit:
Poiché volevo semplificare il design ed evitare la parola di estensione, ho inglobato nell' opcode alcuni campi che erano su quest'ultima (come ad esempio il registro indice e la scala). Il problema è che in tutte le altre modalità di indirizzamento questi campi rimanevano inutilizzati, quindi per sfruttarli al massimo ho aperto la fantasia e ho riempito una nuova tabella di modi di indirizzamento.

Mode| Index Reg. |Operand Reg | Syntax
000 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale]          | Indirect address with scaled index
001 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale]+         | Indirect address with scaled index and writeback
010 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt16]  | Indirect address with scaled index and signed 16 bits offset
011 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt16]+ | Indirect address with scaled index, writeback  and signed 16 bits offset
100 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt32]  | Indirect address with scaled index and signed 32 bits offset
101 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt32]+ | Indirect address with scaled index, writeback and signed 32 bits offset
110 |Index Reg no|Op. Reg. no | [Rn, Ri * Scale, SInt64]  | Indirect address with scaled index and signed 64 bits offset
111 |       0000 |Op. Reg. no | Rn + Uint3                | Register plus Uint3 (in the "scale" field)		<--- potentissima feature
111 |       0001 |Op. Reg. no | Rn - Uint3                | Register less Uint3 (in the "scale" field)
111 |       0010 |Op. Reg. no | [Rn] + Uint3              | Indirect address with postadd of "Uint3" 
111 |       0011 |Op. Reg. no | [Rn] - Uint3              | Indirect address with postsubtract
111 |       0100 |Op. Reg. no | Uint3 + [Rn]              | Indirect address with preadd
111 |       0101 |Op. Reg. no | Uint3 - [Rn]              | Indirect address with presubtract
111 |       0110 |Op. Reg. no | [Rn, Uint3]               | Indirect address with 3 bits unsigned offset
111 |       0111 |Op. Reg. no | [Rn, Uint3]+              | Indirect address with 3 bits unsigned offset and writeback
111 |       1000 |Op. Reg. no | [Rn, SInt16]              | Indirect address with signed 16 bits offset
111 |       1001 |Op. Reg. no | [Rn, SInt16]+             | Indirect address with signed 16 bits offset and writeback
111 |       1010 |Op. Reg. no | [Rn, SInt32]              | Indirect address with signed 32 bits offset
111 |       1011 |Op. Reg. no | [Rn, SInt32]+             | Indirect address with signed 32 bits offset and writeback
111 |       1100 |Op. Reg. no | [Rn, SInt64]              | Indirect address with signed 64 bits offset
111 |       1101 |Op. Reg. no | [Rn, SInt64]+             | Indirect address with signed 64 bits offset and writeback
111 |       1110 |Op. Reg. no | ****                      | Reserved
111 |       1111 |       0000 | ****                      | Reserved
111 |       1111 |       0001 | [PC, SInt16]              | Indirect PC with signed 16 bits offset
111 |       1111 |       0010 | [PC, SInt32]              | Indirect PC with signed 32 bits offset
111 |       1111 |       0011 | [PC, SInt64]              | Indirect PC with signed 32 bits offset
111 |       1111 |       0100 | [SP]+                     | Indirect SP with postincrement		<--- potentissima feature (POP)
111 |       1111 |       0101 | [SP, UInt16]              | Indirect SP with unsigned 16 bits offset
111 |       1111 |       0110 | [SP, UInt32]              | Indirect SP with unsigned 32 bits offset
111 |       1111 |       0111 | -[SP]                     | Indirect SP with predecrement		<--- potentissima feature (PUSH)
111 |       1111 |       1000 | [FP, UInt3]               | Indirect FP with UNsigned 3 bits offset
111 |       1111 |       1001 | [FP, SInt16]              | Indirect FP with signed 16 bits offset
111 |       1111 |       1010 | [FP, SInt32]              | Indirect FP with signed 32 bits offset
111 |       1111 |       1011 | [FP, SInt64]              | Indirect FP with signed 64 bits offset
111 |       1111 |       1100 | [UInt16]                  | Absolute zero-extended 16 bits address
111 |       1111 |       1101 | [UInt32]                  | Absolute zero-extended 32 bits address
111 |       1111 |       1110 | [UInt64]                  | Absolute 64 bits address
111 |       1111 |       1111 | Value                     | Immediate

E questo è il Super MOV:

MOV.s	Md, Ms
|31  30 |29  28  27 |26  25  24 |23  22  21  20 |19  18 |17  16  15 |14  13  12 |11  10   9   8 | 7   6   5   4 | 3   2   1   0 |
| 0   0 |  Scale s  | modalità s| Registro i s  | Size  |  Scale d  | modalità d|  Registro i d |  Registro s   |  Registro  D  |
# Muove qualsiasi cosa in qualsiasi cosa :D

Mi pare proprio un bel design.

Tra l'altro mi hai fornito lo spunto per eliminare le istruzioni di PUSH e POP, sfruttando due delle tre modalità d'indirizzamento che erano rimaste libere, così da avere -[SP] e [SP]+.

In questo modo ho pure recuperato 9 bit dall'opcode table a 16 bit. Grazie!

Alla faccia del CISC !

Appunto: quello tutto lo puoi chiamare, tranne che RISC.

Originariamente inviato da cionci

Il mio intervento era per dire che, vista l'esperienza che mi sembra che abbiate, sarebbe bene provare ad implementare qualcosa di innovativo che una architettura CISC, comoda per il programmatore, ma scomoda per il progettista

Ma alla fine la CPU chi la usa, il progettista o il programmatore?

Comunque i design che stiamo tirando fuori non sono complicati da implementare a livello di decoder, perché sono abbastanza lineari e ortogonali, senza eccezioni (a parte per i "buchi" lasciati liberi dalle istruzioni non implementate).

Anche solo per vedere qualcosa che almeno io non ho mai visto. Nei vari corsi di studio ho sia progettato processori CISC (x86) che RISC, ma mai un VLIW.
Tra l'altro quella CPU Tilera dovrebbe avere una feature molto interessante, cioè una specie di SMT al contrario: più core possono lavorare contemporaneamente sullo stesso thread. Sarebbe quindi interessante esplorare questi lidi

Quello sicuramente, non foss'altro per cultura personale.

[cdimauro]

Originariamente inviato da Z80Fan

Mmmh... potrei provare a mettere giù un set di istruzioni decisamente risc, che poi possiamo inglobare in una parola lunga magari da 128 bit. Sarebbe molto semplice da realizzare il circuito e anche la pipeline, perchè possiamo tralasciare il controllo di dipendenza dei dati e lasciarlo fare al compilatore (cioè come fanno tutti i VLIW ), ma in questo caso dovremo aprire un'altro thread: "Costruire un compilatore"
Una specie di "VLIW" (che "very long" non è, però ci sono più istruzioni in un bundle da 32 bit) è questo: http://www.6502.org/users/dieter/tinst/tinst_0.htm

Mah. Ho dato un'occhiata a questo progetto e potevano farlo molto meglio.

Non hanno tenuto conto di alcune cose che avrebbero permesso di ottimizzare e sfruttare come si deve l'opcode a 32 bit.

[cionci]

Originariamente inviato da cdimauro

Bisogna definire un obiettivo preciso, allora, perché un VLIW è fortemente orientato all'esecuzione parallela (e assistita dal compilatore), mentre una CPU tradizionale (sia essa CISC o RISC) decisamente no (è più orientata al calcolo general purpose con ottimizzazione a runtime).

Invece secondo me sarebbe molto interessante lavorare su un RISC con parallelizzazione esplicita e con indicazione esplicita delle dipendenze.
Ovviamente allungherebbe l'opcode, ma semplificherebbe altre cose. Ad esempio l'esecuzione potrebbe essere in-order, o al limite anche out-of-order ma in base al raggruppamento.
Consideriamo anche che essendo RISC l'analisi delle dipendenze da parte del compilatore è molto più semplice visto il numero ridotto di opcode...

Faccio un esempio: supponiamo di avere due LOAD/STORE pipeline...

grp dep
 1   0    LOAD  R0, op1 
 1   0    LOAD  R1, op2 
 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R0, R2
 4   3    SHR   R0, 6
 1   0    LOAD  R3, op4
 1   4    STORE op1, R0

Credo che con 8 bit per il gruppo e 8 per la dipendenza siano sufficienti.

[Z80Fan]

Originariamente inviato da cdimauro

Se l'obiettivo è quello di scorrere una struttura, non c'è bisogno di incrementare l'indice, che rimane invariato, ma soltanto il puntatore.
Basta porre A0 = Indirizzo di inizio + 2 (era questo l'offset che avevi messo prima), e sfruttare poi quell'istruzione con l'update di A0 con l'indirizzo calcolato dall'AGU.

Quindi l' Xn*scale deve essere inteso come un campo che indica la lunghezza di ogni struttura? Quindi un vettore di quad lo scorri così:

       MOV.Q    vett, A0
       QMOVEU   8, D7
ciclo: MOV.Q [A0, D7, 0]+, D0
       <elabora>
       Bcc ciclo

?

Originariamente inviato da cdimauro

i pare proprio un bel design.

Tra l'altro mi hai fornito lo spunto per eliminare le istruzioni di PUSH e POP, sfruttando due delle tre modalità d'indirizzamento che erano rimaste libere, così da avere -[SP] e [SP]+.

In questo modo ho pure recuperato 9 bit dall'opcode table a 16 bit. Grazie!

Di questo passo non ci servirà neanche la codifica a 32 bit!

Originariamente inviato da cdimauro

Comunque i design che stiamo tirando fuori non sono complicati da implementare a livello di decoder, perché sono abbastanza lineari e ortogonali, senza eccezioni (a parte per i "buchi" lasciati liberi dalle istruzioni non implementate).

Concordo, il design è lineare; sarà quando dobbiamo scrivere il microcodice per l'unità di calcolo indirizzi che ci sarà da ridere!

Originariamente inviato da cionci

Faccio un esempio: supponiamo di avere due LOAD/STORE pipeline...

grp dep
 1   0    LOAD  R0, op1 
 1   0    LOAD  R1, op2 
 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R0, R2
 4   3    SHR   R0, 6
 1   0    LOAD  R3, op4
 1   4    STORE op1, R0

Credo che con 8 bit per il gruppo e 8 per la dipendenza siano sufficienti.

Non sono un esperto in queste cose, il gruppo indica quali istruzioni possono essere riordinate ed eseguite fuori ordine in sicurezza? Perchè penso (tenendo conto del lato progettistico e avendo una cpu in-order) si possa fare tutto con 1 numero solo:

0    LOAD  R0, op1 
1    LOAD  R1, op2 
2    LOAD  R2, op3 
1    ADD   R0, R1
2    SUB   R0, R2
2    SHR   R0, 6
0    LOAD  R3, op4
2    STORE op1, R0

In questo caso, ad ogni istruzione è assegnato il numero uguale alla più vicina istruzione precedente che scrive un dato dipendente.
Ad esempio, ADD R0, R1 dipende da R0 e R1, la più vicina istruzione che scrive un dato dipendente è LOAD R1, op2 (aggiorna/scrive R1), alla quale è stato assegnato il numero 1, quindi all'ADD sarà assegnato lo stesso 1.
Il lavoro della pipeline è questo: quando entra un'istruzione, controlla il suo numero con i numeri di tutte le istruzioni in quel momento sulla pipeline. Se è presente lo stesso numero, l'istruzione è bloccata finchè l'istruzione non esce o supera lo stadio di scrittura-risultato (che tipicamente è l'ultimo). Possiamo usare il numero speciale 0 per indicare un'istruzione che può essere eseguita tranquillamente.
Il problema però nella dipendenza esplicita, è che i programmi possono diventare incompatibili cambiando processore, anche della stessa architettura: se un programma è stato ottimizzato per un processore con al più 5 stadi di pipeline, in un processore da 6-7-8 potrebbe non funzionare più, perchè dati dipendenti potrebbero essere ancora dentro la pipeline.

[cionci]

Tutte le istruzioni del gruppo possono essere eseguite in parallelo (quindi sì, possono essere eseguite fuori ordine per sicurezza).
La dipendenza indica quale gruppo di istruzioni deve essere eseguito prima di dover eseguire quella istruzione del gruppo. 0 indica che non ci sono dipendenze.

Mi sono accorto di aver inserito un errore, volevo scrivere un'altra cosa

grp dep
 1   0    LOAD  R0, op1 
 1   0    LOAD  R1, op2 
 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R2, 2
 4   3    SUB   R0, R2
 5   4    SHR   R0, 6
 1   0    LOAD  R3, op4
 1   5    STORE op1, R0

Ad esempio, così come l'hai messo tu le prime due LOAD non possono essere eseguite in parallelo.
Così come l'ho messo io, supponendo di avere 2 unità LOAD/STORE e 2 ALU è possibile eseguire le prime due LOAD contemporaneamente.
Poi possono essere allocate tutte le unità di esecuzione contemporaneamente potendo eseguire:

 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R2, 2
 1   0    LOAD  R3, op4

La cosa dovrebbe essere anche piuttosto semplice da gestire. Una fase di prefetch (potrebbe essere realizzata anche a frequenza più alta di quella della CPU, vista la semplicità) analizza grp, dep e il tipo di unità di esecuzione.
Supponendo che un gruppo sia composto da istruzioni in sequenza e che all'interno del gruppo le istruzioni sano ordinate per dipendenza, è possibile assegnare l'unità di esecuzione in modo relativamente semplice.

[Z80Fan]

Originariamente inviato da cionci

grp dep
 1   0    LOAD  R0, op1 
 1   0    LOAD  R1, op2 
 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R2, 2
 4   3    SUB   R0, R2
 5   4    SHR   R0, 6
 1   0    LOAD  R3, op4
 1   5    STORE op1, R0

Mmmh, non capisco bene, provo a dirti cosa sto pensando:
La cpu legge il primo load, ha dipendenza 0 quindi lo manda nella pipeline load/store n°1; legge la seconda load, non ha dipendenze, va in load/store n°2. Legge la 3^ load, ha dipendenza 1, quindi attende che le 2 istruzioni (perchè sono tutte gruppo 1) finiscano, quindi la manda nel load/store 1. prende l'add, la dipendenza 1 è soddisfatta, la manda all'alu 1. prende la sub, attende che il load r2 finisca (se non lo è già), e quindi la manda in alu 2, e così via. è giusto?

Originariamente inviato da cionci

Ad esempio, così come l'hai messo tu le prime due LOAD non possono essere eseguite in parallelo.
Così come l'ho messo io, supponendo di avere 2 unità LOAD/STORE e 2 ALU è possibile eseguire le prime due LOAD contemporaneamente.

Beh, forse si:

0    LOAD  R0, op1 
1    LOAD  R1, op2 
2    LOAD  R2, op3 
1    ADD   R0, R1
2    SUB   R2, 2
2    SUB   R0, R2
2    SHR   R0, 6
0    LOAD  R3, op4
2    STORE op1, R0

La cpu prende Load R0, esegue in load/store 1. Prende anche load r1, tra di loro non hanno dipendenze, quindi la manda anch'essa in parallelo in load/store 2. Preleva Load r2, non ha spazio nelle pipeline, la mette in attesa. Se poi è out-of-order, può cominciare subito a prendere l'add, e la esegue (presumiamo che ormai le load siano uscite). Dopo aver elaborato l'add, ricontrolla il load r2, e la assegna alla pipeline load/store 1 (poichè è libera). Ora controlla la Sub R2, ma non la può eseguire. Controlla Sub R0, ma non la può eseguire, e così anche shr. Trova l'ultimo load e lo esegue perchè non ha dipendenze. Ricontrolla il sub, ora sicuramente il load r2 è terminato e quindi esegue il sub. Ora gli rimangono da fare l'altro sub, il shr e lo store, ma sono tutte dipendenti, quindi le deve fare in sequenza.

 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R2, 2
 1   0    LOAD  R3, op4

Mmh, sub r2, 2 non lo puoi fare in contemporanea a load r2, op3, c'è una dipendenza dei dati.

Originariamente inviato da cionci

La cosa dovrebbe essere anche piuttosto semplice da gestire. Una fase di prefetch (potrebbe essere realizzata anche a frequenza più alta di quella della CPU, vista la semplicità) analizza grp, dep e il tipo di unità di esecuzione.
Supponendo che un gruppo sia composto da istruzioni in sequenza e che all'interno del gruppo le istruzioni sano ordinate per dipendenza, è possibile assegnare l'unità di esecuzione in modo relativamente semplice.

Forse dal lato algoritmico è semplice, ma bisogna poi implementarlo in Hardware

[cionci]

Sì, hai capito...

Originariamente inviato da Z80Fan

Beh, forse si:

0    LOAD  R0, op1 
1    LOAD  R1, op2 
2    LOAD  R2, op3 
1    ADD   R0, R1
2    SUB   R2, 2
2    SUB   R0, R2
2    SHR   R0, 6
0    LOAD  R3, op4
2    STORE op1, R0

La cpu prende Load R0, esegue in load/store 1. Prende anche load r1, tra di loro non hanno dipendenze, quindi la manda anch'essa in parallelo in load/store 2. Preleva Load r2, non ha spazio nelle pipeline, la mette in attesa. Se poi è out-of-order, può cominciare subito a prendere l'add, e la esegue (presumiamo che ormai le load siano uscite). Dopo aver elaborato l'add, ricontrolla il load r2, e la assegna alla pipeline load/store 1 (poichè è libera). Ora controlla la Sub R2, ma non la può eseguire. Controlla Sub R0, ma non la può eseguire, e così anche shr. Trova l'ultimo load e lo esegue perchè non ha dipendenze. Ricontrolla il sub, ora sicuramente il load r2 è terminato e quindi esegue il sub. Ora gli rimangono da fare l'altro sub, il shr e lo store, ma sono tutte dipendenti, quindi le deve fare in sequenza.

Ho capito cosa intendi, in pratica come fai tu mi sembra di capire che vengano eseguite in sequenza istruzioni consecutive con lo stesso indice ed in parallelo istruzioni consecutive con indici diversi. In prima lettura mi sembra corretto.

Originariamente inviato da Z80Fan

Mmh, sub r2, 2 non lo puoi fare in contemporanea a load r2, op3, c'è una dipendenza dei dati.

L'ho riscritta ed ho fatto ancora più casino, comunque credo tu abbia capito.

[Z80Fan]

Originariamente inviato da cionci

Ho capito cosa intendi, in pratica come fai tu mi sembra di capire che vengano eseguite in sequenza istruzioni consecutive con lo stesso indice ed in parallelo istruzioni consecutive con indici diversi. In prima lettura mi sembra corretto.

Si, esatto.

Originariamente inviato da cionci

L'ho riscritta ed ho fatto ancora più casino, comunque credo tu abbia capito.

Si.

[marko.fatto]

mi sono letto tutto il thread adesso, mi sembrava di essere di nuovo a lezione di architettura xD

non riuscirò ad intervenire ma seguirò la discussione

[Z80Fan]

Originariamente inviato da marko.fatto

mi sono letto tutto il thread adesso, mi sembrava di essere di nuovo a lezione di architettura xD

non riuscirò ad intervenire ma seguirò la discussione

[cdimauro]

Originariamente inviato da cionci

Invece secondo me sarebbe molto interessante lavorare su un RISC con parallelizzazione esplicita e con indicazione esplicita delle dipendenze.
Ovviamente allungherebbe l'opcode, ma semplificherebbe altre cose. Ad esempio l'esecuzione potrebbe essere in-order, o al limite anche out-of-order ma in base al raggruppamento.
Consideriamo anche che essendo RISC l'analisi delle dipendenze da parte del compilatore è molto più semplice visto il numero ridotto di opcode...

Faccio un esempio: supponiamo di avere due LOAD/STORE pipeline...

grp dep
 1   0    LOAD  R0, op1 
 1   0    LOAD  R1, op2 
 2   1    LOAD  R2, op3 
 3   1    ADD   R0, R1
 3   2    SUB   R0, R2
 4   3    SHR   R0, 6
 1   0    LOAD  R3, op4
 1   4    STORE op1, R0

Credo che con 8 bit per il gruppo e 8 per la dipendenza siano sufficienti.

Mi ricorda molto questo: http://en.wikipedia.org/wiki/Itanium

e non è che brilli (come molti VLIW) per prestazioni GP...

Originariamente inviato da Z80Fan

Quindi l' Xn*scale deve essere inteso come un campo che indica la lunghezza di ogni struttura? Quindi un vettore di quad lo scorri così:

       MOV.Q    vett, A0
       QMOVEU   8, D7
ciclo: MOV.Q [A0, D7, 0]+, D0
       <elabora>
       Bcc ciclo

?

Esattamente. L'indice non serve, ma è sufficiente l'offset per scorrere tutti gli elementi che ci servono.

Di questo passo non ci servirà neanche la codifica a 32 bit!

No, quella serve. Mica hai visto quello che ho combinato con quei preziosi 28 bit.

Concordo, il design è lineare; sarà quando dobbiamo scrivere il microcodice per l'unità di calcolo indirizzi che ci sarà da ridere!

In tutte le implementazioni più avanzate della famiglia 68000 (quindi dal 68040 in poi), c'è un apposito stadio della pipeline che fa solo quello. Il 68060 per quasi tutti gli indirizzamenti semplici (cioè non quelli che hanno la DOPPIA indirezione in memoria) non ha nessun ciclo di clock aggiuntivo.

Il 68050 (chiamato N050) del progetto Natami a cui stanno lavorando impiega anch'esso un singolo ciclo di clock nello stadio di calcolo dell'EA della pipeline per queste modalità, tranne appunto quelle con doppia indirezione (che anche noi non abbiamo).

Il fatto è che i CISC complicati di un tempo non avevano pipeline efficienti come quelle più moderne, ovviamente, ma a meno di non esagerare non ci dovrebbero essere difficoltà.

[Z80Fan]

Originariamente inviato da cdimauro

Esattamente. L'indice non serve, ma è sufficiente l'offset per scorrere tutti gli elementi che ci servono.

Allora, in modo da semplificare l'AGU, si potrebbero omettere le istruzioni che usano indice * scala? Così non dobbiamo neanche controllare per il fetch dell'estensione...

Originariamente inviato da cdimauro

No, quella serve. Mica hai visto quello che ho combinato con quei preziosi 28 bit.

Ho paura (in senso buono )

Originariamente inviato da cdimauro

tranne appunto quelle con doppia indirezione (che anche noi non abbiamo).

Come no?

MOVE.Size Source EA, Destination EA
15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
0    0   | Size    |Dest. Mode     |Dest. Register|Source Mode   |Source Reg.|

In questa non puoi anche specificare 2 indirizzi di memoria? O intendi dire "prelevare dalla memoria il puntatore al dato" (in C: *(*ptr) ) ?

[cdimauro]

Originariamente inviato da Z80Fan

Allora, in modo da semplificare l'AGU, si potrebbero omettere le istruzioni che usano indice * scala? Così non dobbiamo neanche controllare per il fetch dell'estensione...

Ma perché ti darebbe fastidio l'estensione?

Ho paura (in senso buono )

Fai bene ad averne.

Come no?

MOVE.Size Source EA, Destination EA
15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
0    0   | Size    |Dest. Mode     |Dest. Register|Source Mode   |Source Reg.|

In questa non puoi anche specificare 2 indirizzi di memoria? O intendi dire "prelevare dalla memoria il puntatore al dato" (in C: *(*ptr) ) ?

La seconda che hai detto. Che come programmatore mi fa venire l'acquolina in bocca (e col 68EC020 del mio fido Amiga 1200 le ho usate un bel po' di volte), ma a livello di implementazione mi rendo perfettamente conto che è un vero inferno.

EDIT: qui c'è il commento di Gunnar delle 18:53 in cui mostra come funziona la pipeline dell'N050 a cui sta lavorando.

[cionci]

Originariamente inviato da cdimauro

Mi ricorda molto questo: http://en.wikipedia.org/wiki/Itanium

e non è che brilli (come molti VLIW) per prestazioni GP...

E' chiaro che te lo ricordi, dopo tutto c'è parallelismo esplicito. La differenza è che Itanium ha un set di istruzioni complesso e 3 istruzioni per opcode, mentre questo ha un set di istruzioni simil RISC. L'idea era appunto quella di creare una CPU con molte unità di esecuzione, ma con pipeline relativamente corta e semplice. Quindi critical path corto e frequenze alte.
Magari assegnando l'unità di calcolo ancora prima della fase di decodifica in base a quel numerino e al tipo di istruzione, semplificando quindi ulteriormente la gestione interna del decoder.
L'assegnazione delle unità di calcolo può essere fatto tramite una specie di priorità rotante.
Ad esempio dovrebbe funzionare un algoritmo di questo tipo (utilizzando l'idea di Z80Fan per la precedenza):

ALU(i) = ALU(i-1) + prec(i) - prec(i-1)
LSU(i) = ALU(i-1) + prec(i) - prec(i-1)

Secondo me può essere tranquillamente fatto in fase di fetch.
Ovviamente è un conto che andrebbe fatto tutto in modulo (è più semplice farlo in hardware).
Dopo la fase di decode si duplicano le varie unità. Si bloccano le unità che hanno indici di precedenza uguali a quelli in esecuzione.
In fase di esecuzione ricordiamoci che siamo sicuri che non ci siano dipendenze, quindi si possono scrivere direttamente i risultati nei registri e liberare le istruzioni dipendenti già nella fase di esecuzione (ovviamente solo se la destinazione è un registro).