LOAD IMMEDIATE (LI)

li $t0, 0x12345678 non è una istruzione vera perché richiederebbe 32 bit e 32 bit in una istruzione non possono stare perché ci servirà il OPCODE e l'identificativo del registro, ma l'assemblatore lo accetterà perché sarà lui a farsi carico della traduzione e per questo si appoggerà al registro at. Quindi se scriveremo li $t0, 0x12345678, l'assemblatore spezzerà questo comando in due istruzioni ovvero in lui $at, 0x1234 "at perché è il registro dedicato all'assemblatore per la traduzione delle pseudo istruzioni", e ori $t0,$at,0x5678.

Consideriamo li $t0, 0x5678. Questo numero richiede solo 16 bit per essere rappresentato, quando scriveremo "li" l'assemblatore prima di tradurre guarderà il numero che abbiamo definito, analizzando questo numero capirà che bastano 16 bit e tradurrà NON in lui e ori, ma nella sola ori $t0, $zero, 0x5678.

istruzione ori $t0,$zero, 0x5678 perché fare OR di una variabile con lo zero vuol dire lasciare inalterata la variabile. $t0, 0x12340000, l'assemblatore non tradurrà alla cieca con lui e ori ma comprenderà che avendo tutti 0 nella parte bassa, la sola esecuzione della lui ci permette di raggiungere l'obiettivo del caricamento atteso: ➔ Lui $t0, 0x1234LA (LOAD ADRESS): vogliamo caricare l'indirizzo in un registro lo possiamo fare con li Quando il valore numerico dell'indirizzo di interesse. specificando l'indirizzo Ma potrà accadere e sarà il caso più frequente che noi vorremo caricare in un registro per poi magari scriverlo in memoria usando il nome simbolico attribuito all'istruzione di interesse. Caso case switch: volevamo caricare nella tabella degli indirizzi di salto i valori simbolici L0, L1, L2, L3 che erano le etichette in corrispondenza della prima istruzione delle operazioni da svolgere in base al valore di

k.sull'aiuto dell'assemblatore, usando una nuova pseudoistruzione:

Possiamo contarela $t0, labelcome farà l'assemblatore a trasformare questo in istruzione vera?

Si tratterà di trovare quali operandi attribuire alla lui e ori.

Quando l'assemblatore tradurrà i nostri programmi, ogni etichetta simbolica che avremo definito caratterizzerà un'istruzione di un ciclo, di un salto e così via.

Per l'assemblatore sarà un indirizzo un valore numerico.

Quando l'assemblatore tradurrà le istruzioni costruirà la tavola dei simboli.

È stata usata l'etichetta poi, Dirà: dopo, prima, e poi, dopo, prima corrispondono all'indirizzo che quell'istruzione ha all'interno del codice.

L'identificazione della parte alta o bassa dell'indirizzo sarà totalmente trasparente a noi che scriveremo i programmi.

fatto dall'assemblatore, noi identificheremo

L'istruzione attraverso Questo verrà l'etichetta di interesse che corrisponderà all'indirizzo in cui corrisponde l'istruzione.

Sarà l'assemblatore a consultare la tavola dei simboli, a capire quale indirizzo corrisponde a quel nome e quindi sarà l'assemblatore a collocare la parte alta dell'indirizzo usando lui e sarà sempre l'assemblatore a modificare la parte bassa attraverso ori.

L'assemblatore esaminerà il valore e se l'indirizzo di interesse anche in questo caso vedrà posti a 0 tutti e 16 i bit bassi tradurrà con la sola lui.

MARS non fa quest'ottimizzazione.

LINGUAGGIO ASSEMBLATIVO VS LINGUAGGIO MACCHINA

Assemblativo ci da la possibilità di una rappresentazione simbolica, comoda, come add $t0, $t1, $t2.

Più semplice rispetto a scrivere le configurazioni binarie, senza preoccuparci di sapere quale è il codice dell'add.

il function associato all'add. La realtà è molto simile ma non è uguale perché il primo registro che scriveremo nelle nostre istruzioni sarà la destinazione ma la realtà è che il registro di destinazione non sarà il primo che vedremo comparire nelle istruzioni ma il terzo che compare nei campi all'interno dei registri.

Abbiamo la possibilità di utilizzare delle pseudo istruzioni che sono rese possibili dal non c'è alcun traduttore (assemblatore) e quindi possiamo scrivere: move $t0, $t1, a questo comando ma è, è resa possibile configurazione binaria corrispondente all'interno del set dei comandi dall'assemblatore che capirà che vogliamo copiare t1 in t0 e implementerà questo comando come add $t0, $t1, $zero.

La piccola accortezza da avere è che quando andremo a considerare le performance, i tempi di esecuzione, non possiamo pensare che ciò che

abbiamo scritto sia una sola istruzione ma potrebbero essere più di una istruzione. Quando consideriamo le prestazioni dobbiamo andare a vedere quali sono le istruzioni vere e come queste vengono eseguite, ma inoltre dobbiamo tener conto del fatto che in memoria non sappiamo a priori quante istruzioni vere saranno eseguite. "Ci saranno pseudo istruzioni che richiedono una sola istruzione vera e ci saranno alcune che richiedono più di una istruzione vera del processore". Le pseudo istruzioni sono uno strumento gradevole, ci aiuta a scrivere i programmi, fa carico l'assemblatore della traduzione, ma se vogliamo vedere quanto spazio occupiamo in memoria e i tempi di esecuzione delle istruzioni dobbiamo vedere la traduzione. Ricorda che per avere queste pseudo istruzioni abbiamo dovuto sacrificare un registro ovvero il registro at (registro 1) che è quello che non è utilizzabile da parte del programmatore perché dedicato all'assemblatore per.Tradurre i comandi aggiuntivi proposti.

PROGETTO DI SISTEMI BASATO SU MICROPROCESSORE:

Viene usato l'ambiente di collaudo per portare a progetti funzionanti.

L'ambiente di collaudo usato per capire se il progetto fa ciò che dovrebbe.

Quando si tratta di questi tipi di progetti le cose si complicano un po' rispetto ad un progetto totalmente hardware o totalmente software.

Gli aspetti hw e sw si intersecano e quindi c'è qualche complessità aggiuntiva da tenere in conto e bisogna riuscire ad avere un qualche strumento che permetta di dirimere piccole contenzioni che si possono avere a seguito del fatto che chi ha progettato l'hardware presuma di aver fatto al meglio il suo lavoro idem per chi ha progettato il sw, e quando i due lavori vengono messi insieme e qualcosa non va, è tipico che si dia la responsabilità del malfunzionamento all'altro perché ciascuno pensa di aver fatto al meglio il suo lavoro ma può anche

essere che l'interazione tra le due attività svolte provochi problemi. Bisogna trovare degli strumenti per chiarire queste ambiguità. In quanto i progettisti siano stati chiesti di risolvere un problema reale: quando un problema reale viene proposto ci si trova di fronte al problema che molte cose si possono fare sia nell'hardware che nel software. "Ad esempio, realizzare un sistema per contare degli eventi: possono essere contati da un opportuno circuito elettronico digitale, ma si può anche realizzare un registro." programma che fruendo degli interrupt tenga il conteggio incrementando un quindi ci sono molti problemi che possono essere risolti sia nell'hardware che nel software. Conviene inserire la soluzione nello sviluppo hardware o software? Se inseriamo nell'hardware è chiaro che avremo il vantaggio che il software di gestione del nostro apparato si semplificherà, comporterà un minor onere lavorativo, di costo di.progetto e probabilmente semplificherà il nostro collaudo perché ci sarà qualcosa in meno da tenere sotto controllo perché l'hw in autonomia penserà a gestirlo. Un costo aggiuntivo per ogni esemplare dell'apparecchiatura che ma avremo realizzato. È vero che i dispositivi elettronici hanno costi ridotti ma realizzare centinaia di migliaia o milioni di esemplari, aggiungere qualche dispositivo elettronico che magari vale pochi euro, vuol dire che deve essere moltiplicato per il numero di esemplari da vendere. Il problema è anche che aggiungere dispositivi vuol dire rendere più grande (ingombrante) le nostre schede elettroniche, rendere più complessa la realizzazione (montaggio, saldature, connessioni...). Se inseriamo nel software tutto ciò che riusciremo a mettere nel sw comporterà un costo di progetto più elevato, perché la complessità del progetto cresce ma il costo dello sviluppo.

sw è un costo unatantum (per una volta soltanto). Seppur si tratta di un progetto di grande complessità, il costo della replica del sw (di ogni apparato) è nullo. Dovremmo trovare un bilanciamento tra questi due desideri: quello di alleggerire l'onere per il sw e quello di non appesantire troppo la circuiteria.

Un altro aspetto da considerare è la modificabilità del nostro progetto. Modificare qualcosa che è stato previsto essere nei programmi vuol dire ripensare una parte del progetto, cambiare il contenuto di una memoria ROM che contiene le istruzioni e riutilizzare la circuiteria. Viceversa se avremo inserito la soluzione all'interno del nostro hardware, se le specifiche di progetto, se le esigenze evolvono non è detto che non si debba ripensare anche in modo significativo all'hardware, che vuol dire riprogettare una nuova scheda solo perché bisogna aggiungere un componente o utilizzare uno di taglio diverso.

Ad esempio,

se abbiamo realizzato il contatore nell'hardware, che conta da 0 a 2^13, se l'esigenza che si presenta è quella di ampliare il conteggio, dobbiamo buttar via il nostro hw e ricominciare da capo. Se avremmo realizzato nel programma il conteggio, ci basterà cambiare pochissime istruzioni che renderanno fruibile un registro con un numero più ampio di bit, che magari sarà già a disposizione realizzando la soluzione senza un costo per hw probabilmente con bassissimi costi nel progetto. -Si può pensare che si acquisisce un qualcosa di esistente sul mercato o che si utilizzi qualcosa che in ambito aziendale sia stato sviluppato per finalità simili o diverse a quella che dobbiamo affrontare. È che nell'hw ci siano il processore di interesse, le memorie RAM e Ciò che conta ROM di capacità adeguata, i dispositivi di I/O di interesse, il A/D converter con le precisione di un certo tipo, tutte quelle ri