Limiti e prospettive di ASIM

Limiti e prospettive di ASIM
Una serie di prove di simulazione eseguite con il programma ASIM hanno
consentito di verificare, in prima approssimazione, fino a che punto le
specifiche di progetto formulate nel primo capitolo siano state soddisfatte.
Alcune prove sono state dedicate alla verifica del corretto funzionamento del
programma, altre a stabilire l' effettiva possibilità di simulare le diverse
architetture esaminate in 1.3; nel terzo capitolo sono stati presentati alcune
configurazioni e programmi per la simulazione da utilizzare come esempi d'
uso.
In questo capitolo si cercherà di evidenziare i limiti riscontrati e di suggerire le
modifiche e gli sviluppi possibili.
5.1 La procedura per aggiungere nuovi componenti ad ASIM.
Il limite principale dell' attuale versione di ASIM è la scarsa disponibilità di
componenti simulabili.
Questo aspetto è stato però tenuto in conto in fase di progettazione ed infatti l'
ambiente è stato costruito in modo da rendere il più possibile semplice l'
aggiunta di nuovi componenti.
Il primo aspetto da sottolineare riguarda l' insieme di conoscenze necessarie per
programmare la simulazione di un dispositivo in ASIM.
Ovviamente sono date per scontate la conoscenza del linguaggio C++ e del
comportamento interno del dispositivo da simulare; qui si vuole mettere l'
accento sul livello di conoscenza di ASIM e dell' ambiente di sviluppo
Microsoft Visual C.
In generale, se il componente non è particolarmente complesso, non è
necessario conoscere sull' ambiente Windows molto di più di quanto detto nel
capitolo due. L' interazione con l' ambiente Windows è gestita, infatti, nelle
classi predefinite ed in quelle già disponibili in ASIM per cui il programmatore
non ha necessità di una conoscenza dettagliata su concetti riguardanti la
gestione delle finestre, il multitasking, lo scambio di messaggi, l' input/output.
Il compito è ulteriormente semplificato dalla disponibilità del sorgente delle
classi che implementano i dispositivi predefiniti; questo può essere infatti
ampiamente riutilizzato. Opportuna è invece una certa conoscenza delle
Microsoft Fundation Classes.
Capitolo 5: Limiti e prospettive di ASIM.
2
Per quanto riguarda ASIM, è indispensabile avere una conoscenza a livello di
utente del programma; per quanto riguarda la struttura interna, dovrebbe essere
sufficiente quanto detto nel capitolo quattro (insieme alla descrizione
dettagliata delle principali classi presente in appendice) e quanto si dirà di
seguito.
La programmazione di componenti complessi e la modifica dell' ambiente
stesso richiedono la conoscenza di tutte le classi e del codice sorgente di ASIM
che è allegato a questo lavoro di tesi.
Per inserire la simulazione di un nuovo componente occorre innanzi tutto
individuare, in base alle sue proprietà, a quale dei quattro tipi di dispositivi
previsti nel modello (paragrafo 1.4), esso appartiene; ciò consente di stabilire
da quale classe base (paragrafi 4.4, 4.5, 4.6, 4.7) ereditare quella in cui saranno
raccolti i metodi e i dati necessari per simulare il nuovo componente.
La classe base offre già implementate molte delle funzionalità di cui si può aver
bisogno e richiede di riscrivere un certo numero di funzioni "virtual"; questo
dovrebbe semplificare la stesura del codice indicando le linee guida.
Alcuni dei metodi "virtual" (funzione e parametri di scambio sono descritti, per
ogni classe base, in appendice) da riscrivere sono comuni a tutti i tipi di
dispositivi perchè sono definiti nella classe CBaseWnd:
- OnReset, effettua i controlli sui collegamenti e riporta il dispositivo nelle
condizioni "iniziali" (paragrafo 3.2.4);
- ClockProcess, include le istruzioni necessarie ad implementare le operazioni
che il dispositivo deve eseguire durante un passo di simulazione;
- PaintScreen, cura la presentazione dei dati (tipicamente registi interni) nella
finestra video associata al dispositivo;
- ModifyReg, consente la modifica del contenuto dei registri;
- ShowReg, mostra a video i registri se questi non appaiono già nella finestra;
- ModifyTheMenu, consente di presentare, se necessario, dei comandi specifici
nel menù associato al dispositivo.
Altri metodi sono specifici per un tipo di componente:
- RunInstruction, include le operazioni necessarie ad eseguire un' istruzione
macchina (solo processore);
- RunException, include le istruzioni necessarie per iniziare a servire un'
interruzione (solo processore);
- OnAccessDev, consente la lettura e scrittura dei registri accessibili da bus
(device e nodo);
- OnSetFromOut, riceve in un device i messaggi da un altro device;
Capitolo 5: Limiti e prospettive di ASIM.
3
- OnLinkxMsg, riceve in un nodo i messaggi da un altro nodo.
Come detto in 4.7.2, per un nodo di macchina Data Flow è conveniente
utilizzare come classe base CDfNodeWnd anzichè CNodeWnd.
In generale, riscrivere questi metodi è tutto quanto occorre per la simulazione di
un componente; nuovi metodi possono essere introdotti per gestire delle
operazioni interne al dispositivo (un esempio possibile è l' utilizzo di metodi per
l' esecuzione dei singoli codici operativi di un processore).
Una volta costruita la classe relativa al nuovo componente, l' inserimento nell'
ambiente è molto semplice e richiede due sole operazioni.
Supponendo che il dispositivo da aggiungere sia un device di nome NUOVO e
che la classe che ne descrive il comportamento sia CNuovoWnd (file di
intestazione in "nuovo.h", file sorgente in "nuovo.cpp"), le due operazioni sono:
1) aggiungere la linea #include "nuovo.h" nel file "asim.h";
2) aggiungere, nella procedura CMainWindow::NewElem, le linee:
else if (Name == "NUOVO")
pElemWnd = (CDeviceWnd*) new CNuovoWnd(Nmbr);
Detta procedura è l' unica presente in un file denominato "tomodify.cpp";in
appendice (si veda CMainWindow::NewElem) è spiegato, con un esempio,
dove inserire le due linee di codice.
Infine occorre aggiungere "nuovo.cpp" al file di progetto ("asim.mak") e
ricompilare il tutto (queste operazioni sono descritti nei manuali dell' ambiente
Microsoft Visual C). Nella nuova versione di ASIM che si ottiene, sarà
possibile, a questo punto, simulare configurazioni che includono il device
NUOVO.
5.2 Suggerimenti per l' aggiunta di nuovi componenti.
Quando si è interessati a simulare più componenti dello stesso tipo, aventi
proprietà comuni, può essere utile non ereditare direttamente ogni dispositivo
dalla classe base, ma introdurre una classe intermedia che raccolga tutte le
proprietà comuni; ciò consente sia di semplificare la programmazione dei
dispositivi sia di contenere l' espansione del codice di ASIM. Un esempio di
tale situazione può essere la simulazione di tipi differenti di stampanti o di
dischi o di nodi di macchine data flow; per quest' ultimo caso è stata infatti
introdotta in ASIM la classe CDfNodeWnd da cui ereditare un generico nodo
data flow.
Capitolo 5: Limiti e prospettive di ASIM.
4
La finalità didattica dell' ambiente di simulazione suggerisce l' insieme di
componenti non presenti per i quali è più sentita l' esigenza di disporre di un
simulatore. Tra questi si ricordano:
- processori, come Intel 8086 o Zilog Z80;
- interfaccia seriale;
- "disk controller" + disco;
- "DMA controller";
- "priority interrupt controller" (PIC);
L' inserimento di un nuovo processore richiede in generale uno sviluppo di
codice notevole per implementare l' esecuzione di tutti i codici operativi, ma la
classe CCPUWnd offre tutto il supporto necessario per la parte che riguarda l'
interazione con l' ambiente; per questo l' inserimento di un processore non
presenta difficoltà particolari. Il sorgente della classe che implementa il
Motorola 68000 (M68000) può essere un valido esempio ed offrire del codice
riutilizzabile.
Neanche l' inserimento di un' interfaccia seriale presenta particolarità rilevanti;
inoltre il codice da produrre in questo caso è limitato. L' unico aspetto che
richiede maggiore attenzione è la codifica da adottare per i messaggi (paragrafo
4.6.1) che devono essere scambiati sul collegamento tra due porte seriali; spunti
interessanti si possono trarre dal sorgente della classe C6821PIAWnd che
implemeta in sostanza un' interfaccia parallela (Motorola 6821 PIA).
Per la simulazione di un "disk controller" l' unica fonte di complicazione può
essere l' interazione con un "DMA controller" (se previsto); in questo caso
potrebbe essere utile il trasferimento in blocco di un record fisico sia da disco
sia sul bus.
Il problema del trasferimento in blocco di informazioni complesse riguarda non
solo il caso del "disk controller", ma in generale il collegamento tra device e tra
nodi e il trasferimento su un bus; merita pertanto una particolare attenzione.
Nei paragrafi 4.6.1 e 4.7.1 è stato detto che i collegamenti tra device e tra nodi
avvengono attraverso uno scambio di messaggi, che ogni messaggio ha due
parametri e che a quello a trentadue bit è in genere associato il dato da
trasmettere; quindi sembrerebbe che al più una doubleword possa essere
trasferita con un sol messaggio. In realtà poichè tutti i task possono accedere
alla memoria del PC, è possibile trasferire con un messaggio un oggetto
comunque complesso, inviando il puntatore a questo oggetto; più precisamente
il modo di procedere è il seguente:
- Si costruisce una classe dinamica ereditandola da CObject (una classe
Capitolo 5: Limiti e prospettive di ASIM.
5
dinamica consente di creare, con il comando "new", oggetti che vengono
allocati nell' area di "heap"); essa deve contenere l' insieme dei dati da
trasmettere (ad esempio il record fisico, nel caso del disk controller, o una
matrice, nel caso di macchina data flow i cui nodi eseguono operazioni su
matrici).
- Ogni qualvolta si deve trasferire l' informazione, il dispositivo mittente crea
un oggetto della classe con il comando "new" che restituisce il puntatore all'
oggetto nello heap; questo puntatore, conservato in una variabile, è un dato a 32
bit e può essere convertito nel tipo LONG; il mittente invia il messaggio che
avrà come secondo parametro (che è un LONG) il valore del puntatore.
- Il dispositivo ricevente converte il parametro LONG nuovamente in puntatore
all' oggetto della classe che racchiude le informazioni e può quindi disporre
delle informazioni giunte.
- Intanto il mittente avrà cancellato, appena dopo l' invio del messaggio, la
variabile contenente il puntatore (variabile posta a NULL).
Quest' ultimo punto è importante per conservare la validità semantica del
trasferimento: un oggetto, una volta inviato, non è più disponibile al mittente (i
due task non devono poter operare contemporaneamente sull' oggetto
contenente le informazioni).
Quanto detto vale per il trasferimento di informazioni complesse tra device e tra
nodi, ma un discorso simile è possibile fare per il trasferimento di blocchi di
bytes verso bus/memoria. Il trasferimento di dati sul bus, infatti, è sempre
implementato con uno scambio di messaggi (paragrafo 4.4.2); basta utilizzare il
membro dato del processore che contiene il dato (m_DataBus, paragrafo 4.5)
per contenere il puntatore; il primo parametro del messaggio che normalmente
porta l' informazione riguardante il tipo di accesso (lettura, scrittura, modifica;
di byte, word, doubleword) potrà ammettere nuovi valori per identificare il
trasferimento di blocchi di byte di desiderate dimensioni.
Per la simulazione di un disco, chiarito come sia possibile il trasferimento in
blocco di un record fisico (è ovviamente possibile il tresferimento del record
byte per byte, ma ciò rallenterebbe enormemente la simulazione), resta da
esaminare il problema di come simulare la memoria di massa; le strade possibili
sono due:
- utilizzare la memoria del PC;
- utilizzare il disco del PC.
La prima soluzione consente una simulazione più veloce, ma è praticabile solo
se si sta simulando un disco di limitate dimensioni; per un migliore
Capitolo 5: Limiti e prospettive di ASIM.
6
sfruttamento della memoria è consigliabile adottare la stessa tecnica adoperata
per simulare le RAM e ROM (paragrafo 4.4.1).
La seconda soluzione è un pò meno efficiente, ma consente di simulare dischi
di maggiori dimensioni; per realizzare un tale dispositivo possono essere utili le
considerazioni svolte sulla ridirezione dell' input/output e sulle classi CIO_Data
e CIO_DataStr (paragrafo 4.6.2).
Il tentativo di introdurre un DMA controller o un PIC mette in evidenza un
grave limite del modello definito in 1.4: non è stato previsto per un dispositivo
processore (tipo in cui secondo il modello devono rientrare anche DMA e PIC)
la possibilità di avere registri accessibili da parte di altri processori, cosa che è
invece indispensabile. Purtroppo la struttura interna di ASIM (proprio perchè
nata dal modello) non consente di aggiungere semplicemente questa possibilità.
La soluzione migliore è riformulare il modello aggiungendo un nuovo tipo base
e riprogettare ASIM di conseguenza.
E' tuttavia possibile trovare soluzioni più semplici:
- il PIC può essere ricavato da CDeviceWnd aggiungendo la possibilità di
ricevere il messaggio WM_INTERRUPT e di utilizzare oggetti della classe
CMemInt;
- il DMA può essere ricavato da CDeviceWnd aggiungendo la possibilità di
creare un oggetto della classe CCPUWnd cui affidare il trasferimento dei dati in
parallelo al funzionamento del DMA; esso sarebbe in questo modo simulato da
due task: uno per il controllo ed uno per il trasferimento vero e proprio.
Infine l' ultima osservazione riguarda l' inserimento di componenti come gli
INMOS Transputer. La soluzione consigliata è la seguente:
ereditare la classe che ne implementa il comportamento da CNodeWnd e
consentire ad essa di poter creare un oggetto della classe CMainMemory
(paragrafo 4.4.1) per la memoria locale e un oggetto di una classe ereditata da
CCPUWnd (paragrafo 4.5) per l' elaborazione vera e propria.
In questo modo il dispositivo avrà due task ad esso associati in grado di operare
in parallelo: uno per gestire la comunicazione ed uno per le elaborazioni.
Capitolo 5: Limiti e prospettive di ASIM.
7
5.3 Limiti e prospettive di ASIM.
Dei limiti derivanti dalla scarsità di componenti simulabili e dalle imprecisioni
del modello si è detto nei paragrafi precedenti. Tali limiti condizionano
direttamente sia l' uso sia la possibilità di espandere l' ambiente.
Altri limiti ad un uso ottimale di ASIM vengono dalla mancanza di un "help in
linea" e di un prodotto software che completi l' ambiente integrato, offrendo la
possibilità di scrivere, compilare e correggere i programmi in linguaggio
macchina destinati ai vari processori; attualmente è necessario, per eseguire il
ciclo di sviluppo, utilizzare un "editor" ed un assemblatore (asm.exe per
Motorola 68000) non integrati, il che rallenta le operazioni. Sarebbe quindi
opportuno, per completare l' ambiente integrato per la simulazione di sistemi a
microprocessore, realizzare un programma in ambiente Windows che
sopperisca a detta carenza.
Nel capitolo 3, nel descrivere la creazione di una configurazione, non si è posto
alcun limite al numero massimo di componenti simulabili, ma di fatto questo
non può superare la ventina. Detto numero è limitato:
- dall' area video che non consente di visualizzare troppe finestre; in reltà nel
corso di una simulazione solo un sottoinsieme delle finestre è utile che sia
visibile; la possibilità di sovrapporre e di ridurre ad icona le finestre consente di
simulare molti più componeti di quanti possono essere contemporaneamente
visibili (al più sette o otto);
- dalla velocità di esecuzione di un passo di simulazione che si riduce all'
aumentare dei componenti.
Poichè nel progetto di ASIM non è stato svolto uno studio accurato delle
prestazioni, ma ci si è solo preoccupati di trovare, di volta in volta, soluzioni
efficienti a singoli sottoproblemi, è possibile (ed auspicabile) un riesame del
codice per incrementare la velocità di esecuzione di un passo di simulazione. L'
ambiente di sviluppo software Microsoft Visual C offre il supporto necessario
all' ottimizzazione delle prestazioni (Microsoft Profiler).
In ogni caso la velocità sarà limitata dalla macchina hardware disponibile ed in
particolare dal fatto di disporre di un sistema con una sola CPU. ASIM è stato
infatti progettato per PC; a livello di macchina astratta (PC più Windows) i
componenti elaborano in parallelo, imponendo che la durata di un passo di
simulazione sia quella del passo di simulazione del componente più lento, ma in
realtà il tempo impiegato ad eseguire un singolo passo è dato dalla somma dei
tempi impiegati da ciascun componente. La soluzione adottata per la
Capitolo 5: Limiti e prospettive di ASIM.
8
simulazione è valida su sistemi monoprocessore, ma non su sistemi
multiprocessore; in quest' ultimo caso è possibile trovare tecniche più efficienti
("roll back").
Si è citato più volte l' ambiente di sviluppo software Microsoft; a tal proposito è
però dovuta una precisazione: ASIM è stato sviluppato in Microsoft C/C++
versione 7.0 che è accompagnato dalle Microsoft Fundation Classes (MFC)
versione 1.0, ma è stato poi convertito in Microsoft Visual C che è
accompagnato dalle MFC versione 2.0. Purtroppo le due versioni di MFC non
sono perfettamente compatibili ed è stato necessario modificare parti di codice;
la modifica è stata eseguita seguendo le direttive della Microsoft ("Tecnical
note #19") ed utilizzando un metodo "veloce" che però non garantisce (a detta
della stessa Microsoft) né il corretto funzionamento della nuova versione del
programma né la compatibilità con future versioni del Visual C. Potrebbe
essere allora utile modificare il programma secondo le regole della versione 2.0
di MFC; le direttive per eseguire le modifiche in maniera "completa" sono
disponibili ancora nella "Tecnical note #19".
Tra i requisiti del simulatore didattico dati in 1.5 compare anche la richiesta di
poter scambiare dati con altri prodotti utilizzati per la simulazione funzionale di
sistemi. Si potrebbe, ad esempio, esplorare la possibilità di realizzare in ASIM
la simulazione del controllo a microprocessore di un sistema simulato in Matlab
4.0. La soluzione più semplice è la realizzazione di un filtro che renda
compatibili i file dato di Matlab con i file dato di ASIM (file con estensione
".ios", paragrafi 3.2.5 e 4.6.2). Una soluzione più efficiente è lo scambio dei
dati in memoria, sfruttando il supporto offerto da Windows al collegamento e
all' inserimento di oggetti ("OLE support").
Sebbene ASIM, per i limiti che presenta, non riesca a soddisfare pienamente
tutti i requisiti di un simulatore didattico destinato alla parte esercitativa dei
corsi del settore informatico, questo lavoro di tesi può costituire un utile punto
di partenza per una più efficiente soluzione al problema posto.
In conclusione si richiamano gli elementi di maggior rilievo nel lavoro svolto:
- l' approccio globale al problema con l' analisi di più architetture;
- la definizione di un modello generale e dei requisiti del simulatore didattico;
- il progetto e la realizzazione del prodotto software ASIM.