Pages: 1 ... 19 20 [21] 22 23 24   Go Down
Print
Author Topic: AA 2010-2011: Quesiti a risposta aperta  (Read 89492 times)
0 Members e 1 Utente non registrato stanno visualizzando questa discussione.
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #300 on: 25-05-2012, 20:19:19 »

Le due frasi seguenti, riprodotte dai due paragrafi del testo citati, appaiono in contraddizione. Lo sono? Se sì, quale delle due è corretta? Se no, perché (max 5 righe)?
    * 4.4.2, ultimo paragrafo in "Unione del ciclo d'interpretazione con il microcodice":
      "Il prezzo da pagare è solamente un piccolo incremento della memoria
      di controllo."
    * 4.4.4, primo paragrafo:
      "il costo della IFU è senza dubbio maggiore del guadagno ottenuto
      riducendo la memoria di controllo."



Si sono in contraddizone ed è giusta quella del paragrafo 4.4.2 perchè  il prezzo da pagare è solamente un piccolo incremento della memoria di controllo.


Non riesco a trovare la contraddizione, per me sembrano corrette entrambe.

Unire il ciclo di interpretazione con il microcodice, vuol dire eliminare l'operazione Main1 e replicare l'istruzione contenuta in esso in ogni altra operazione.
Se si trova un ciclo morto in queste operazioni, cioè un'istruzione vuota (nope) , non si causa nessun incremento nella memoria di controllo, mentre se cosi non fosse bisogna aggiungere una nuova istruzione e quindi come dice il testo: "Il prezzo da pagare è solamente un piccolo incremento della memoria di controllo".

E' vera anche la seconda: per realizzare una IFU ci sono dei costi aggiuntivi e in più la dimensione del chip aumenta (come dice il testo, più è grande un chip, più è costoso).
Inoltre la IFU serve ad effettuare il fetching. Mediante un registro a scorrimento tiene sempre aggiornato i valori di MBR1/U e MBR2/U in modo da essere sempre pronti qualora il microcodice lo richiedesse. Grazie a ciò si riduce la dimensione della memoria di controllo (nel microcodice le istruzioni di fetch vengono omesse).
Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #301 on: 28-05-2012, 12:51:57 »

due domande non mi sono chiare...

Domanda 1)

Sarebbe possibile usare una IFU più economica in Mic-2, con registro di scorrimento da 5 byte invece che 6?
Ed una con registro di scorrimento da 4 byte? Motivare le risposte
È ovvio che il costo della IFU decresce al decrescere della capacità del registro di scorrimento. La struttura della IFU è schematizzata in Figura 4.27, dove il pre-prelievo nel registro di scorrimento avviene mediante lettura di una parola dalla memoria, ovvero 4 byte alla volta, com'è peraltro evidente dalle relative transizioni dell'automa in Figura 4.28. Perché una lettura da memoria possa aver luogo occorre dunque che almeno 4 byte siano liberi nel registro di scorrimento. Naturalmente, maggiore è la capacità di quest'ultimo, minore è la probabilità che una cache miss provochi uno stallo nel tentativo di lettura dal registro di scorrimento verso il percorso dati (registro MBR). A lei il resto del ragionamento...

Quote
Domanda 2)

Se oltre il 90% dei file occupano al più 8KB ca. mentre gli altri usano oltre il 90% dello spazio disco occupato, che si può dire della dimensione ottimale dei blocchi del disco? Formulare la risposta
Le operazioni di I/O sul disco trasferiscono un blocco alla volta, e per ognuna di queste il tempo di esecuzione ha varie componenti: posizionamento, latenza, trasferimento del blocco. L'ottimalità della dimensione dei blocchi va valutata rispetto a due fattori: tempo di esecuzione dell'I/O (a parità di quantità di dati trasferiti) e spazio effettivamente utilizzato in rapporto allo spazio occupato (che è sempre un multiplo della dimensione del blocco). Credo che ora abbia tutti gli elementi per ragionare sul quesito proposto.
Logged
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #302 on: 28-05-2012, 16:49:12 »

Le due frasi seguenti, riprodotte dai due paragrafi del testo citati, appaiono in contraddizione. Lo sono? Se sì, quale delle due è corretta? Se no, perché (max 5 righe)?
    * 4.4.2, ultimo paragrafo in "Unione del ciclo d'interpretazione con il microcodice":
      "Il prezzo da pagare è solamente un piccolo incremento della memoria
      di controllo."
    * 4.4.4, primo paragrafo:
      "il costo della IFU è senza dubbio maggiore del guadagno ottenuto
      riducendo la memoria di controllo."



Si sono in contraddizone ed è giusta quella del paragrafo 4.4.2 perchè  il prezzo da pagare è solamente un piccolo incremento della memoria di controllo.


Non riesco a trovare la contraddizione, per me sembrano corrette entrambe.

Unire il ciclo di interpretazione con il microcodice, vuol dire eliminare l'operazione Main1 e replicare l'istruzione contenuta in esso in ogni altra operazione.
Se si trova un ciclo morto in queste operazioni, cioè un'istruzione vuota (nope) , non si causa nessun incremento nella memoria di controllo, mentre se cosi non fosse bisogna aggiungere una nuova istruzione e quindi come dice il testo: "Il prezzo da pagare è solamente un piccolo incremento della memoria di controllo".

E' vera anche la seconda: per realizzare una IFU ci sono dei costi aggiuntivi e in più la dimensione del chip aumenta (come dice il testo, più è grande un chip, più è costoso).
Inoltre la IFU serve ad effettuare il fetching. Mediante un registro a scorrimento tiene sempre aggiornato i valori di MBR1/U e MBR2/U in modo da essere sempre pronti qualora il microcodice lo richiedesse. Grazie a ciò si riduce la dimensione della memoria di controllo (nel microcodice le istruzioni di fetch vengono omesse).
Ha perfettamente ragione, è stata una mia svista credere che la prima asserzione (quella del par. 4.4.2) fosse erronea: circoscritta al contesto in cui è posta, è un'asserzione valida. Ho aggiornato la lista delle correzioni di conseguenza. Naturalmente, questa segnalazione le vale un punto di bonus, se non ha ancora registrato l'esame (in tal caso può comunicarmi il suo n. di matricola per e-mail o PM).
Logged
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #303 on: 31-05-2012, 11:14:04 »

Secondo me non ha significato avere un numero di vie che sia potenza di due in quanto le attuali macchine fanno uso di cache a 3 vie per motivi di efficienza
Mi sembra un giudizio eccessivo, cache a 2 o 4 vie hanno tanto senso quanto cache a 3 o 5 vie, in linea di principio. Dunque, mentre non c'è ragione di preferire le potenze di 2, non ce n'è nemmeno per escluderle a priori.

Di solito si sfruttano le potenze di 2 per non sprecare bit in eventuali indirizzamenti.
Secondo me non c'è nessun vantaggio usare k vie con k potenza di 2, poichè l'indirizzo di memoria, generato da una CPU, non contiene bit che specificano una particolare linea su un elemento di cache set-associative.
In poche parole, il campo LINE indica l'elemento della cache contenente i dati (in questo caso l'elemento è un insieme di k linee), ed una volta trovato, verrà fatta un ricerca sequenziale controllando per ogni linea dell'insieme il bit VALID e il campo TAG.
Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #304 on: 12-06-2012, 10:16:31 »

lezione 17 - Quesito 22 : Definire una macro con 3 parametri A, N, M, risp. da attualizzarsi con nomi di un array, di una costante e di una locazione di memoria, che calcoli in M la media degli N elementi di A (max 15 righe).

MACRO ARRAY_MEDIA A,N,M
   MOV INIZIO, #A            ; inizio = indirizzo dell'array A
   MOV FINE, #A+N            ; fine = ind. dell'array A + N (numero totale di elementi, se ogni elemento = 1 byte)
   MOV CONTA, #0             ; contatore per le somme successive nel ciclo

 CICLO: ADD CONTA,(INIZIO)    ; visto che inizio è un registro che contiene un indirizzo, si usa ind. a reg indiretto
                                                  ;  per estrarre il valore ed effettuare la somma
        ADD INIZIO,#1             ; incremento di inizio di 1 byte
        CMP INIZIO,FINE           ; confronto fra inizio e fine
        BLT CICLO                 ; se inizio < fine, si ritorna all'etichetta ciclo

   DIV CONTA,N               ; conta = conta / n
   MOV M,CONTA               ; assegna ad m il valore della media
ENDM

L'operazione di divisione deve essere anch'essa definita come macro?
Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #305 on: 12-06-2012, 12:26:08 »

lezione 17 - Quesito 22 : Definire una macro con 3 parametri A, N, M, risp. da attualizzarsi con nomi di un array, di una costante e di una locazione di memoria, che calcoli in M la media degli N elementi di A (max 15 righe).

MACRO ARRAY_MEDIA A,N,M
   MOV INIZIO, #A            ; inizio = indirizzo dell'array A
   MOV FINE, #A+N            ; fine = ind. dell'array A + N (numero totale di elementi, se ogni elemento = 1 byte)
   MOV CONTA, #0             ; contatore per le somme successive nel ciclo

 CICLO: ADD CONTA,(INIZIO)    ; visto che inizio è un registro che contiene un indirizzo, si usa ind. a reg indiretto
                                                  ;  per estrarre il valore ed effettuare la somma
        ADD INIZIO,#1             ; incremento di inizio di 1 byte
        CMP INIZIO,FINE           ; confronto fra inizio e fine
        BLT CICLO                 ; se inizio < fine, si ritorna all'etichetta ciclo

   DIV CONTA,N               ; conta = conta / n
   MOV M,CONTA               ; assegna ad m il valore della media
ENDM

L'operazione di divisione deve essere anch'essa definita come macro?
No, si può supporre che sia eseguibile da un'istruzione macchina. L'esercizio è sostanzialmente corretto, però ho un paio di osservazioni.
  • Quello che lei chiama "contatore" è in realtà un accumulatore. Un contatore tipicamente varia per incrementi (o decrementi) costanti, mentre qui si si accumula una somma iterata.
  • Che INIZIO sia un registro lo dicono solo i commenti, dal codice appare come un simbolo, ovvero nome di una locazione di memoria, e non è conveniente usare la memoria per la funzione a cui è adibito. Oltre a questo, dovrebbero essere registri anche CONTA e FINE, e il valore da porre in FINE andrebbe calcolato con un'istruzione ADD.
Logged
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #306 on: 13-06-2012, 09:53:57 »

  • Quello che lei chiama "contatore" è in realtà un accumulatore. Un contatore tipicamente varia per incrementi (o decrementi) costanti, mentre qui si si accumula una somma iterata.
  • Che INIZIO sia un registro lo dicono solo i commenti, dal codice appare come un simbolo, ovvero nome di una locazione di memoria, e non è conveniente usare la memoria per la funzione a cui è adibito. Oltre a questo, dovrebbero essere registri anche CONTA e FINE, e il valore da porre in FINE andrebbe calcolato con un'istruzione ADD.

Ho modificato il codice usando questa volta registri a 32bit (EAX, EBX...).

MACRO ARRAY_MEDIA A,N,M

   MOV EAX,#A      ; EAX = indirizzo dell'array A in un registro a 4 byte
   MOV EBX,N        ; se ogni elemento dell'array è di 32bit (4 byte), allora  
   MUL EBX,4         ; esso terminerà nella locazione
   ADD EBX, EAX    ; dell'indirizzo A + Nx4
   MOV ECX,#0      ; registro che accumula le somme successive

 CICLO: ADD ECX,(EAX)      ; visto che EAX è un registro che contiene un indirizzo, si usa ind. a reg indiretto
                                           ; per estrarre il valore ed effettuare le somme successive con ECX
        ADD EAX,#4                  ; incremento di 4 byte
        CMP EAX,EBX                ; controllo se si è arrivati a fine array
        BLT CICLO                    ; in caso negativo, si ritorna all'etichetta CICLO

   DIV ECX,N               ; calcolo della media (somme successive diviso il num. elem.)
   MOV M,ECX              ; assegna ad M il valore della media

ENDM


MUL e DIV sono operazioni di moltiplicazione e divisione.
Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #307 on: 13-06-2012, 13:31:32 »

Ho modificato il codice usando questa volta registri a 32bit (EAX, EBX...).

MACRO ARRAY_MEDIA A,N,M

   MOV EAX,#A      ; EAX = indirizzo dell'array A in un registro a 4 byte
   MOV EBX,N        ; se ogni elemento dell'array è di 32bit (4 byte), allora  
   MUL EBX,4         ; esso terminerà nella locazione
   ADD EBX, EAX    ; dell'indirizzo A + Nx4
   MOV ECX,#0      ; registro che accumula le somme successive

 CICLO: ADD ECX,(EAX)      ; visto che EAX è un registro che contiene un indirizzo, si usa ind. a reg indiretto
                                           ; per estrarre il valore ed effettuare le somme successive con ECX
        ADD EAX,#4                  ; incremento di 4 byte
        CMP EAX,EBX                ; controllo se si è arrivati a fine array
        BLT CICLO                    ; in caso negativo, si ritorna all'etichetta CICLO

   DIV ECX,N               ; calcolo della media (somme successive diviso il num. elem.)
   MOV M,ECX              ; assegna ad M il valore della media

ENDM


MUL e DIV sono operazioni di moltiplicazione e divisione.
Così va meglio, ed è corretto, ma si può fare un po' meglio. È consuetudine usare EAX come registro accumulatore e ECX come contatore. In quest'ultimo caso, impostando inizialmente ECX a N (dunque usando EBX come puntatore agli elementi del vettore), può sostituire le due ultime istruzioni del ciclo con la sola LOOP CICLO (che decrementa automaticamente ECX ed effettua il salto a CICLO se il nuovo valore in ECX è non nullo).
Logged
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #308 on: 19-06-2012, 09:57:01 »

lezione 19 - Quesito 18 : È necessario che le dimensioni delle pagine siano potenze intere di 2? Sarebbe teoricamente possibile avere pagine di dimensione 4000 B? Se sì, sarebbe una soluzione pratica (max 5 righe)?

No, non c'è nessun obbligo nel definire come potenze di 2 le dimensione delle pagine, purchè sia le pagine negli indirizzi virtuali che quelle negli indirizzi fisici siano di uguali grandezza.
Quindi è possibile avere 4000B di dimensione pagina.

Non sarebbe  però una soluzione pratica.
La MMU (il dispositivo che relaziona indirizzi di mem. virtuale e mem. fisica) ha dei registri di ingresso e dei registri di uscita. Il numero dei bit meno significativi di quest'ultimo (offset) è l'esponente che si da una base 2 per raggiungere la dimensione di pagina prestabilita. Se questa dimensione non fosse una potenza di 2, verrebbero a crearsi degli sprechi di bit.
Nel nostro caso di pagine di 4000B, il registro di uscita userebbe 12bit per l'offset. Ma con 12bit è possibile indirizzare 4KB (4096B) e verrebbero cosi sprecati 96B per ogni pagina.
« Last Edit: 19-06-2012, 09:59:41 by کtεvЭ » Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #309 on: 19-06-2012, 20:14:12 »

La MMU (il dispositivo che relaziona indirizzi di mem. virtuale e mem. fisica) ha dei registri di ingresso e dei registri di uscita. Il numero dei bit meno significativi di quest'ultimo (offset) è l'esponente che si da una base 2 per raggiungere la dimensione di pagina prestabilita. Se questa dimensione non fosse una potenza di 2, verrebbero a crearsi degli sprechi di bit.
Nel nostro caso di pagine di 4000B, il registro di uscita userebbe 12bit per l'offset. Ma con 12bit è possibile indirizzare 4KB (4096B) e verrebbero cosi sprecati 96B per ogni pagina.
Giusto, ma non è detto che l'unico inconveniente sarebbe lo spreco di memoria. Va considerata anche la conseguente complicazione nella memoria fisica: tipicamente i dischi hanno il settore come unità di trasferimento minima, e la capacità di un settore è sempre una potenza di 2. Occorrerebbe dunque frammentare informazioni più lunghe inserendo del riempimento fra una pagina e l'altra. Inoltre, dedurre il n. di pagina dall'indirizzo virtuale non sarebbe più effettuabile da una MMU convenzionale, come quella da lei indicata, che ignora i bit meno significativi mediante un semplice scorrimento: occorrerebbe effettuare una divisione per un divisore che non è una potenza di 2, e questa è un'operazione ben più complicata. Il registro di uscita da lei considerato dà l'indirizzo locale di un byte nella pagina, ovvero il resto della divisione in questione, ma ne serve anche il quoziente intero, ovvero il n. di pagina virtuale, per gestire la tabella di corrispondenza fra pagine virtuali e pagine fisicamente in memoria.
Logged
کtεvЭ
Matricola
*
Offline Offline

Gender: Male
Posts: 40



« Reply #310 on: 21-06-2012, 10:15:27 »

Quote
Domanda 2)
Se oltre il 90% dei file occupano al più 8KB ca. mentre gli altri usano oltre il 90% dello spazio disco occupato, che si può dire della dimensione ottimale dei blocchi del disco? Formulare la risposta
Le operazioni di I/O sul disco trasferiscono un blocco alla volta, e per ognuna di queste il tempo di esecuzione ha varie componenti: posizionamento, latenza, trasferimento del blocco. L'ottimalità della dimensione dei blocchi va valutata rispetto a due fattori: tempo di esecuzione dell'I/O (a parità di quantità di dati trasferiti) e spazio effettivamente utilizzato in rapporto allo spazio occupato (che è sempre un multiplo della dimensione del blocco). Credo che ora abbia tutti gli elementi per ragionare sul quesito proposto.

La dimensione ottimale dei blocchi del disco è di 8KB.
Avere dimensioni minori richiederebbe per tutti i file (il 90% è di 8KB mentre il 10% è > 8KB) più accessi e ricerche nel disco, causando un rallentamento dovuto ai tempi appunto di latenza e di posizionamento (in generale occorrono 10ms per raggiungere il blocco e 1ms circa per leggere 8KB. Riferimento 6.2.2 del testo).
Con la dimensione dei blocchi di 8KB, per il 90% dei file non ci sarebbe nessuno spreco in memoria (dato che sono 8KB cad.), mentre per il restante 10% che sono molto più grandi, in media lo spreco è metà di un blocco per ogni file (uno spreco più che accettabile dato che sono pochi i file di grandi dimensioni).
« Last Edit: 21-06-2012, 10:17:54 by کtεvЭ » Logged

<< Poco importano le note in musica, contano le sensazioni che esse producono >> .
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #311 on: 22-06-2012, 11:49:25 »

Quote
Domanda 2)
Se oltre il 90% dei file occupano al più 8KB ca. mentre gli altri usano oltre il 90% dello spazio disco occupato, che si può dire della dimensione ottimale dei blocchi del disco? Formulare la risposta
La dimensione ottimale dei blocchi del disco è di 8KB.
Avere dimensioni minori richiederebbe per tutti i file (il 90% è di 8KB mentre il 10% è > 8KB) più accessi e ricerche nel disco, causando un rallentamento dovuto ai tempi appunto di latenza e di posizionamento (in generale occorrono 10ms per raggiungere il blocco e 1ms circa per leggere 8KB. Riferimento 6.2.2 del testo).
Con la dimensione dei blocchi di 8KB, per il 90% dei file non ci sarebbe nessuno spreco in memoria (dato che sono 8KB cad.), mentre per il restante 10% che sono molto più grandi, in media lo spreco è metà di un blocco per ogni file (uno spreco più che accettabile dato che sono pochi i file di grandi dimensioni).
Il ragionamento è sostanzialmente giusto, ma è affetto da una inesattezza che va corretta, con conseguente modifica di qualcuna delle argomentazioni proposte. Il testo del problema recita "Oltre  il 90% dei file occupano al più 8KB ca." (sottolineatura mia). Questo significa che ciascuno di questi file occupa 8KB o meno di 8KB. Non è perciò corretto sostenere che per questi "non ci sarebbe nessuno spreco in memoria (dato che sono 8KB cad.)".
Logged
Gladior
Matricola
*
Offline Offline

Posts: 87


« Reply #312 on: 06-07-2012, 18:17:16 »

Può essere che è necessario conoscere il numero dei parametri passati al metodo per non eccedere nella zona di memoria della costant pool??
Direi di no, in quella zona ci trova solo l'indirizzo di inizio del metodo nell'area dei metodi. Alla risposta fornita dal suo collega, da lei citata, avevo obiettato:
Sì, ma i parametri sono posti nello stack prima dell'esecuzione di invokevirtual. Perché, invece, proprio nella interpretazione di invokevirtual è necessario conoscerne il numero?
Dunque i parametri si trovano già sullo stack quando inizia l'interpretazione di invokevirtual, si sa dove cominciano, e occorre sapere dove finiscono... la domanda è: perché occorre sapere anche questo? Sospetterei che nell'interpretazione di invokevirtual si debba effettuare qualche altra scrittura sullo stack, senza correre il rischio di modificare i parametri che già vi si trovano.



Conoscere il numero dei parametri durante l'esecuzione di invokevirtual è importante perchè, per costruire l'indice relativo alla porzione costante di memoria,l'indirizzo base del nuovo blocco delle variabili locali si ottiene sottraendo il numero di parametri dal puntatore allo stack e impostando LV in modo che punti OBJREF.OBJREF viene sovrascritto con l'indirizzo della locazione in cui si trovava il vecchio PC.L'indirizzo di Pc è calcolato sommando la dimensione del blocco delle variabili locali(Parametri+variabili locali),all'indirizzo contenuto in LV.
Logged
Giuseppe Scollo
Moderator
Forumista Eroico
*****
Offline Offline

Posts: 1.539


« Reply #313 on: 07-07-2012, 14:33:00 »

Conoscere il numero dei parametri durante l'esecuzione di invokevirtual è importante perchè, per costruire l'indice relativo alla porzione costante di memoria,
No, direi piuttosto "dopo aver costruito l'indice relativo alla porzione costante di memoria che dà accesso a OBJREF e numero dei parametri nell'area dei metodi,". Il resto va bene:
Quote
l'indirizzo base del nuovo blocco delle variabili locali si ottiene sottraendo il numero di parametri dal puntatore allo stack e impostando LV in modo che punti OBJREF.OBJREF viene sovrascritto con l'indirizzo della locazione in cui si trovava il vecchio PC.L'indirizzo di Pc è calcolato sommando la dimensione del blocco delle variabili locali(Parametri+variabili locali),all'indirizzo contenuto in LV.
purché sia chiaro che qui OBJREF è il contenuto di una locazione nello stack, non quella nella porzione costante di memoria (che, appunto, è costante, dunque non può essere sovrascritta).
Logged
Gladior
Matricola
*
Offline Offline

Posts: 87


« Reply #314 on: 08-07-2012, 19:46:33 »

Lezione 13.
Quesito n°19
Il maggior risparmio di ciclci dell' interprete IJVM in Mic-2 rispetto a Mic-1 è dovuto all IFU. Perchè

La IFU permette di ridurre in modo considerevole la lunghezza media del percorso di un'istruzione. In primo luogo elimina interamente il ciclo principale, dato che alla fine di ogni istruzione si effettua un semplice salto all' istruzione successiva. Inoltre risparmia l'ultilizzo della ALU per incremento di PC,e riduce la lungheza  del percorso ogni volta che viene calcolato un indice o uno spiazzamento a 16 bit (dato che assembla  il valore a 16 bit  e lo fornisce direttamente alla ALU come un valore a 32 bit evitando di doverlo assemblare all'interno di H.
Consideriamo IADD la macchina preleva la seconda parola dallo stack ed esegue l'istruzione come prima, tranne il fatto che ,una volta terminata l'operazione ,non è più necessario tornare a MAIN1 per incrementare PC e passare alla microistruzione successiva.Quando la IFU vede che durante IADD3 è stato effettuato un riferimanto a MBR1, il suo registro a scorrimento trasla tutto il proprio contenuto a destra e ricarica sia MBR1 che MBR2. TUtto ciò viene effettuato dall'hardware ,senza l'intervento del microcodice.
Prendiamo ad esempio alcune istruzioni come LDC_W passa da 9 istruzioni a 3 ;ILOAD da 6 a 3; etc..
Logged
Pages: 1 ... 19 20 [21] 22 23 24   Go Up
Print
Jump to: