[Asm] Progettare una architettura di processore

[MaxArt]

Insomma la "riga 0" non si può leggere come un unico registro ad 8 bit, ma sempre e solo come R0 e R1...

[lupoxxx87]

in effetti.....sorgerebbe un problema .... in quanto operazioni tra due coppie di registri andrebbero in overflow.

bisognerebbe usare una coppia di accumulatori

[cdimauro]

Originariamente inviato da MaxArt

Ma a dire il vero anche queste sarebbero già "decodificate", solo che anziché una manciata di codifiche qui ce ne sono 256 (anzi, anche qualcuna di meno), ognuna già pronta con dimensione e posizione del registro.

Ma non sono già decodificate, perché utilizzano un codice prefisso per ricavare prima la dimensione del registro, e poi quale usare.

Per avere "già pronti" dimensione e posizione devi pertanto operare nel seguente modo:
- estrarre i 4 primi bit;
- usando una LUT ricavare la dimensione (valore a 3 bit, magari da 0 a 4: 0-> 8 bit, 1 -> 16 bit, ecc.) e la maschera (7 bit) da usare per estrarre la posizione;
- usare gli ultimi 7 bit facendo un and logico con la maschera del precedente punto per ricavare la posizione.

Questo se vogliamo risparmiare spazio, visto che le LUT costano.

Per averli già pronti servirebbe una LUT da 8 bit che ritorni due dati, a 3 e 7 bit, che però è ben più costosa.

Ma magari mi sto facendo delle seghe mentali per lo spazio, visto che ormai abbiamo chip da miliardi di transistor.

Comunque rimane il fatto che per poter disporre dei dati che ci servono è necessario un passo in più, per estrarli.

Il mio discorso si riferiva al fatto che bastano 8 bit per indicare tutti i registri possibili.

Sì, però mi sembra un grosso spreco di spazio (per l'opcode). Tanto per fare un esempio, nella mia implementazione sto usando 2 bit per la dimensione (da 8 a 64 bit) e 3 per il registro, e con gli opcode che occupano 16 bit sono già con l'acqua alla gola.

Però potrebbe essere interessante il tuo schema per avere più registri sfruttando lo spazio a disposizione.

Può darsi che aggiungendo un solo stadio nella pipeline al solo scopo di estrarre questi dati si possa ottenere comunque un vantaggio. Ma dipende strettamente dall'uso che ne farebbe un compilatore e/o un programmatore. Perché se è vero che 128 registri a 8 bit sono tantissimi e fanno venire l'acquolina in bocca, è anche vero che pensare di sfruttarli tutti è pura utopia.

Quindi nella scelta della caratteristiche da implementare serve anche un po' di sano pragmatismo.

[cdimauro]

Originariamente inviato da lupoxxx87

il fatto di avere un registro fisso come accumulatore è più semplice, almeno a mio dire, da realizzare sul circuito del processore.

Sarà più semplice, ma è decisamente obsoleto.

Tanto per dire, i 68000 hanno 8 registri dati indistinti: con ognuno di essi puoi fare esattamente le stesse cose. E i compilatori (e i programmatori pure, che non devono ricordarsi "eccezioni" al modello) ringraziano per l'ortogonalità.

[MaxArt]

Originariamente inviato da cdimauro

Ma magari mi sto facendo delle seghe mentali per lo spazio, visto che ormai abbiamo chip da miliardi di transistor.

Più che altro pensavo a questo fattore, visto che se vogliamo fare un processore possiamo operare in una logica più moderna.

D'altra parte, se vogliamo un processore moderno allora bisognerebbe metterci qualche altra corbelleria tipo la gestione OOO (e qui so' cazzi ).
Più che altro mi pareva un'idea molto flessibile, tutto qui

[Z80Fan]

Wow, avete già fatto 2 pagine!

x MaxArt:
è un'idea interessante, molto utile per usare ogni byte a disposizione, ma decisamente complesso per decodificare la dimensione (come ha già spiegato bene Cesare). Invece di usare campi di bit "variabili" per identificare la dimensione (1 = 64, 10 = 32, 100 = 16 ecc...), puoi usare 2 bit "fissi", che ti danno quelle 4 combinazioni (8,16,32,64) che ti servono, e usare gli altri per definire il registro vero e proprio. La differenza, in questo caso, è che avrai la stessa quantità di registri da 8, da 16 (ecc) bit, e la cosa può piacere o no.

Originariamente inviato da MaxArt

Ecco, questa è una cosa che non ho mai ben capito dei processori, almeno quelli moderni. Cioè, dover attribuire per forza un "compito" specifico ai registri.

Veramente, solo l'architettura x86 ancora oggi continua a imporre registri specifici per ogni operazione. Tutti i Risc lasciano ampia libertà al programmatore (a parte un paio di registri, come il program counter e il link register), anche un cisc come il 68k fornisce molta libertà!

x lupoxxx87:

Originariamente inviato da lupoxxx87

il bit più significativo se sarà 0 indicherà che la modalità "ad estensione di registri" è disattivata, 1 altrimenti;

Mi sembra più un' idea da "retrocompatibilità": avevi già un uP a 4 bit, e lo vuoi portare a 8 bit. Se il nuovo programma è a 8 bit, si imposta il bit di controllo ed entra in 8 bit. Un po' come cambiare tra modalità reale->protetta->long. La dimensione dell'operando andrebbe messa nell'istruzione, perchè metti che il tuo codice stà lavorando su una lista di elementi, ognuno di questi a 8 bit (e gli indirizzi sono a 64): dovresti continuamente cambiare modalità per prima operare sul dato (8), e poi lavorare sui puntatori (64) per scorrere i nodi della lista.

Originariamente inviato da lupoxxx87

il fatto di avere un registro fisso come accumulatore è più semplice, almeno a mio dire, da realizzare sul circuito del processore.

Non necessariamente.

Cmq, e se avessimo tipo 16/32 registri, tutti a 64 bit, ma che posso specificare al volo la dimensione da contenere? Cioè, ad un registro posso far contenere un dato a 8, 16, 32 o 64 bit, se è a 8 il dato occuperà il byte meno significativo dei 64, se è a 16 occuperà i 2 meno significativi ecc..., e poi nell'istruzione decidiamo quanto usarne. Vantaggio: è molto più semplice da costruire (basta aggiungere una riga di AND per mascherare solo i dati che ci interessano, sia in ingresso sia in uscita dal banco registri); svantaggio: se usi dati piccoli, sprechi la parte alta dei registri (ma se ti sta a cuore lo spazio, puoi usare degli shift per caricare anche in alto, poi possiamo dire al processore di non azzerare automaticamente la parte alta del registro quando carichiamo un nuovo dato piccolo).

[Z80Fan]

Una cosa che mi sarebbe piaciuta implementare, è una serie di istruzioni che fanno il cmp e poi il salto condizionato adatto, p.es:

cje    R0, R1, etichetta    ; compara e salta se uguale
cjne   R0, R2, etichetta    ; compara e salta se non uguale
ecc...

Si migliorerebbe la densità del codice, visto che i salti sono quasi sempre accompagnati da un test.
Se rimane spazio si possono anche creare le istruzioni con i dati immediati

cje    R0,  5, etichetta    ; compara e salta se uguale
cjne   R0, 26, etichetta    ; compara e salta se non uguale
ecc...

(bisognerà però mettere un limite sulla costante, sennò non ci entra nell'istruzione insieme alla destinazione del salto, che sarà sicuramente un offset dall'attuale)

[cdimauro]

Originariamente inviato da MaxArt

Più che altro pensavo a questo fattore, visto che se vogliamo fare un processore possiamo operare in una logica più moderna.

Secondo me non è il contesto giusto. Avevo avuto la stessa idea una venticinquina d'anni fa, quando stavo progettando l'ISA del mio microprocessore a 1024 bit (non scherzo).

Però per i registri non va bene. Per altro, invece, è utile; infatti ne ho adottato una codifica particolare per un'istruzione simile alla IF degli ARM, per l'esecuzione condizionata di un certo numero di istruzioni.

D'altra parte, se vogliamo un processore moderno allora bisognerebbe metterci qualche altra corbelleria tipo la gestione OOO (e qui so' cazzi ).

E' da un pezzo che ci penso, ma francamente non è chiaro che tipo di accelerazione potrebbe giovare. La vTable, alla fine, è una tabella di puntatori, e si gestisce già; le variabili d'istanza sono campi di un record / struct, e si gestiscono già.

Più che altro mi pareva un'idea molto flessibile, tutto qui

Lo è, ma applicata ad altri contesti, come dicevo prima.

Originariamente inviato da Z80Fan

Una cosa che mi sarebbe piaciuta implementare, è una serie di istruzioni che fanno il cmp e poi il salto condizionato adatto, p.es:

cje    R0, R1, etichetta    ; compara e salta se uguale
cjne   R0, R2, etichetta    ; compara e salta se non uguale
ecc...

Si migliorerebbe la densità del codice, visto che i salti sono quasi sempre accompagnati da un test.

Nell'attuale ISA "short" a 16 bit non l'ho prevista, perché sono già con l'acqua alla gola, in quanto lo spazio è quasi del tutto esaurito (ebbene sì: alle 3 di notte ero ancora a cazzeggiare coi pattern delle istruzioni ), ma nell'opcode a 32 bit dovrebbe esserci abbastanza spazio (ho già messo una DBcc per eseguire loop condizionati, ma con contatore anche a 64 bit; Motorola-style anche questo ovviamente ).

Se rimane spazio si possono anche creare le istruzioni con i dati immediati

cje    R0,  5, etichetta    ; compara e salta se uguale
cjne   R0, 26, etichetta    ; compara e salta se non uguale
ecc...

(bisognerà però mettere un limite sulla costante, sennò non ci entra nell'istruzione insieme alla destinazione del salto, che sarà sicuramente un offset dall'attuale)

Esatto. Negli opcode a 16 bit ho messo una QCMP che accetta soltanto valori da -1 a 2: non c'è altro spazio; comunque si tratta di valori molto comuni per i confronti, per cui dovrebbe bastare. Per le altre costanti c'è sempre la classica CMP con valore immediato:

CMP.Q $123456789ABCDEF0,D0

[Z80Fan]

Originariamente inviato da cdimauro

Secondo me non è il contesto giusto. Avevo avuto la stessa idea una venticinquina d'anni fa, quando stavo progettando l'ISA del mio microprocessore a 1024 bit (non scherzo).

Caspita, ti servivano 1,559250242e290 EiB di memoria? Di sicuro avevi spazio per gli opcode

Originariamente inviato da cdimauro

E' da un pezzo che ci penso, ma francamente non è chiaro che tipo di accelerazione potrebbe giovare. La vTable, alla fine, è una tabella di puntatori, e si gestisce già; le variabili d'istanza sono campi di un record / struct, e si gestiscono già.

Ti sei fregato anche te, penso che MaxArt intendesse dire "Out Of Order", non "Object Oriented"

Originariamente inviato da cdimauro

Nell'attuale ISA "short" a 16 bit non l'ho prevista, perché sono già con l'acqua alla gola, in quanto lo spazio è quasi del tutto esaurito (ebbene sì: alle 3 di notte ero ancora a cazzeggiare coi pattern delle istruzioni ), ma nell'opcode a 32 bit dovrebbe esserci abbastanza spazio (ho già messo una DBcc per eseguire loop condizionati, ma con contatore anche a 64 bit; Motorola-style anche questo ovviamente ).

Esatto. Negli opcode a 16 bit ho messo una QCMP che accetta soltanto valori da -1 a 2: non c'è altro spazio; comunque si tratta di valori molto comuni per i confronti, per cui dovrebbe bastare. Per le altre costanti c'è sempre la classica CMP con valore immediato:

CMP.Q $123456789ABCDEF0,D0

Deduco che vuoi fare un'architettura con opcode a lunghezza differente. Penso che si possa fare anche con opcode a lunghezza fissa, e usando dei "trucchi" e pseudo-istruzioni si può risparmiare qualche istruzione (ad esempio, se il program counter è accessibile, si può risparmiare una istruzione sul caricamento di un immediato con una istruzione tipo mov registro, [PC++]. Ovviamente il ++ aumenterà di tanto quanto è la costante caricata. Oppure, per creare uno stack si usa mov reg, [SP++] e mov [--SP], reg , si risparmia su push e pop). Cosa ne pensi?

[cdimauro]

Originariamente inviato da Z80Fan

Caspita, ti servivano 1,559250242e290 EiB di memoria? Di sicuro avevi spazio per gli opcode

Ero giovane e immaturo. Figurati che avevo disegnato pure una tastiera gigantesca con centinaia e centinaia di tasti (tutti quelli che avevo visto in altre tastiere e altri che ritenevo utili).

Ti sei fregato anche te, penso che MaxArt intendesse dire "Out Of Order", non "Object Oriented"

Hum. Hai ragione. Colpa della OOP, che mi fa stravedere.

Deduco che vuoi fare un'architettura con opcode a lunghezza differente.

Io sono un amante dei CISC. Fai tu.

Penso che si possa fare anche con opcode a lunghezza fissa, e usando dei "trucchi" e pseudo-istruzioni si può risparmiare qualche istruzione (ad esempio, se il program counter è accessibile, si può risparmiare una istruzione sul caricamento di un immediato con una istruzione tipo mov registro, [PC++]. Ovviamente il ++ aumenterà di tanto quanto è la costante caricata.

Che però dovrebbe essere allineata sempre a 32 bit, ad esempio (supponendo che gli opcode a dimensione fissa siano di 4 byte, appunto).

In ogni caso il comportamento è esattamente come quello di un CISC con opcode a dimensione variabile.

Oppure, per creare uno stack si usa mov reg, [SP++] e mov [--SP], reg , si risparmia su push e pop). Cosa ne pensi?

Considera che Motorola coi 68000 faceva già così, usando A7 (l'ultimo dei registri indirizzi) come SP.

Io, invece, ho dedicato un apposito registro. Per due motivi: il primo è che così libero un registro indirizzi. Il secondo è che il set di registri diventa completamente general purpose (nessun registro specializzato), per cui compilatori e programmatori ringraziano.

Altra cosa, in questo modo SP lo posso gestire come voglio in termini di allineamento.

[cdimauro]

Penso di aver completato la tabella degli opcode a 16 bit.

Appena ho tempo (devo sospendere perché mercoledì ho il solito appuntamento con AD ) mi metto a lavoro su quella 32 bit (che è ben più complessa).

[Z80Fan]

Originariamente inviato da cdimauro

Che però dovrebbe essere allineata sempre a 32 bit, ad esempio (supponendo che gli opcode a dimensione fissa siano di 4 byte, appunto).

Non necessariamente, è la pigrizia dei progettisti RISC a imporre questa limitazione

Originariamente inviato da cdimauro

Considera che Motorola coi 68000 faceva già così, usando A7 (l'ultimo dei registri indirizzi) come SP.

Io, invece, ho dedicato un apposito registro. Per due motivi: il primo è che così libero un registro indirizzi. Il secondo è che il set di registri diventa completamente general purpose (nessun registro specializzato), per cui compilatori e programmatori ringraziano.

Altra cosa, in questo modo SP lo posso gestire come voglio in termini di allineamento.

Ma se non usi le istruzione apposite, puoi creare anche più di uno stack contemporaneamente, perchè puoi usare qualsiasi registro come SP. E anche in questo caso puoi gestire te l'allineamento, perchè si può decidere nelle istruzioni se pre/post inc/decrementare di 1,2,4,8 byte. Tu dici che lo SP è riservato perchè quando esegui "call", il uP salva l'indirizzo di ritorno sullo stack. So che non ti piacerà (), ma usando il link register, risparmi un accesso alla memoria sia in call sia in ret, e la funzione sa da sola se deve salvarsi il ritorno (in caso debba fare essa stessa una chiamata). Oppure, senza link, si dice a call e a ret quale registro usare come stack su cui salvare o ripristinare l'indirizzo. Questo ha 2 vantaggi: si possono usare 2 stack, uno per i parametri e uno per gli indirizzi di ritorno. Ovviamente le funzioni devono usare gli stessi registri (almeno sullo stesso sistema).

Poi, c'è un vantaggio a usare differenti registri per i dati e per gli indirizzi? Perchè in questo caso stai dando una limitazione ai compilatori e ai programmatori: metti che devi unire 10 vettori in uno ordinato, finiscono i registri indirizzo. O è solo per risparmiare un bit nell'istruzione?

Comincio a buttare giù la mia versione del set istruzioni, così possiamo discutere meglio.

[MaxArt]

Originariamente inviato da Z80Fan

Invece di usare campi di bit "variabili" per identificare la dimensione (1 = 64, 10 = 32, 100 = 16 ecc...), puoi usare 2 bit "fissi", che ti danno quelle 4 combinazioni (8,16,32,64) che ti servono, e usare gli altri per definire il registro vero e proprio. La differenza, in questo caso, è che avrai la stessa quantità di registri da 8, da 16 (ecc) bit, e la cosa può piacere o no.

L'idea alla base era la flessibilità. Con 2 bit per definire la lunghezza dei registri impedisce di fatto in un futuro di definire registri più grandi. Nell'altro metodo sarebbe più veloce?

Veramente, solo l'architettura x86 ancora oggi continua a imporre registri specifici per ogni operazione.

E dici poco, sono i più diffusi al mondo (nonché quelli che conosco meglio).
Mi ricordo anche che gli Z80 avevano registri specifici, e tu di certo puoi confermarlo o smentirlo. Beh, gli Z80 si usano ancora

Non necessariamente.

Originariamente inviato da cdimauro

Però per i registri non va bene. Per altro, invece, è utile; infatti ne ho adottato una codifica particolare per un'istruzione simile alla IF degli ARM, per l'esecuzione condizionata di un certo numero di istruzioni.

Puoi spiegare meglio questo punto?
Quali contesti ne gioverebbero e perché?

Originariamente inviato da Z80Fan

Ti sei fregato anche te, penso che MaxArt intendesse dire "Out Of Order", non "Object Oriented"

Già...

Originariamente inviato da cdimauro

Penso di aver completato la tabella degli opcode a 16 bit.

Porca miseria, hai fatto tutto tu...
Ma si può vedere qualcosa? Altrimenti come faccio ad imparare?

[Z80Fan]

Originariamente inviato da MaxArt

L'idea alla base era la flessibilità. Con 2 bit per definire la lunghezza dei registri impedisce di fatto in un futuro di definire registri più grandi. Nell'altro metodo sarebbe più veloce?

Si, sarebbe più veloce perchè basterebbe prendere i 2 bit così come sono e portarli al circuito adatto di selezione registri. Nel tuo metodo, invece, bisogna prima decodificare il valore del byte, e poi inviarlo alla selezione. Cmq, non è impossibile da implementare la tua versione: non è necessaria una LUT come ha detto Cesare, basta solo un decoder a priorità (posso farvi il circuito se volete capire meglio).
Cmq l'idea non è cattiva, per niente, ma la limitazione c'è lo stesso: se usi 8 bit per il campo registri, arriveresti al massimo a 2 registri da 512 bit, perchè poi non hai lo spazio fisico nell'istruzione per espandere il suddetto campo (sempre se vuoi mantenere la retrocompatibilità con i precedenti programmi)

Originariamente inviato da MaxArt

E dici poco, sono i più diffusi al mondo (nonché quelli che conosco meglio).
Mi ricordo anche che gli Z80 avevano registri specifici, e tu di certo puoi confermarlo o smentirlo. Beh, gli Z80 si usano ancora

Certo, anche lo Z80 aveva una marea di registri riservati (A accumulatore, coppia HL per puntatore in memoria, coppie BC e DE se volevi per puntatori a memoria, ma solo se per destinazione/sorgente avevi A, IX e IY per puntare la memoria con offset a 8bit.), ma è stato fatto per mantenere la retrocompatibilità con l'8080. Difatti, il povero Z8000, che non era stato pensato per essere retrocompatibile, aveva un set di istruzioni completamente ortogonale (o quasi).

Originariamente inviato da MaxArt

Porca miseria, hai fatto tutto tu...
Ma si può vedere qualcosa? Altrimenti come faccio ad imparare?

Calma, calma

[MaxArt]

Originariamente inviato da Z80Fan

Cmq l'idea non è cattiva, per niente, ma la limitazione c'è lo stesso: se usi 8 bit per il campo registri, arriveresti al massimo a 2 registri da 512 bit, perchè poi non hai lo spazio fisico nell'istruzione per espandere il suddetto campo (sempre se vuoi mantenere la retrocompatibilità con i precedenti programmi)

Sticazzi, quando ci sarà bisogno di registri a 512 bit si rifà un'ISA tutta daccapo
Guarda un po' che fatica che si sta facendo a passare ai 64 bit... (e non è solo una questione di x86).

Calma, calma

Calma perché? Io sono curioso!

[Z80Fan]

Originariamente inviato da MaxArt

Guarda un po' che fatica che si sta facendo a passare ai 64 bit... (e non è solo una questione di x86).

Si, è solo questione di x86 e retrocompatibilità
Basta solo ricompilare le applicazioni, e si avrebbe già tutto a 64 bit (beh, non si avrebbero da subito tutte le capacità, perchè bisogna anche un po' ottimizzare il sorgente, tipo sulla dimensione delle variabili). Non si passa in bomba ai 64 (almeno su x86 e Windows) perchè ci sono ancora tantissimi computer con cpu a 32bit, e perchè molti produttori sono pigri (puoi farti una distro Linux con tutti i programmi a 64 bit, semprechè non ti interessi avere Flash in Firefox )

[MaxArt]

No, non è solo questione di x86. A parte il casino che c'è stato coi G5 a "64 bit" (per poi essere in realtà solo un lontano parente di un processore a 64 bit), il problema sta anche nei sistemi operativi che non si aggiornano ma soprattutto negli interi più lunghi che ti obbligano ad avere:
- assai più RAM;
- dischi più grandi e più veloci;
- bus più ampi e veloci.
Per molte applicazioni anche 32 bit sono troppi: prendine una, che so, che ti fa da sveglia...
Un editor di testo non vedo che necessità abbia dei 64 bit (file di testo più grandi di 4 GB? ORLY? ) . E si può continuare. Da qui l'inerzia per passare ad architetture più complesse.

[Z80Fan]

Originariamente inviato da MaxArt

No, non è solo questione di x86. A parte il casino che c'è stato coi G5 a "64 bit" (per poi essere in realtà solo un lontano parente di un processore a 64 bit), il problema sta anche nei sistemi operativi che non si aggiornano ma soprattutto negli interi più lunghi che ti obbligano ad avere:
- assai più RAM;
- dischi più grandi e più veloci;
- bus più ampi e veloci.

Non è detto che un'applicazione compilata per 64 bit debba per forza usare interi a 64 bit: le opzioni standard di compilazione su un amd64 sono di avere int a 32 bit, quindi non cambia nulla. Se vuoi un dato grande, usi un long. I puntatori invece diventano tutti a 64 bit. Poi dipende dall'architettura: se per aggiungere le istruzioni a 64 bit hanno messo diecimila byte di prefisso, è ovvio che i programmi son più grandi
Riguardo ai bus: già dal pentium 4 abbiamo avuto bus dati a 64 bit (se non addirittura prima)

Per molte applicazioni anche 32 bit sono troppi: prendine una, che so, che ti fa da sveglia...
Un editor di testo non vedo che necessità abbia dei 64 bit (file di testo più grandi di 4 GB? ORLY? ) . E si può continuare. Da qui l'inerzia per passare ad architetture più complesse.

Non è solo per la quantità di memoria indirizzabile che si passa ai 64 bit: si può usare la maggior banda per poter spostare efficacemente grande quantità di dati (visto che i pc non hanno un dma che opera memoria-memoria). Se parliamo di Blocco note, ovvio la velocità non si sente, ma se prendiamo software un pochino più su, che permettono di gestire immagini, font, colori ... il calcolo della posizione degli oggetti, o il render della pagina attuale la deve fare la cpu (a meno che non si modifichi radicalmente l'applicativo e gli si faccia usare la GPU, ma allora già che ci sono possono cmq portarlo a 64 bit )
Cmq, in ultima analisi, la colpa è anche del corrente set di istruzioni, che riprende dall'x86: se avessero tagliato completamente, ridisegnato il set, e relegato l'emulazione ad un altro strato, in un futuro si sarebbe potuto togliere completamente il supporto al 32 bit e lasciare solo il sistema a 64. Invece ci tocca cmq all'avvio del sistema passare dalla modalità 32 bit, e già questo ci blocca dal poterla togliere.

[cdimauro]

Originariamente inviato da Z80Fan

Non necessariamente, è la pigrizia dei progettisti RISC a imporre questa limitazione

No, non è pigrizia: è una filosofia. Coi RISC si cerca di risparmiare al massimo sull'architettura introducendo eventualmente vincoli (anche rigidi). Quello degli opcode tutti allineati alla dimensione degli stessi è un classico esempio; d'altra parte secondo te avrebbe senso avere che fossero non allineati, quando la dimensione rimane sempre la stessa?

Ma se non usi le istruzione apposite, puoi creare anche più di uno stack contemporaneamente, perchè puoi usare qualsiasi registro come SP. E anche in questo caso puoi gestire te l'allineamento, perchè si può decidere nelle istruzioni se pre/post inc/decrementare di 1,2,4,8 byte.

No, perché, ad esempio, su 68000 per questioni di efficienza il "push" di un byte sullo stack (A7) salva comunque una word (16 bit), mentre con gli altri registri indirizzo viene preservata la giusta dimensione.

Tu dici che lo SP è riservato perchè quando esegui "call", il uP salva l'indirizzo di ritorno sullo stack.

Anche per questo; di fatto SP/A7 è già specializzato. In ogni caso un processore deve sempre avere uno stack definito.

Tanto vale, a questo punto, fornirgli un apposito registro, e liberare un prezioso registro per un uso più generale.

So che non ti piacerà (), ma usando il link register, risparmi un accesso alla memoria sia in call sia in ret, e la funzione sa da sola se deve salvarsi il ritorno (in caso debba fare essa stessa una chiamata). Oppure, senza link, si dice a call e a ret quale registro usare come stack su cui salvare o ripristinare l'indirizzo. Questo ha 2 vantaggi: si possono usare 2 stack, uno per i parametri e uno per gli indirizzi di ritorno. Ovviamente le funzioni devono usare gli stessi registri (almeno sullo stesso sistema).

Sì, come soluzione quella del registro di link non mi piace molto, perché puoi salvare un solo indirizzo di ritorno alla volta: dopo ti costringe a eseguire comunque un push sullo stack, e poi un restore.

Se consideri che molti processori moderni hanno una sezione di call-stack, capisci bene che il caso comune non è certo quello di un insieme di funzioni flat che poi non richiamano nessuno. Per questo ho preferito usare il classico stack per l'indirizzo di ritorno.

Ma quella del registro link è un'idea che potrebbe essere presa in considerazione. D'altra parte ho pure aggiunto un registro per il Frame Pointer (FP) e apposite istruzioni (LINK, UNLINK, PUSH FP, POP FP, MOVE FP,An, MOVE An,FP) per poterlo gestire, per cui si potrebbe fare la stessa cosa (anche se ormai nella tabella degli opcode a 16 bit sono rimasti una decina di posti ).

Poi, c'è un vantaggio a usare differenti registri per i dati e per gli indirizzi?

Sì, perché ti permette di realizzare delle ALU ottimizzate.

Ad esempio per aggiornare un registro indirizzi basta che l'ALU dedicata implementi le operazioni di somma, differenza, confronto, e hai finito. In questo modo l'ALU che si occupa di effettuare il calcolo dell'indirizzo si può usare indifferentemente per la sezione AGU e per l'aggiornamento di un registro indirizzi.

Perchè in questo caso stai dando una limitazione ai compilatori e ai programmatori: metti che devi unire 10 vettori in uno ordinato, finiscono i registri indirizzo.

Qualunque tu ponga al numero di registri, troverai sempre un pezzo di codice che ne richiede di più.

O è solo per risparmiare un bit nell'istruzione?

Anche per quello.

Comincio a buttare giù la mia versione del set istruzioni, così possiamo discutere meglio.

OK

Originariamente inviato da MaxArt

Puoi spiegare meglio questo punto?
Quali contesti ne gioverebbero e perché?

Stasera ti posto la struttura dell'istruzione IF e ti faccio vedere come ho utilizzato il concetto di codice prefisso per definire le 8 modalità in cui opera.

Un esempio "sul campo" penso che valga meglio di qualunque spiegazione.

Porca miseria, hai fatto tutto tu...

Sono stato facilitato dalla mia esperienza con le architetture degli elaboratori, ma considera che sono anni che ho in mente una mia ISA (erede dei 68000 ).

Diciamo che l'aperto di questo thread mi ha dato la possibilità di riversare su un progetto concreto tutte le masturb, ehm, le idee che mi sono fatto in questo tempo.

Ma si può vedere qualcosa? Altrimenti come faccio ad imparare?

Certo. Stasera posto la prima versione, con l'intera opcode table a 16 bit, con l'aggiunta di qualche opcode a 32 bit.

Considera che al momento mi sono concentrato quasi esclusivamente sul funzionamento dello user mode. Per il supervisor mode ho già un po' di idee (mi piace molto il modello ARM), ma ci penserò dopo.

Originariamente inviato da Z80Fan

Si, sarebbe più veloce perchè basterebbe prendere i 2 bit così come sono e portarli al circuito adatto di selezione registri. Nel tuo metodo, invece, bisogna prima decodificare il valore del byte, e poi inviarlo alla selezione. Cmq, non è impossibile da implementare la tua versione: non è necessaria una LUT come ha detto Cesare, basta solo un decoder a priorità (posso farvi il circuito se volete capire meglio).

Una LUT è, però, estremamente veloce (e considerata la dimensione della tabelle, è pure economica) e semplicissima da realizzare.

Originariamente inviato da MaxArt

Sticazzi, quando ci sarà bisogno di registri a 512 bit si rifà un'ISA tutta daccapo

Non credo che avremo ISA a 128 bit, né tanto meno a 512.

Originariamente inviato da MaxArt

No, non è solo questione di x86. A parte il casino che c'è stato coi G5 a "64 bit" (per poi essere in realtà solo un lontano parente di un processore a 64 bit),

I G5 erano a 64 bit a tutti gli effetti. Certo, perdevi il 10-15% di prestazioni in questa modalità, ed è il motivo per cui da un lato Apple la pubblicizzava (sempre per una questione di puro marketing: "64 bit" è più lungo di "32 bit"), dall'altro consigliava agli sviluppatori di usarli solo dopo attenta valutazione dei pro e dei contro.

Originariamente inviato da Z80Fan

Non è detto che un'applicazione compilata per 64 bit debba per forza usare interi a 64 bit: le opzioni standard di compilazione su un amd64 sono di avere int a 32 bit, quindi non cambia nulla. Se vuoi un dato grande, usi un long. I puntatori invece diventano tutti a 64 bit. Poi dipende dall'architettura: se per aggiungere le istruzioni a 64 bit hanno messo diecimila byte di prefisso, è ovvio che i programmi son più grandi

Sono leggermente più grandi, dai.

Riguardo ai bus: già dal pentium 4 abbiamo avuto bus dati a 64 bit (se non addirittura prima)

Con gli x86 è arrivato addirittura col primo Pentium.

Non è solo per la quantità di memoria indirizzabile che si passa ai 64 bit: si può usare la maggior banda per poter spostare efficacemente grande quantità di dati (visto che i pc non hanno un dma che opera memoria-memoria). Se parliamo di Blocco note, ovvio la velocità non si sente, ma se prendiamo software un pochino più su, che permettono di gestire immagini, font, colori ... il calcolo della posizione degli oggetti, o il render della pagina attuale la deve fare la cpu (a meno che non si modifichi radicalmente l'applicativo e gli si faccia usare la GPU, ma allora già che ci sono possono cmq portarlo a 64 bit )

Per molte cose ci sono le unità SIMD, ed è il motivo per cui QUI servono registri con più di 64 bit.

Cmq, in ultima analisi, la colpa è anche del corrente set di istruzioni, che riprende dall'x86: se avessero tagliato completamente, ridisegnato il set, e relegato l'emulazione ad un altro strato, in un futuro si sarebbe potuto togliere completamente il supporto al 32 bit e lasciare solo il sistema a 64. Invece ci tocca cmq all'avvio del sistema passare dalla modalità 32 bit, e già questo ci blocca dal poterla togliere.

Nessuno t'impedisce di realizzare un processore con ISA AMD64-only. Anzi, personalmente è quel che farei se fossi nei panni di AMD o Intel.

Comunque ad AMD rimprovero un'altra cosa: AMD64 non è compatibile a livello binario con x86, per cui sei costretto a ricompilare i sorgenti e ad adattarli (poco, per fortuna). Tanto valeva sistemare l'ISA a 64 bit razionalizzando la tabella degli opcode (tanto per cambiare, avrei utilizzato una opcode table a 16 bit ).

[Z80Fan]

Originariamente inviato da cdimauro

No, perché, ad esempio, su 68000 per questioni di efficienza il "push" di un byte sullo stack (A7) salva comunque una word (16 bit), mentre con gli altri registri indirizzo viene preservata la giusta dimensione.

Ok, tu vuoi fare in modo che sia il uP a decidere come disporre lo stack in modo da adattarsi ai suoi bisogni e velocizzare l'operazione.

Originariamente inviato da cdimauro

Sì, come soluzione quella del registro di link non mi piace molto, perché puoi salvare un solo indirizzo di ritorno alla volta: dopo ti costringe a eseguire comunque un push sullo stack, e poi un restore.

Se consideri che molti processori moderni hanno una sezione di call-stack, capisci bene che il caso comune non è certo quello di un insieme di funzioni flat che poi non richiamano nessuno. Per questo ho preferito usare il classico stack per l'indirizzo di ritorno.

Si potrebbe unire l'utilità del link e dello stack in questo modo: la call mette l'indirizzo nello stack e nel link, se poi la funzione non richiama altre cose, può ritornare mediante un'istruzione che semplicemente usa il link per ripristinare il pc, e decrementa lo sp di tot (in modo da simulare il pop).

Originariamente inviato da cdimauro

Ma quella del registro link è un'idea che potrebbe essere presa in considerazione. D'altra parte ho pure aggiunto un registro per il Frame Pointer (FP) e apposite istruzioni (LINK, UNLINK, PUSH FP, POP FP, MOVE FP,An, MOVE An,FP) per poterlo gestire, per cui si potrebbe fare la stessa cosa (anche se ormai nella tabella degli opcode a 16 bit sono rimasti una decina di posti ).

E se invece di aggiungere registri specifici, e istruzioni adatte per gestirli, si potrebbe riservare un altro bit per selezionare il registro indirizzi, in modo da espanderli a 16, e usare i trucchi "risc-eschi" per risparmiare sulle altre istruzioni (e usare pseudo-istruzioni). Ad esempio, A15 è PC, A14 è SP, la call sarà un'istruzione discreta, ma push, pop, carica immediato, ret, salto incondizionato possono essere tranquillamente semplificate in
mov r, [++SP]
mov [SP--],r
mov r, [PC++]
mov PC, [SP--]
mov PC, [PC++]
Si semplificherebbe il tutto, mantenendo ortogonalità e lasciando al programmatore possibilità di abbinare le istruzioni per far venire fuori qualche altro "trucchetto".

Originariamente inviato da cdimauro

Sì, perché ti permette di realizzare delle ALU ottimizzate.

Ad esempio per aggiornare un registro indirizzi basta che l'ALU dedicata implementi le operazioni di somma, differenza, confronto, e hai finito. In questo modo l'ALU che si occupa di effettuare il calcolo dell'indirizzo si può usare indifferentemente per la sezione AGU e per l'aggiornamento di un registro indirizzi.

Possiamo cmq usare 2 alu per operare sugli stessi registri: se ad esempio abbiamo una istruzione tipo

add R1, [R2+R3]

R2 e R3 verranno prelevati dall'AGU, e il valore prelevato andrà sommato con R1 nell'alu normale; oppure

add R1, [R2++]

R2 viene prelevato dall'AGU, che manda il suo valore in uscita e salva pure il valore aggiornato, e R1 viene prelevato dall'ALU.

Originariamente inviato da cdimauro

Una LUT è, però, estremamente veloce (e considerata la dimensione della tabelle, è pure economica) e semplicissima da realizzare.

Anche col codificatore a priorità non c'è troppa circuiteria: il segnale al massimo deve passare 3 porte logiche prima di passare in uscita, mi bastano qualche AND e OR a molteplici ingressi, e tante NOT. Se invece vogliamo la versione economica ma più lenta, servono molte meno NOT ma qualche AND in più.

Originariamente inviato da cdimauro

Nessuno t'impedisce di realizzare un processore con ISA AMD64-only. Anzi, personalmente è quel che farei se fossi nei panni di AMD o Intel.

Comunque ad AMD rimprovero un'altra cosa: AMD64 non è compatibile a livello binario con x86, per cui sei costretto a ricompilare i sorgenti e ad adattarli (poco, per fortuna). Tanto valeva sistemare l'ISA a 64 bit razionalizzando la tabella degli opcode (tanto per cambiare, avrei utilizzato una opcode table a 16 bit ).

Beh, sono solo state tolte qualche istruzioni veramente arcaiche per riassegnarle ad un altro scopo, ma è ancora compatibile (di default le istruzioni lavorano su 32bit, per usare le 64 bisogna anteporre il prefisso REX).
Cmq concordo che ridisegnare la tabella di opcode sarebbe stato decisamente meglio.


Ultima cosa: come pensi di far riconoscere al processore istruzioni a 16 o a 32 bit? Queste ultime sono solo normali 32 bit ma con un prefisso, o usi un bit dell'istruzione per dire "questa è a 32, carica anche l'altra word" ?