Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #315 on: 08-07-2012, 22:22:32 » |
|
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)
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #316 on: 16-07-2012, 15:32:29 » |
|
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)
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #317 on: 16-07-2012, 23:45:05 » |
|
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 6 (= 1 kk), non 2 20 (= 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.
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #318 on: 17-07-2012, 13:41:53 » |
|
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?
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #319 on: 18-07-2012, 16:03:14 » |
|
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/
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #320 on: 22-07-2012, 15:50:11 » |
|
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?
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #321 on: 23-07-2012, 16:05:42 » |
|
[...] 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?
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #322 on: 23-07-2012, 17:58:09 » |
|
[...] 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.
|
|
« Last Edit: 23-07-2012, 17:59:41 by Gladior »
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #323 on: 25-07-2012, 08:41:30 » |
|
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?
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #324 on: 05-08-2012, 14:00:30 » |
|
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.
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #325 on: 05-08-2012, 18:09:04 » |
|
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)?
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #326 on: 06-08-2012, 18:06:17 » |
|
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.
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #327 on: 07-08-2012, 10:45:31 » |
|
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.
|
|
|
Logged
|
|
|
|
Gladior
Matricola
Offline
Posts: 87
|
 |
« Reply #328 on: 11-08-2012, 18:22:54 » |
|
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.
|
|
|
Logged
|
|
|
|
Giuseppe Scollo
|
 |
« Reply #329 on: 12-08-2012, 18:50:26 » |
|
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.
|
|
|
Logged
|
|
|
|
|