| Entrambe le parti precedenti la revisioneRevisione precedente | |
| ae:notec1 [12/11/2007 alle 09:47 (17 anni fa)] – Marco Danelutto | ae:notec1 [12/11/2007 alle 11:12 (17 anni fa)] (versione attuale) – Marco Danelutto |
|---|
| |
| == Domanda 1 == | == Domanda 1 == |
| * la verifica che A[J] sia compreso fra 512 e 1024 realizzata utilizzando ALU è corretta, ma in generale troppo costosa per il contributo apportato al T omega PO. In questo caso era tollerabile solo perchè il test che controllava se A[J] era maggiore di B[J] doveva comunque essere fatto utilizzando una ALU e quindi richiedeva comunuque 10 tp in T omega PO (5 per l'accesso alla memoria e 5 per la ALU). La cosa più giusta sarebbe stata considerare che 512 e 1024 sono due potenze di due consecutive. Quindi un valore appartiene a [512,1024) sse il bit che rappresenta 512 è a uno e quelli da quello che rappresenta 1024 in poi sono a zero. Il primo test è un semplice bit da un registro (costo 0) il secondo è un OR (due livelli di logica, per fare l'or di 22 valori). Il peso su T omega PO (se questo fosse stato l'unico contributo a tale tempo) sarebbe stato quindi di soli 3 tp. Testare solo il bit di peso 2 alla 9 o solo i due bit di peso 2 alla 9 e due alla 10 non serve comunque a testare l'appartenenza all'intervallo. | * nel procedimento formale di progettazione di una unità di elaborazione, **prima** si scrive il microprogramma (magari dopo aver scritto lo pseudo codice ad alto livello) e **dopo** si realizza di conseguenza la parte operativa. Immaginarsi soluzioni più o meno correttamente basate sul controllo residuo prima di scrivere il microprogramma porta alla necessità di "sintassi non standard" nel microcodice. Per esempio, aver scritto max(A[J],B[J]) -> ... pensando alla realizzazione con controllo residuo può essere una soluzione accettabile, se realizzata opportunamente e soprattutto, se motivata. Occorre far vedere cosa ci si guadagna in termini di ciclo di clock e/o di numero di microistruzioni rispetto alla soluzione standard che prevedeva l'uso della segno(A[J],B[J]) come variabile di condizionamento |
| * è un errore (violazione della condizione di correttezza: la PO risultante (senza queste condizioni) non è di Moore) utilizzare come variabile di condizionamento l'uscita di una ALU che calcola A[J]-B[j] senza aver specificato che | * è un errore (violazione della condizione di correttezza: la PO risultante (senza queste condizioni) non è di Moore) utilizzare come variabile di condizionamento l'uscita di una ALU che calcola A[J]-B[j] senza aver specificato che |
| - la ALU utilizzata è una ALU dedicata (senza alpha di controllo dalla PC) | - la ALU utilizzata è una ALU dedicata (senza alpha di controllo dalla PC) |
| - l'indirizzamento di A e B avviene senza commutatori, ovvero utilizzando indirizzamento multiplo nel caso le stesse memorie debbano essere indirizzate anche da qualcosa di diverso da J | - l'indirizzamento di A e B avviene senza commutatori, ovvero utilizzando indirizzamento multiplo nel caso le stesse memorie debbano essere indirizzate anche da qualcosa di diverso da J |
| * nel procedimento formale di progettazione di una unità di elaborazione, **prima** si scrive il microprogramma (magari dopo aver scritto lo pseudo codice ad alto livello) e **dopo** si realizza di conseguenza la parte operativa. Immaginarsi soluzioni più o meno correttamente basate sul controllo residuo prima di scrivere il microprogramma porta alla necessità di "sintassi non standard" nel microcodice. Per esempio, aver scritto max(A[J],B[J]) -> ... pensando alla realizzazione con controllo residuo può essere una soluzione accettabile, se realizzata opportunamente e soprattutto, se motivata. Occorre far vedere cosa ci si guadagna in termini di ciclo di clock e/o di numero di microistruzioni rispetto alla soluzione standard che prevedeva l'uso della segno(A[J],B[J]) come variabile di condizionamento | * la verifica che A[J] sia compreso fra 512 e 1024 realizzata utilizzando ALU è corretta, ma in generale troppo costosa per il contributo apportato al T omega PO. In questo caso era tollerabile solo perchè il test che controllava se A[J] era maggiore di B[J] doveva comunque essere fatto utilizzando una ALU e quindi richiedeva comunuque 10 tp in T omega PO (5 per l'accesso alla memoria e 5 per la ALU). La cosa più giusta sarebbe stata considerare che 512 e 1024 sono due potenze di due consecutive. Quindi un valore appartiene a [512,1024) sse il bit che rappresenta 512 è a uno e quelli da quello che rappresenta 1024 in poi sono a zero. Il primo test è un semplice bit da un registro (costo 0) il secondo è un OR (due livelli di logica, per fare l'or di 22 valori). Il peso su T omega PO (se questo fosse stato l'unico contributo a tale tempo) sarebbe stato quindi di soli 3 tp. Testare solo il bit di peso 2 alla 9 o solo i due bit di peso 2 alla 9 e due alla 10 non serve comunque a testare l'appartenenza all'intervallo. |
| * per la stima del ciclo di clock è necessario avere presente/progettato **tutta** la parte operativa, altrimenti non si stimano correttamente, per esempio, tutti i ritardi legati ai commutatori (o ai selezionatori sugli ingressi, in questo caso) | * per la stima del ciclo di clock è necessario avere presente/progettato tutta la porzione della parte operativa che concorre a determinare il maggior tempo speso per stabilizzare l'uscita della omega PO, altrimenti non si stimano correttamente, per esempio, tutti i ritardi legati ai commutatori (o ai selezionatori sugli ingressi, in questo caso) |
| * per definire una rete sequenziale (domanda 1.b) occorreva definire le reti sigma e omega. In generale non basta disegnare una collezione di componenti standard connessi opportunamente | * per definire una rete sequenziale (domanda 1.b) occorreva definire le reti sigma e omega. In generale non basta disegnare una collezione di componenti standard connessi opportunamente |
| * | * |
