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 ---->