Oggetto: Re: possibile errore paragr 4.13 Mittente: Giuseppe Scollo Data: Thu, 14 Apr 2011 16:48:44 +0200 [...] > studiando il paragr. 4.13 mi è venuto un dubbio: high bit > esegue la funzione booleana > > F=(jamz and z) or (Jamn and n) or nextaddress[8] > > nel diagramma a blocchi che rappresenta mic-1, non dovrebbe esserci il > collegamento tra il bit più significativo di address(contenuto in mir) e high > bit, così come sono collegati ad high bit il campo jam di mir e i flipflop > n e z? No, sarebbe superfluo, e forse erroneo. Come specificato due paragrafi sopra quello che lei cita: "Inizialmente i 9 bit del campo NEXT_ADDRESS vengono copiati all'interno di MPC." La funzione booleana in questione è dunque un OR ternario, di cui il componente "Bit alto" calcola l'OR delle prime due clausole, mentre il valore della terza clausola (nextaddress[8]) è già a destinazione: se vale 1, tale resta la destinazione; se vale 0, la destinazione assume il valore risultante dall'OR delle prime due clausole. C'è però un problema di interpretazione della figura alla luce del testo, incluso quello che viene dopo la figura successiva: il fatto che se il bit alto del campo NEXT_ADDRESS vale 1 tale resta in MPC è spiegato a p. 236, penultimo paragrafo, dove si asserisce: "Il quadratino etichettato con ``O'' (...) lascia semplicemente passare NEXT_ADDRESS in MPC quando JMPC vale 0". L'output del componente "O" è dunque su tutto MPC (9 bit), mentre la graffa orizzontale nella figura può dare l'impressione che l'output sia solo sugli 8 bit meno significativi di MPC. D'altra parte, se così fosse, non si capirebbe perché il componente "O" dovrebbe avere 9 bit in input, e in particolare il bit alto del MIR, di cui non avrebbe che farsi. In conclusione, credo che si tratti solo di un problema di lettura della figura in momenti diversi, alla luce della descrizione nel testo. Nella pagina precedente si specifica che, durante la copia iniziale dei 9 bit in MPC "viene ispezionato il campo JAM; se il suo valore è 000, allora non viene eseguita alcuna azione aggiuntiva". Ora, quando N e Z non sono entrambi nulli, l'output di "Bit alto" è 0 solo se JAM vale 000 oppure 100. Nel primo caso non succede altro, come detto, mentre nel secondo caso il componente "O" esegue l'OR con MBR, dunque effettivamente produce un output di 8 bit (il che può spiegare la "graffa corta" in figura), mentre il bit alto resta, anche in questo caso, quale era stato già copiato in MPC (attraverso "O", con output a 9 bit). La figura va bene come diagramma a blocchi (meno dettagliato di quanto non debba esserlo un circuito logico) se si assume l'ipotesi che JAMN e JAMZ siano entrambi nulli quando il bit alto del MIR vale 1. Questa ipotesi è di fatto un vincolo sulla validità di microistruzioni, ed è esplicitata nel testo subito dopo la Fig. 4.7. Infatti, cosa potrebbe succedere altrimenti? Che il bit alto di MPC sia inizialmente 1 (copiato da MIR), ma successivamente azzerato dall'output di "Bit alto" (abilitato dal fatto JAMN e JAMZ non sono entrambi nulli, ma nullo per via del valore di N e/o Z). Se le microistruzioni, invece, rispettano il vincolo suddetto, allora quando il bit alto di MIR vale 1 accade che: 1) né N né Z influiscono sul bit alto di MPC, copiato in prima battuta dal bit alto di MIR attraverso "O", e 2) tale bit non è successivamente modificato dal componente "O", nemmeno quando JMPC=1, perché in seconda battuta "O" ha un output di 8 bit (OR con MBR). Spero che l'interpretazione della figura sia più chiara adesso. ______________________________________________________________________________ Oggetto: Re: R: Re: possibile errore paragr 4.13 Mittente: Giuseppe Scollo Data: Fri, 15 Apr 2011 01:56:36 +0200 [...] >> La sua risposta è esaustiva.. Grazie mille la invito a pubblicare sul Forum il testo della sua comunicazione precedente. Penso che il chiarimento sia utile anche ai suoi colleghi, e inoltre è evidente che il testo non è chiarissimo su questo aspetto, altrimenti non dovrebbero essere necessarie ulteriori spiegazioni e interpretazioni. Sebbene ritenga che il testo non vada modificato, il dubbio da lei sollevato è di natura tecnica e perfettamente legittimo, dunque le riconoscerò l'accredito del bonus. Che il testo sia fonte del dubbio è peraltro confermato dall'interpretazione che ne ha dato, in una precedente edizione del corso, lo studente Sergio Nativo, autore di un'animazione Flash della figura 4.6: http://www.dmi.unict.it/~barba/Architetture.html/SIMULATORS/Hw-Mic-1/Mic-1.animazione.htm Da un canto, nell'immagine complessiva, lo studente indica 8 input dal campo Addr del MIR, invece che 9, per il componente "O". Che questa non sia una svista tipografica è corroborato dall'ingrandimento di tale componente. D'altra parte, sebbene il componente "High bit" sia da lui rappresentato come nella figura del testo, nell'immagine complessiva, dunque senza input del bit alto del MIR, l'ingrandimento di tale componente indica l'OR con tale bit, secondo l'interpretazione che lei ha proposto, che equivale ad ipotizzare un'implementazione con rete combinatoria della funzione booleana che produce il bit alto di MPC. E` evidente che il testo dà adito a dubbi di interpretazione. ______________________________________________________________________________ ______________________________________________________________________________ Oggetto: Re: emuMIC 1.2: risoluzione 800x600? Mittente: Dario Spitaleri Data: Mon, 18 Apr 2011 17:21:42 +0200 On 16/04/11 13:12, Giuseppe Scollo wrote: [...] > Ieri invece è emerso un piccolo problema con la Fig. 4.6 del testo, > che è poi l'immagine principale del simulatore. Nella Fig. 4.6 la linea > che collega il campo Addr del MIR al componente "O" ha molteplicità 9, > mentre nella vostra immagine, come pure nell'animazione Flash del > vostro collega Sergio Nativo, la molteplicità indicata è 8. A quanto mi ricordi di architettura (la prego di prendere con le pinze quello che sto per dire, mi scuso per eventuali baggianate): Il componente "O" calcola gli 8 bit a destra dell'indirizzo della prossima istruzione, mentre il bit più a sinistra dipende solo dai bit JAMZ e JAMN ed i bit N e Z dell'alu, quindi dovrebbe essere corretto il numero 8. In altre parole, il primo bit a sinistra di MPC non dipende dal componente "O", ma dalla verifica o no delle condizioni del salto condizionato (componente HighBit). Il problema da Lei sollevato della molteplicità, a quanto mi ricordi, era dato da un errore di stampa in versioni meno recenti del libro (poi corretto nelle versioni più recenti (o viceversa). > D'altra parte, sia nel testo che nelle due immagini in questione, non è > indicato alcun collegamento fra il (bit più alto del) campo Addr > e il componente "High bit", ma se quest'ultimo deve implementare la > funzione booleana specificata nel testo, allora ha bisogno di > quell'input. Se è così (ovvero: se la suddetta funzione booleana > è implementata da una rete combinatoria), allora gli 8 bit in input > da Addr al componente "O" bastano e avanzano, altrimenti deve > averne 9 per permettere di caricare inizialmente il bit alto di MPC > con Addr[8] (come indicato dal testo). In tal caso però "O" deve, > almeno inizialmente, avere anche un output di 9 bit su MPC, non solo > di 8 bit come suggerito dalla graffa orizzontale. Inoltre, in questa > seconda ipotesi, il componente "High bit" dovrebbe essere disabilitato > quando Addr[8]=1, altrimenti un suo output 0 modificherebbe il bit alto > di MPC, contrariamente a quanto asserito nel testo. Suppongo che questo > secondo tipo di implementazione dovrebbe usare un tri-state a tal fine. > Voi avete considerato questo problema? Grazie in anticipo. Questo non mi suona nuovo, ed infatti mi chiedo: che senso ha, nel calcolo del bit più significativo di MPC, il bit più significativo di NEXTADDR se questo dipende solo dalla verifica delle condizioni di salto o meno? Inoltre, non dovrebbe esistere alcuna microistruzione dentro il controlStore con NEXTADDRES che abbia il primo (da sinistra) bit posto a 1 e dunque ADDR[8] dovrebbe sempre essere 0. [...] _____________________________________________________________________________ Oggetto: Re: emuMIC 1.2: risoluzione 800x600? Mittente: Giuseppe Scollo Data: Mon, 18 Apr 2011 19:05:04 +0200 A: Dario Spitaleri [...] > Il componente "O" calcola gli 8 bit a destra dell'indirizzo della > prossima istruzione, mentre il bit più a sinistra dipende solo dai bit > JAMZ e JAMN ed i bit N e Z dell'alu, quindi dovrebbe essere corretto il > numero 8. > In altre parole, il primo bit a sinistra di MPC non dipende dal > componente "O", ma dalla verifica o no delle condizioni del salto > condizionato (componente HighBit). > Il problema da Lei sollevato della molteplicità, a quanto mi ricordi, > era dato da un errore di stampa in versioni meno recenti del libro (poi > corretto nelle versioni più recenti (o viceversa). Credo che valga il viceversa (ho la 5a edizione, sia dell'originale in inglese che della versione italiana, c'è "9" in entrambi). Penso che il 9 sia corretto, perché non è vero che il bit alto di MPC debba dipendere sempre solo dalle condizioni di salto condizionato, JAMN or JAMZ. Infatti, nella IJVM c'è l'istruzione prefisso "WIDE", e non a caso il suo codice Mic-1 prevede (nella seconda istruzione) il salto goto (MBR OR 0x100) che imposta a 1 il bit alto di MPC incondizionatamente, perché tutte le versioni "wide_" del codice Mic-1 per istruzioni IJVM a cui può applicarsi l'istruzione prefisso iniziano nella parte alta della memoria di controllo. > Questo non mi suona nuovo, ed infatti mi chiedo: che senso ha, nel > calcolo del bit più significativo di MPC, il bit più significativo di > NEXTADDR se questo dipende solo dalla verifica delle condizioni di salto > o meno? Come detto sopra, ci sono casi in cui il bit più significativo di MPC non dipende da N OR Z. Tuttavia: > Inoltre, non dovrebbe esistere alcuna microistruzione dentro il > controlStore con NEXTADDRES che abbia il primo (da sinistra) bit posto a > 1 e dunque ADDR[8] dovrebbe sempre essere 0. Questo potrebbe essere vero (nei casi suddetti, il bit alto di MPC non è determinato da ADDR[8] ma da JMPC), però il vincolo che lei indica potrebbe creare qualche problema di implementazione di estensioni della IJVM. Infatti, posto che il codice Mic-1 per una istruzione IJVM estesa (da WIDE) ha la prima microistruzione nella parte alta della memoria di controllo, quel vincolo imporrebbe di collocare nella parte bassa della memoria le microistruzioni successive alla prima. Ciò si può fare con la traduzione della IJVM di Fig. 4.17, perché si tratta di 212 microistruzioni in tutto, ma se si considerano sue eventuali estensioni, allora il vincolo potrebbe risultare stretto (a p. 260 il testo indica che la versione completa di JVM ha anche una versione wide di IINC: non sappiamo quante altre estensioni abbia). Mi pare che la soluzione che permette ADDR[8]=1 sia preferibile, ma questa richiede appunto 9 linee in input a "O".