Sviluppi futuri

PUTS: PUSH R0 PUSH R1 LDWI R0 0 L_PUTS: LDBI R1 0 LDBR R0 R10 SUB R0 R1 JMPZ END_PUTS OUTB R0 0002 INC R10 JMP L_PUTS END_PUTS: POP R1 POP R0 RET

; f u n z i o n e PUTS, stampa a video di ; ogni c a r a t t e r e d e l messaggio con ; incremento d e l puntatore ,

; f i n e d e l l a stampa quando s i i n c o n t r a ; i l c a r a t t e r e "/0" c o r r i s p o n d e n t e a 00h

4.3 Sviluppi futuri

SimOS è soltanto la punta di un possibile iceberg: si presta eettivamente ad un numero veramente grande di possibili modiche:

• OTTIMIZZAZIONE: Dal nostro punto di vista, la prima operazione da eseguire sul codice è quella di ottimizzarlo nell'esecuzione delle sue attuali funzionalità. Riordinare in maniera modulare il listato, semplicare o gene-ralizzare certe routine, stabilire un metodo di attribuzione coerente ai nomi delle etichette, possono essere solo i primi passi della fase di ottimizzazione. E' necessario rendere questa parte di codice appena scritta il più robusta possibile. Essa infatti rappresenta il cuore del sistema operativo e su di essa si basano tutte le restanti routine.

• AMPLIAMENTO DEL DEBUGGING: Come seconda cosa potrebbe esse-re opportuno forniesse-re agli utenti che utilizzano SimOS, ulteriori strumenti che ne facilitino la comprensione dei meccanismi, le variabili impiegate e le operazioni svolte. SimOS, infatti, non è solamente un mezzo che ore ai programmi utente un ambiente nel quale essi possono venire eseguiti in maniera sicura, ma è altresì un importante strumento didattico per inizia-re a compinizia-rendeinizia-re le problematiche ineinizia-renti un sistema operativo e il suo funzionamento.

• AMPLIAMENTO DEL CODICE, SHELL E NUOVA OTTIMIZZAZIONE: Come terzo passo si suggerisce di iniziare a specializzare alcune sezioni del codice, dall'introduzione di nuove trap di lettura, al miglioramento della gestione della tastiera, allo sviluppo di un sistema di shell minimale, ad un parco di chiamate a sistema per la gestione dei programmi (la terminazione degli stessi da linea di comando). Per ogni fase si consiglia di eseguire l'operazione di ottimizzazione sul codice.

• COMPILATORE C-ASM: Migliorare e completare il progetto già tuttora avviato per realizzare un compilatore da codice C a codice ASM.

• FILE SYSTEM: In seguito alla simulazione del dispositivo hardware che gestisce la DMA, si può iniziare a pensare di poter implementare all'interno di SimOS la gestione del le system. Ciò comporta nuove chiamate a sistema per l'apertura dei le in memoria secondaria, il caricamento degli stessi in memoria principale e la possibilità di operare sui le e le cartelle.

• SimOS DINAMICO: Giunti a questo punto è possibile iniziare a pensare ad un sistema operativo di tipo dinamico, ma la concezione di questo genere di sistema è così lontana che probabilmente non vale la pena nemmeno di parlarne.

Capitolo 5

SimCPU & SimOS - testing

L'importantissima fase di testing del sistema viene eettuata in questo capitolo. Il sistema operativo (nonché l'hardware), verrà stressato mediante numerosi e diversi stimoli. In questo contesto verrà condotto un testing prettamente correlato alla parte del progetto che concerne questa tesi, ma verrà utilizzato il sistema totale per testarlo. Ciò attribuisce un valore decisamente più grande al test in quanto, se concluso in maniera corretta, implica automaticamente un corretto funzionamento anche della tesi condotta parallelamente.

5.1 Considerazioni pre-simulazione

La generazione delle interruzioni da parte del timer avviene in seguito alla con-clusione di uno dei due conteggi che sono stati implementati nel simulatore, il conteggio per istruzione e il conteggio per istanti temporali. E' facile capire che il primo di questi, essendo il numero di istruzioni da contare ssato, fornisce un segnale di interrupt di tipo deterministico, ovvero è sempre possibile prevedere quando il segnale di interruzione verrà generato. Il conteggio a tempo, invece, fornisce un impulso di timer ogni qual volta vengono eseguite una serie di istru-zioni la cui esecuzione occupa il tempo eettivo di TIME_SLICE e dunque la generazione delle interruzioni in questa modalità è del tutto indeterministica. Il numero di istruzioni che vengono eseguite all'interno di una TIME SLICE, infatti, è legato essenzialmente al codice eseguito in quanto ogni istruzione ha tempi di esecuzione dierenti.

Mostrare il funzionamento delle routine software e delle procedure hardware, che è essenzialmente lo scopo di questo capitolo, equivale in sostanza a bloccare l'esecuzione della CPU ad istanti sensibili (momenti di passaggio tra il kernel e lo user mode) per poter eseguire delle visualizzazioni della mappatura della me-moria e della CPU necessarie a vericarne il corretto funzionamento. Tuttavia, l'indeterminazione restituita dal conteggio di tempo non fornisce aatto un aiu-to per quanaiu-to concerne la determinazione dell'istante sensibile (anche se questa limitazione verrà poi agevolmente superata); viceversa, l'utilizzo del conteggio di istruzioni, se da un lato può essere utile per determinare l'istante di generazio-ne dell'interruziogenerazio-ne, dall'altro, non garantisce una sollecitaziogenerazio-ne sucientemente

elevata alla CPU per poter considerare robustamente corretta la parte di codice sotto testing. Sarebbe opportuno dunque eettuare entrambi i tipi di testing, ma la facilità con la quale il testing robusto può essere eettuato (basta considera-re qualsiasi programma utente e farlo giraconsidera-re per qualche minuto) lo considera-rendeconsidera-rebbe ridondante ai ni esemplicativi del capitolo.

5.1.1 Breakpoint

Uno tra gli strumenti più importanti di debugging è quello del sistema di Break-points. L'introduzione della memoria virtuale e l'espansione della memoria sica, ha indotto il sistema dei Breakpoint ad operare solamente all'interno dei segmenti dei vari programmi sia kernel che utente che vengono schedulati nella CPU. In particolare, attualmente, impostare un breakpoint ad un determinato valore del-la memoria virtuale equivale essenzialmente ad impostarlo per ogni programma presente in memoria, incluso il sistema operativo. Starà all'utente discriminare se il punto al quale l'esecuzione si è fermata è quello del programma prescelto o meno.

5.2 Test trasparenza e di codice rientrante per