Interrupt e Supervisor Call
Una Interrupt o Interruzione
è il più facile meccanismo (comunemente adottato da tutti i sistemi
programmabili e da tutti i modelli di CPU sul mercato) che consente di
interrompere e modificare il normale flusso di esecuzione delle operazioni da
parte della CPU al verificarsi di un evento. Una Interrupt Hardware è
generata da dispositivi esterni alla CPU e serve a comunicare il verificarsi di
un evento generalmente asincrono (un dispositivo I/O informa la CPU che è
disponibile a fornire o ricevere dati, il clock segnala la scadenza di un
quanto di tempo, ). Un Interrupt Software o Trap è generata
invece da istruzioni assembly (INT x, SYSCALL) assimilabili a chiamate a
sottoprogrammi con le quali un processo richiede una System Call o Supervisor
Call (esecuzione di una primitiva del SO, accesso diretto a risorse
controllate dal SO, ) oppure segnala una exception (tentata divisione
per zero, la violazione della memoria, disconnesione dalla rete, errore di
trasferimento dati, ). Le interruzioni possono inoltre essere abilitate o
disabilitate con apposite istruzioni assembly (STI Set Interrupt e CLI
Clear Interrupt).
Una Interrupt Request o IRQ
o Richiesta di Interruzione (usata spesso erroneamente come sinnimo di
Interrupt) è il meccanismo con cui lo specifico evento viene segnalato alla
CPU, inviando opportuni segnali ai pin fisici di collegamento della CPU
stessa: a seconda dello stato in cui si trova la CPU, la IRQ può essere servita
o accantonata per essere eseguita in un secondo tempo, e questo perchè gli IRQ
sono organizzati in gerarchie di priorità e una IRQ di livello più basso
può essere scavalcata - e l'interruzione da essa generata a sua volta
interrotta - da una IRQ di livello alto, a meno che non sia associata ad una Non
Maskable Interrupt o NMI, che non può essere accantonata e va
eseguita immediatamente. Diversi tipi di CPU generalmente standardizzano
i loro IRQ in modo che ad un certo IRQ corrisponda sempre lo stesso tipo di
evento: tasto premuto sulla tastiera, comunicazione in arrivo su porta seriale,
e così via.
La gestione degli Interrupt
prevede che, quando la CPU riceve una IRQ, la prima esigenza sia determinare
quale dispositivo l'ha generata e questo può essere fatto con due diversi
sistemi, la scansione degli interrupt (o polling) e la vettorizzazione
degli interrupt. Nel prima caso si effettua l'interrogazione di
ciascuno dei dispositivi collegati per una eventuale conferma della richiesta
di interruzione inviata. Nel secondo caso si usa invece un opportuno circuito
integrato detto Programmable Interrupt Controller o PIC, che
riceve in ingresso un certo numero di linee di IRQ usate appunto dai
dispositivi per richiedere un'interruzione: quando il PIC riceve una IRQ, si
occupa di segnalare alla CPU tale richiesta di interruzione e - se la CPU
conferma la richiesta (potrebbe non confermarla se le interruzioni sono
disabilitate) - deposita nel bus dati l'indice di un Vettore di Interrupt
o Vettore di Interruzione, cioè l'indice che consenta di indirizzare una
vera e propria tabella chiamata anche Interrupt Vector Table o Interrupt
Descriptor Table, in cui siano memorizzati gli indirizzi delle diverse Interrupt
Service Routine o ISR o Interrupt Handler associata alle
interruzioni, ovvero funzioni di tipo callback (una funzione
specializzata passata come parametro a un'altra funzione che invece è generica)
che contengono le operazioni la cui esecuzione è prevista nel caso di ogni specifica
interruzione. In sintesi, quando la CPU riceve una IRQ, recepisce un indice di
interruzione, lo usa per indirizzare la tabella o vettore delle interruzioni e
trova un puntatore ad una specifica procedura, predisposta dal programmatore o
più spesso dal SO; affinchè il meccanismo di interruzione funzioni
correttamente, è necessario che l'esecuzione della ISR sia trasparente
al processo interrotto e qundi serve che la CPU, prima di mandare in esecuzione
la ISR, faccia un salvataggio del contesto del processo in corso in un
apposito stack e che poi, a seguito del ritorno dall'interruzione
tramite l'istruzione RTE, lo ripristini com'era; poichè l'interruzione
va gestita rapidamente non va perso tempo a salvare tutto il contesto del
processo (ad esempio le sue variabili globali) ma solo quello che
effettivamente verrà modificato dall'ISR, e siccome la CPU non conosce in
anticipo che cosa l'ISR modificherà, quando si verifica una interruzione essa
provvede ad affettuare il salvataggio almeno del Registro di Stato del
processo o Program Status Word o
PSW (un'area di memoria o un
registro che contiene informazioni sullo stato dei programmi in esecuzione sul
SO) e del Program Counter o PC.
Il compito del SO, relativamente
al meccanismo di gestione degli interrupt, consiste essenzialmente nel
predisporre gli opportuni sottoprogrammi di gestione degli interrupt per tutte
le periferiche, così come i sottoprogrammi di gestione delle eccezioni,
inserendo i loro indirizzi nella tabella degli interrupt.
Si
definiscono istruzioni privilegiate di un SO quelle istruzioni riservate
all'uso esclusivo da parte del SO (allo scopo di rendere impossibili le interferenze
reciproche di processi concorrenti) concernenti essenzialmente la
manipolazione del sistema delle interruzioni, la commutazione
della CPU tra processi, le operazioni di I/O, l'accesso ai registri
utlizzati dall'hardware per la protezione della memoria e l'arresto
della CPU (halt). La maggioranza degli elaboratori opera in due
modalità distinte, il Supervisor Mode (modo privilegiato, system
mode, monitor mode) e lo User Mode (modo utente, modo
non privilegiato) e le istruzioni privilegiate sono permesse solo
nel Supervisor Mode; il passaggio dal modo utente al modo
privilegiato ha luogo automaticamente al verificarsi di una delle 4 seguenti
condizioni: un processo utente effettua un richiamo del SO (Supervisor Call
o SVC o System Call) allo scopo di eseguire una funzione che
richieda l'esecuzione di una istruzione privilegiata, si verifica il tentativo
di eseguire una istruzione privilegiata mentre ci si trova nel modo
utente, si verifica un interrupt oppure, infine, si verifica una
condizione di errore interna al processo utente (exception); il ritorno
al modo utente viene effettuato tramite una apposita istruzione, anch'essa
privilegiata.
Con riferimento specifico alle SVC, possiamo dire che il kernel
del SO astrae l'hardware mettendo a disposizione dei processi utente una serie
di interfacce standard denominate system call, chiamate di
sistema, con le quali è possibile interagire con il kernel
richiedendogli servizi: ogni volta che un processo necessita di un servizio che
agisce direttamente sulla macchina reale (e che non potrebbe eseguire
direttamente a causa del mascheramento delle risorse da parte del SO allo scopo
di evitare i conflitti), richiede l'intervento del SO affidandosi alle SVC
o System Call; le system call sono implementate in assembly
da
istruzioni (INT x, SYSCALL) in cui l'operando ne specifica il tipo, mentre eventuali
altri parametri vengono passati tramite registri o per indirizzo: effettuando
la chiamata ad una di queste funzioni, si verifica una interruzione del
processo ed il controllo viene passato al kernel, che provvede a fornire
il servizio richiesto; nei linguaggi di alto livello tali istruzioni
assembly sono wrappate (da wrap = incartare, imballare) cioè
mascherate all'interno di routine di libreria dette di supporto a
tempo di esecuzione.
Ricapitolando,
le funzioni di un livello di macchina virtuale sono rese disponibili ai
programmi in esecuzione attraverso primitive (procedure non
interrompibili) del SO, accedute mediante SVC (quindi interruzioni software)
con scambio di parametri tramite registri del processore e specifiche aree di
memoria. Lo stesso meccanismo delle interruzioni consente di attivare da un
livello superiore de Kernel funzioni di un livello inferiore, producendo contestualmente il
salvataggio dello stato del processore nello stack di sistema e ogni ritorno da
interruzione produce chiaramente il rispristino dallo stack di sistema dello
stato del processore.
[ Picolo appunti ]
