AA 2010-2011: Quesiti a risposta aperta

[Gladior]

lezione 13
Quesito 22

Codificare in MIC-2 l'istruzione  JVM DLOAD Varnum, con indice di 1 byte, che inserisce nello stack la sequenza di 2 variabili locali che inizia a tale posizione.


DLOAD1         OPC = MAR = LV + MBR1U; rd
DLOAD2         MAR = SP = SP + 1
DLOAD3         TOS = MDR; wr
DLOAD4         MAR = OPC + 1; rd
DLOAD5         MAR = SP = SP + 1
DLOAD6         TOS = MDR; wr; goto(MBR)

[Gladior]

Quesito n°16
Un disco da 64 settori di 512 B  per traccia compie una rotazione in 16 ms, con I/O in DMA su bus da 16 bit a 2 MHz
. In che misura percentuale il DMA rallenta la CPU?

 64(settori)*512 Byte=32768 Byte(Traccia)=32kB per traccia

32768 Byte*8 bit=262144 bit/ 16 bit(dimensione Bus)=16384 bit /1024 bit=16k  il trasferimento dei dati viene eseguito a 16k in 16ms.


2MHz reciproco per trovarci il periodo------> 1/2000000=0.0000005 S------>500ns


16384 bit(16k)*500ns=8192000ns=8,192 msec  (tempo di cilco del bus ogni 16msec di tempo reale)
16msec-8,192msec=7,808mec/16msec=0,488*100=48,8% (tempo percentuale utilizzato dalla CPU)
100%-48,8%=51,2%(percentuale di rallentamento della CPU)

[Giuseppe Scollo]

I conti e il ragionamento sono corretti. Avrei espresso un po' meglio le dimensioni delle grandezze in gioco, e fatto qualche conto in modo più semplice, per esempio:

32768 Byte*8 bit=262144 bit/ 16 bit(dimensione Bus)=16384 bit /1024 bit=16k  il trasferimento dei dati viene eseguito a 16k in 16ms.

Il bus trasferisce 2 byte in un ciclo, dunque per trasferire 32K byte occorrono 16K cicli del bus. Per questi la velocità di rotazione del disco richiede 16 ms di tempo, dunque il trasferimento in DMA usa 1 kK = 1024000 cicli di bus al secondo (va notata la differenza fra k = 1000 e K = 1024).

2MHz reciproco per trovarci il periodo------> 1/2000000=0.0000005 S------>500ns

OK, perché convenzionalmente la "M" nell'espressione di una frequenza di clock designa 10⁶ (= 1 kk), non 2²⁰ (= 1 KK). Tuttavia non sono necessari molti altri conti a questo punto: se il bus compie 2kk cicli al secondo, e di questi il DMA ne usa 1kK, la percentuale di utilizzazione del bus (ovvero il rallentamento della CPU) da parte del DMA è (1kK / 2kk)*100 = (1024/2000)*100 = 51,2%, come da lei calcolato.

[Gladior]

Quesito 22
lezione16
Scrivere una procedura in un linguaggio assemblativo, con istruzioni per la moltiplicazione, per il calcolo di n! (max 10 righe).

Posso utilizzare l'assemblatare presente nel cd-rom dato in dotazione nel libro cioè as88 ? ho provato ad installare as88 con scarsi risultati qualcuno di voi è riuscito ad utilizzarlo, conoscete qualche guida? oppure il prof ha dato qualche altro simulatore in cui è possibile provare gli esercizi?

[Giuseppe Scollo]

Posso utilizzare l'assemblatare presente nel cd-rom dato in dotazione nel libro cioè as88 ? ho provato ad installare as88 con scarsi risultati qualcuno di voi è riuscito ad utilizzarlo, conoscete qualche guida? oppure il prof ha dato qualche altro simulatore in cui è possibile provare gli esercizi?

Non ho provato a installare as88. Se lavora su un sistema open source dovrebbe avere già pre-installato l'assemblatore GNU, detto GAS (GNU ASsembler: eseguibile 'as'), che riconosce la sintassi di quasi tutti i processori in commercio. Il manuale di GAS è on-line (oltre che incluso nella distribuzione): http://sourceware.org/binutils/docs/

[Gladior]

Quesito 20: Il linker risolve il problema della rilocazione e quello dei riferimenti esterni. Spiegare in cosa consistono e in che senso la soluzione del secondo dipende da quella del primo (max 10 righe).

I problmei risolti dal linker  sono la rilocazione e quello dei riferimenti esterni.
Il primo si verifica perchè i moduli hanno sapzi degli indirizzi separati ,mentre il secondo detto "problema della rilocazione esterna"  è dovuto al fatto che l'assemblatore non conosce l'indirizzo da inserire nell'istruzione CALL del modulo oggetto chiamante, dato che ciascuna procedura è stata tradotta in modo indipendente, l'indirizzo del modulo oggetto chiamato non sarà disponibile fino al momento del collegamento.
Questi problemi vengono risolti dal linker attraverso dei passi.

- Costruisce una tabella contenente la lunghezza dei moduli oggetto
- In base alla tabella, assegna un indirizzo di caricamento ad ogni modulo oggetto
- Aggiorna tutti gli indirizzi rilevabili
- Aggiorna i riferimenti a procedure esterne

la seconda parte della domanda? Può darmi una dritta?

[Giuseppe Scollo]

[...]
Questi problemi vengono risolti dal linker attraverso dei passi.

- Costruisce una tabella contenente la lunghezza dei moduli oggetto
- In base alla tabella, assegna un indirizzo di caricamento ad ogni modulo oggetto
- Aggiorna tutti gli indirizzi rilevabili

rilocabili, suppongo.

- Aggiorna i riferimenti a procedure esterne

la seconda parte della domanda? Può darmi una dritta?

Lei ha indicato l'aggiornamento dei riferimenti a procedure esterne quale ultimo dei 4 passi indicati. Sarebbe possibile effettuarlo prima di qualcuno degli altri?

[Gladior]

[...]
Questi problemi vengono risolti dal linker attraverso dei passi.

- Costruisce una tabella contenente la lunghezza dei moduli oggetto
- In base alla tabella, assegna un indirizzo di caricamento ad ogni modulo oggetto
- Aggiorna tutti gli indirizzi rilevabili

rilocabili, suppongo.

- Aggiorna i riferimenti a procedure esterne

la seconda parte della domanda? Può darmi una dritta?

Lei ha indicato l'aggiornamento dei riferimenti a procedure esterne quale ultimo dei 4 passi indicati. Sarebbe possibile effettuarlo prima di qualcuno degli altri?

Del  primo passo credo non sia possibile perchè costruisce la tabella con la relativa lunghezza dei moduli oggetto,il secondo passo permette ai moduli oggetto di acquisire un insieme di indirizzi lineari,continui che inizialmente erano frammentati.Questi passi sicuramente non godono della proprietà commutativa.Io penso che sia possibile invece invertire il terzo passo cioè aggiornare tutti gli indirizzi rilocabili con aggiorna i riferimenti a procedure esterne.

[Giuseppe Scollo]

Del  primo passo credo non sia possibile perchè costruisce la tabella con la relativa lunghezza dei moduli oggetto,il secondo passo permette ai moduli oggetto di acquisire un insieme di indirizzi lineari,continui che inizialmente erano frammentati.Questi passi sicuramente non godono della proprietà commutativa.Io penso che sia possibile invece invertire il terzo passo cioè aggiornare tutti gli indirizzi rilocabili con aggiorna i riferimenti a procedure esterne.

E in base a che cosa lo crede? Risolvere i riferimenti a procedure esterne significa sostituire a dei simboli di valore ignoto (i riferimenti in questione) il loro valore, cioè i rispettivi indirizzi. Questi indirizzi sono rilocabili nei moduli in cui tali procedure sono definite, e diventano indirizzi assoluti solo dopo che il linker abbia collegato i moduli, ovvero dopo il terzo passo. O pensa a un  meccanismo diverso?

[Gladior]

Programma che calcola il prodotto tra due vettori, il risultato viene posto in un terzo vettore
ovviamente impostiamo i relativi indici
allora
sp lo facciamo puntare all'indirizzo della primo cella del vettore A 0x000
lv lo facciamo puntare all'indirizzo  della prima cella del vettore B 0x005
cpp lo facciamo puntare all'indirizzo della cella del vettore risultante 0x00A
PC=4  lunghezza dei vettiri A e B risultante vettore C di lunghezza 4

INIZIO:    Z=PC; if(Z) goto FINE; else goto PVETT1
PVETT1:  MAR=LV; rd; goto PVETT2
PVETT2:  LV=LV+1; goto PVETT3
PVETT3:  H=MDR; goto PVETT4
PVETT4:  MAR=SP; rd; goto PVETT5
PVETT5: SP=SP+1; goto PVETT6
PVETT6:  TOS=MDR; goto PASSO1
PASSO1:  OPC=TOS; goto PASSO2
PASSO2: TOS=0; goto PASSO3
PASSO3:  Z=OPC; if(Z) goto PASSO6; else goto PASSO4
PASSO4: TOS=H+TOS; goto PASSO5
PASSO5:  OPC=OPC-1;goto PASSO3
PASSO6: MDR=TOS;  goto PVETT7
PVETT7:  MAR=CPP; wr; goto PVETT8
PVETT8: CPP=CPP+1; goto PVETT9
PVETT9: PC=PC-1; goto INIZIO
FINE:

Vorrei capire se ho utilizzato qualche registro in modo improprio.

[Giuseppe Scollo]

Programma che calcola il prodotto tra due vettori, il risultato viene posto in un terzo vettore
ovviamente impostiamo i relativi indici
allora
sp lo facciamo puntare all'indirizzo della primo cella del vettore A 0x000
lv lo facciamo puntare all'indirizzo  della prima cella del vettore B 0x005
cpp lo facciamo puntare all'indirizzo della cella del vettore risultante 0x00A
PC=4  lunghezza dei vettiri A e B risultante vettore C di lunghezza 4
(...)
Vorrei capire se ho utilizzato qualche registro in modo improprio.

Prima di avventurarmi a risponderle, le pongo due domande:

• Qual è la fonte del problema proposto? Si tratta di uno dei quesiti a risposta aperta proposti su Studium.UniCT (se sì, quale), di un problema proposto nel testo (Tanenbaum: se sì, quale), o altra fonte?
• Visti gli indirizzi iniziali dei tre vettori in gioco, mi aspetterei che la lunghezza di ciascuno di essi sia 5. Come mai 4 (valore iniziale in PC)?

[Gladior]

Programma che calcola il prodotto tra due vettori, il risultato viene posto in un terzo vettore
ovviamente impostiamo i relativi indici
allora
sp lo facciamo puntare all'indirizzo della primo cella del vettore A 0x000
lv lo facciamo puntare all'indirizzo  della prima cella del vettore B 0x005
cpp lo facciamo puntare all'indirizzo della cella del vettore risultante 0x00A
PC=4  lunghezza dei vettiri A e B risultante vettore C di lunghezza 4
(...)
Vorrei capire se ho utilizzato qualche registro in modo improprio.

Prima di avventurarmi a risponderle, le pongo due domande:

• Qual è la fonte del problema proposto? Si tratta di uno dei quesiti a risposta aperta proposti su Studium.UniCT (se sì, quale), di un problema proposto nel testo (Tanenbaum: se sì, quale), o altra fonte?
• Visti gli indirizzi iniziali dei tre vettori in gioco, mi aspetterei che la lunghezza di ciascuno di essi sia 5. Come mai 4 (valore iniziale in PC)?

Ha perfettamente ragione ho confuso la posizione dell'indice che è n-1 con la lunghezza effettiva del vettore cioè 5
cmq non so se è presente da qualche parte questo quesito nei rispettivi link dai lei indicati, se devo essere sincero mi sono inventato un quesito , esclusivamente per esercitarmi tutto qui.

[Giuseppe Scollo]

non so se è presente da qualche parte questo quesito nei rispettivi link dai lei indicati, se devo essere sincero mi sono inventato un quesito , esclusivamente per esercitarmi tutto qui.

Ha fatto benissimo. Sospettavo che l'origine fosse qualcosa del genere perché il fatto che il programma debba essere in linguaggio MAL si evince dalla soluzione, non dall'enunciato del problema... Si sarebbe potuto porre lo stesso quesito chiedendo un programma IJVM, magari per poi elaborarne la traduzione in MAL che ne fa l'interprete IJVM per la Mic-1 o la Mic-2. Naturalmente, il risultato della traduzione sarebbe un programma MAL ben diverso da quello da lei proposto, perché l'interprete usa i registri PC, SP ecc. in tutt'altro modo. Questo però non vuol dire che lei faccia uso improprio dei registri, semmai insolito (il PC per esempio è tutto fuorché un Program Counter). Se però l'obiettivo è quello di realizzare un programma MAL a sé stante, allora si possono usare i registri come si vuole, purché la sintassi MAL sia rispettata e il calcolo dia il risultato previsto. Non ho fatto questo controllo (né mi pare che lei me lo abbia chiesto), ma credo di avere risposto alla sua domanda. Il suo esercizio può essere utile per un test sul simulatore EmuMIC-1, per esempio.

[Gladior]

Ho un dubbio riguardante il simulatore dell'istruzione INVOKEVIRTUAL
Quando eseguiamo l'istruzione LDC_W OBJREF  abbiamo i seguenti valori 0x13 e 0x15 dove quest'ultimo rappresenta il riferimento della constant pool che contiene objref il mio dubbio è questo objref contiene un valore 0xb22 che non riesco a capire come si calcola.

[Giuseppe Scollo]

Ho un dubbio riguardante il simulatore dell'istruzione INVOKEVIRTUAL
Quando eseguiamo l'istruzione LDC_W OBJREF  abbiamo i seguenti valori 0x13 e 0x15 dove quest'ultimo rappresenta il riferimento della constant pool che contiene objref il mio dubbio è questo objref contiene un valore 0xb22 che non riesco a capire come si calcola.

L'operando di INVOKEVIRTUAL, come pure quello di LDC_W, è uno spiazzamento (o indice, o offset, la terminologia è un po' varia al riguardo) rispetto all'indirizzo iniziale dell'area delle costanti. Quest'ultimo è il contenuto del registro CPP.