Corsi di Laurea

[Ale89]

Eh si infatti!!!

[Ale89]

Sto provando a fare BLTZAL per caso l'hai gia vista???

[eferre]

Sto provando a fare BLTZAL per caso l'hai gia vista???

No, non l'ho vista; BLTZAL sta per "branch less than zero..." ... AL sta per...

[Ale89]

Sto provando a fare BLTZAL per caso l'hai gia vista???

No, non l'ho vista; BLTZAL sta per "branch less than zero..." ... AL sta per...

and link... Praticamente fa se il contenuto del registro è minore di zero salta a label e metti in ra il contenuto di pc+4... E' di tipo I... Sono arrivato fin qui

[eferre]

and link... Praticamente fa se il contenuto del registro è minore di zero salta a label e metti in ra il contenuto di pc+4... E' di tipo I... Sono arrivato fin qui

Ho capito... è una sorta di combinazione delle istruzioni jal e blt... se hai fatto jal non dovrebbe esserti troppo difficile, in ogni caso posso proporti una soluzione nel pomeriggio... se nel frattempo nessun altro ti avrà risposto...

[Ale89]

X il calcolo della condizione di salto e per il nuovo indirizzo del PC la soluzione è la stessa della BLTZ... Ora mi manca da collegare il PC vecchio + 4 nel registro RA....
Ma nella JAL c'è un collegamento fisico tra l'alu e il registro RA??? Ovvero nel passo in cui l'alu fa pc+4 vado a asserire tipo un segnale che dice di poter scrivere in ra???

[eferre]

Si, in pratica nella jal ho aggiunto un' entrata al mux controllato da MemToReg e tale entrata sarebbe il PC (essendo il dato che deve essere scritto in memoria)... poi ho aggiunto un segnale RAWrite, essendo che non poteva essere passato l'indirizzo di ra nel modo canonico...

Ovviamente il tutto si conclude con un ultimo passo in cui
PcWrite=1, PCSource=10

[Ale89]

Ok ok più o meno quello che avevo in mente anche io!

[Ale89]

Enrì stavo facendo la macchina a stati finiti della MFLO e della MFHI...

Si tratta di 2 istruzioni di tipo R giusto? Dunque l'unità di controllo non sa da se di che operazione si tratta dunque non può nemmeno passare i registri LO e HI all'Alu...

Ho un'idea bizzarra... non è che questi 2 registrisi trovano nell'Alu ??? Altrimenti come facciamo ?

[eferre]

Enrì stavo facendo la macchina a stati finiti della MFLO e della MFHI...

Si tratta di 2 istruzioni di tipo R giusto? Dunque l'unità di controllo non sa da se di che operazione si tratta dunque non può nemmeno passare i registri LO e HI all'Alu...

Ho un'idea bizzarra... non è che questi 2 registrisi trovano nell'Alu ??? Altrimenti come facciamo ?

Nella traccia proposta dal professore è specificato che LO ed HI sono registri del register-file, l'unico problema è che non sono accessibili tramite i 5 bit che identificano uno dei 32 registri (perchè non rientrano tra i 32 registri!)... quindi l'unica soluzione sta nell'assegnare alla CU dell'ALU dei segnali che abilitano la scrittura (o la lettura) di tali registri quando viene riconosciuto un determinato compo "funct".

Nel caso di "move from", che è quello da te proposto, si tratta di avere un "segnale sulla lettura", se vedi la mia soluzione nei post precedenti capisci come ho ragionato... e le cose sembrano funzionare...

[f.savarese]

Raga scusate ma io nell''istruzione BGTZ non vi ho seguiti molto....
A parte che non capisco quel 500 per il prof cosa stia ad indicare....Non ho capito se serva ai fini dell'istruzione,forse sta li solo per farci vedere che negli ultimi 16 bit c' un immediato....
Ma cmq, io avrei dato qst soluzione:

AluSRCA = 1
ALUsrcB = 00
ALUop = 01
PCWiriteCondMag = 1
PCSource = 3

Dove è un segnale collecato in AND con un segnale che esce dall'ALU nel caso in cui il risultato della sottrazione fra reg A e reg B(il quale reg sarà a zero) sia maggiore di 0.Il segnale in uscita dalla AND è collegato in OR al segnale in PCWRITE(che di norma non è asserito)...
AGGIUNGO ke PCSource = 3 indica un quarto valore del MUX che è il LABEL indicato dall'istruzione cosicchè si scelga di scrivere nel PC l'indirizzo voluto...


Cmq aggiungo che non so se ho ben capito cosa deve fare qst istruzione, nel senso che non so se devo saltare al label 500 o all'indirizzo fisso 000111 00000 00000 125
Spero di essere stato chiaro.....

[eferre]

Volevo solo farti notare che l'indirizzo al quale saltare è stato già calcolato nella fase di decode e si trova nell'ALUOut, dunque sarà sufficiente dare al MUX 01... in pratica non serve un'altra entrata... per il resto mi trovo con te.

Quella stringa di bit seguita da 125, come viene detto nella traccia, è la codifica dell'istruzione, in ogni caso credo che ci sia un errore nella traccia perchè se fosse davvero codificata così, come dicevo in un altro post, non si potrebbe fare riferimento al registro s0, e dunque tale istruzione funzionerebbe per un solo registro... cosa che reputo del tutto assurda!

[f.savarese]

Si si ok, l'altro ingresso al mux era dovuto ad un'interpretazione sbagliata dell'istruzione(avevo ipotizzato che fosse un Label fisso)questo era l'errore in cui ero incappato....tnx

[f.savarese]

Raga sono un po' in ritardo, però direi, per quanto riguarda la mflo:
Il campo funct risulta essere identificativo per la funzione(come già detto),per cui una volta fatta la decode il controllo passa all'unità di controllo ALU,Tale unità deve abiitare un segnale ,da essa uscente, che chiameremo (dollaro)LoRead tale segnale abilita la lettura di (dollaro)LO che finisce direttamente in gola all'ALU senza la necessità di un registro aggiuntivo c, come proposto su...La ALU anche se poi in realtà nn ci interessa potrebbbe fare una somma a tre operandi 0 più 0 più (dollaro)lo o anke a due o anke non sommare per nulla(è inutile ai fini dell'ex entrare in qst dettagli che non ci riguardano).Il riultato della computazione dell'ALU cosìsarà posto in ALUout...In tal modo,passando il controllo al Controllo Alu, la macchina a stati finiti non va affatto modificata e non ci dobbiamo preoccupare delle altre istr di tipo-R...Aspetto vostre conferme...a me sembra che fili liscio.....

[f.savarese]

Raga io non capisco cosa sta succedendo e perkè il mio post esce così, se mi aiutate please poso dire anke io la mia sulla MFLO
TNX

[eferre]

Raga io non capisco cosa sta succedendo e perkè il mio post esce così, se mi aiutate please poso dire anke io la mia sulla MFLO
TNX

Non devi utilizzare i dollari, altrimenti parte lo script matematico! Non postare di nuovo, modifica il post precedente con "edit" in basso a destra del post.

[Edd]

Quindi, riassumendo:

La bgtz è una istruzione di salto condizionato di formato I, in cui a variare è il codice operativo. Da ciò si deduce che bisogna modificare i segnali della CU. Non si è ben capito però se dobbiamo ragionare su s0 in particolare o se il Prof. voleva intendere un registro a caso per fare un esempio. Beh, penso che se volesse intendere che l'istruzione agisce su s0 in particolare bisogna aggiungere un segnale alla CU che invia alla alu proprio s0, altrimenti no prob.
Poi, se ho capito bene, la alu può selezionare direttamente la msb, giusto? Se è così, credo ci sia solo bisogno di un'altra porta and in cui vanno pcwritecond ( già asserito dal codop ) e msb ( che sarà naturalmente 0 se è positivo, 1 se è negativo ), il segnale passa per la or con pcwrite e arriva al pc.

Le modifiche del datapath sono il segnale msb dalla alu e ( a seconda di quello che intendeva il prof ) un nuovo segnale della CU esclusivamente per selezionare s0. Per la macchina a stati finiti invece non c'è niente da modificare, perchè segue i passi di una tipica istruzione branch.

La mflo invece è un'istruzione di tipo R, si limita a spostare lo in un altro registro. Siccome l'unica cosa che varia nella stringa rispetto ad una comune istruzione R è il campo funct abbiamo supposto che sia la alu a regolare tutto. In particolare ricevendo quella stringa dal campo funct il controllo alu indica alla alu di prendere direttamente lo ( ma a quanto pare nessuno sa da dove ) e quindi somma o non somma, il contenuto di lo finsice in aluOut.

Le modifiche del datapath sono l'inserimento di un nuovo segnale per la alu che invia appositamente lo. Nella macchina a stati finiti non si dovrà modificare niente perchè si comporta come un'istruzione R.


Quante ca**ate ho detto?

[eferre]

Non si è ben capito però se dobbiamo ragionare su s0 in particolare o se il Prof. voleva intendere un registro a caso per fare un esempio. Beh, penso che se volesse intendere che l'istruzione agisce su s0 in particolare bisogna aggiungere un segnale alla CU che invia alla alu proprio s0, altrimenti no prob.

Non mi esprimo su questa cosa perchè già ho ripetuto un paio di volte come la penso!

Per la macchina a stati finiti invece non c'è niente da modificare, perchè segue i passi di una tipica istruzione branch.

Non puoi usare lo stesso segnale PcWriteCond sia per la bgtz ché per gli altri salti condizionati, altrimenti in un qualsiasi salto condizionato salti ogni volta che l'ALU fa una sottrazione che ti fa uscire MSB=1 (e questo non deve accadere)... se non mi sbaglio anche questo l'ho detto in un altro post...
In ogni caso la CU deve essere modificata per inserire un nuovo segnale di salto specifico per la bgtz.

In particolare ricevendo quella stringa dal campo funct il controllo alu indica alla alu di prendere direttamente lo ( ma a quanto pare nessuno sa da dove ) e quindi somma o non somma, il contenuto di lo finsice in aluOut.

Veramente nella mia soluzione non è l'ALU a vedere LO, ma essa vede un registro C nel quale è stato inserito il contenuto di LO (il contenuto di LO viene inserito in questo registro C indipendentemente da se si tratti di una mflo, è l'ALU che legge tale registro solo se è una mflo!)

Le modifiche del datapath sono l'inserimento di un nuovo segnale per la alu che invia appositamente lo. Nella macchina a stati finiti non si dovrà modificare niente perchè si comporta come un'istruzione R.

Non c'è bisogno di aggiungere segnali perchè l'ALU viene indirizzata alla lettura del registro C direttamente dal campo funct, che ricordo essere identificativo esclusivamente di tale istruzione! Quindi l'unica modifica è l'aggiunta del registro C...

Quante ca**ate ho detto?

Tante! ovviamente scherzo!

[eferre]

Raga sono un po' in ritardo, però direi, per quanto riguarda la mflo:
Il campo funct risulta essere identificativo per la funzione(come già detto),per cui una volta fatta la decode il controllo passa all'unità di controllo ALU,Tale unità deve abiitare un segnale ,da essa uscente, che chiameremo (dollaro)LoRead tale segnale abilita la lettura di (dollaro)LO che finisce direttamente in gola all'ALU senza la necessità di un registro aggiuntivo c, come proposto su...La ALU anche se poi in realtà nn ci interessa potrebbbe fare una somma a tre operandi 0 più 0 più (dollaro)lo o anke a due o anke non sommare per nulla(è inutile ai fini dell'ex entrare in qst dettagli che non ci riguardano).Il riultato della computazione dell'ALU cosìsarà posto in ALUout...In tal modo,passando il controllo al Controllo Alu, la macchina a stati finiti non va affatto modificata e non ci dobbiamo preoccupare delle altre istr di tipo-R...Aspetto vostre conferme...a me sembra che fili liscio.....

Lo so che ne abbiamo parlato in privato, però preferisco scriverlo anche qui per i posteri... la soluzione proposta da ciccio non è male, ma una cosa va specificata: affinché l'ALU possa leggere un operando esso deve trovarsi in un registro.. da qui la necessità dell'inserimento del registro C... in altre parole un valore che proviene dal register-file non può "andare direttamente in gola all'ALU", il motivo lo trovate sul libro leggendo le premesse fondamentali per l'implementazione multiciclo.

Se deve essere aggiunto un nuovo registro nel quale va messo solo il valore di LO non vedo perchè serva un segnale che dica al register-file di mettercelo! A questo punto glielo facciamo mettere ogni volta, risparimando anche un ciclo di clock, sarà l'ALU a leggerlo solo se si tratta di una mflo!

Un'alternativa a questa strada, e che in un certo senso si ricollega alla soluzione proposta dal buon savarese, sarebbe quella di inviare un segnale al register-file che dica di inserire in A LO e in B zero (o viceversa), in modo che poi l'esecuzione dell'istruzione proceda come una qualsiasi istruzione R... ovviamente in tal caso non serve l'aggiunta di un terzo registro.

Tirando le somme direi che questa soluzione è ancora migliore perchè non prevede l'aggiunta di un registro, e bravo Ciccio!

[f.savarese]

Hai fatto benissimo, mi ero collegato con questo scopo...Cmq l'ultima sol ke hai dato mi sembra di difficile implementazione in quanto noi carichiamo A e B durante la fase di decode...alla fase successiva selezioniamo solo da quali sorgenti deve avvenire la lettura da parte dell'Alu....pertanto mi sembra difficile poterla implementare....sennò andremmo ad incappare nello stesso trabocchetto in cui sono caduto io...

Quello che poco mi convinceva della tua prima soluzione è che per ogni istruzione dovremmo caricare in C e poi nell'ALU il registro L0..Certo poi l'Alu sa cosa deve fare....Ma mi sembra un po' una forzatura...Ad ora però non riesco a trovare un' altra soluzione...

Avrei poi pensato alla soluzione di cui mi parlavi sul MUX(non te ne voglio togliere il metodo ed aspetterò che la posti tu ) Probabilmente le obiezioni che ti facevo io (Sulla poco generalità della soluzione, che fra l'altro compare anche nelle altre sol. postate) Aggiungendo il bit non sul MUX legato al reg.A ma su quello Legato al reg.B...in questo modo col secondo mux possiamo sel 8 uscite differenti, mentre con la stessa aggiunta sull'altro MUX fino a 4....
è vero che aumenterebbe la banda passante, ma credo sia l'equivalente di aggiungere lo stesso bit dall'altra parte...ma cmq non mi lacerei in discorsi che cmq non ci competono ancora.....
Fatemi pensa come la pensate....