Il gestore delle interruzioni

Descriviamo ora il comportamento del Gestore delle interruzioni.
Supponiamo che il gestore delle interruzioni sia un programmino in linguaggio macchina, IJVM o quello che c'e' (potevamo anche pensare di averlo realizzato con un microprogramma Mic-1, nel qual caso andava modificato qualcosa nelle microistruzioni sopra).
Il gestore deve mandare in esecuzione i driver (altri programmini in linguaggio macchina) dei devices che hanno fatto richiesta di interruzione. L'ordine di esecuzione dei driver non è arbitrario, ma seguirà una certa politica (si potrebbe anche pensare che i devices hanno una certa priorità fra di loro e che queste priorità siano descritte in una particolare sezione di memoria che viene caricata, per esempio, quando il sistema viene inizializzato).Nel nostro caso la stampante ha priorità maggiore
Una volta che tutte le richieste di interruzione sono state servite, il gestore riabiliterà le interruzioni e passerà il controllo al programma che è stato interrotto. Per permettere di far ciò, supponiamo che il set di istruzioni del nostro linguaggio macchina contenga l'istruzione RETI (RETurn from Interrupt). L'esecuzione di tale istruzione, ripristinerà lo stato della computazione interrotta (per esempio ripristinando il valore del PC che era stato inserito sullo Stack) e riabiliterà le interruzioni. Ovviamente se volessimo programmare il sistema in modo che anche il gestore e/o i driver siano interrompibili, come descritto dalla fig.5.46 del testo (5.44 nella IV edizione), dovremmo modificare il microcodice in modo che non disabiliti le interruzioni. Anche l'istruzione RETI andrebbe modificata in modo da non abilitare le interruzioni. L'abilitazione e la disabilitazione potrebbero essere effettuate da due apposite istruzioni: EINT (Enable INTerrupt), DINT (Disable INTerrupt).
Vedremo ora nel seguito il comportamento dei controller e dei driver di tastiera e stampante.


<---- L'interprete Il controller della tastiera ---->