Dopo una lunga pausa riprendiamo la trattazione sull'architettura del calcolatore elettronico, in questa e nelle prossime due puntate approfondiremo le interruzioni.
Un qualsiasi sistema di elaborazione se potesse solo eseguire le istruzioni costituenti i programmi applicativi sarebbe scarsamente utile, non sarebbe in grado di comunicare con il mondo esterno, fatto da una miriade di periferiche di I/O, la stessa interrazione con l'utente sarebbe nulla, quindi porterebbe a termine solo compiti ripetitivi come macinare dati, in pratica opererebbe più da macchina calcolatrice programmabile che da macchina general purpose quale deve essere un moderno calcolatore elettronico.
Proprio per gestire eventi indipendenti dal codice eseguito dal processore sono state create le interruzioni. Possiamo considerare le interruzioni come una sorta di campanellino, il cui compito è quello di distogliere l'attenzione del processore dal codice in esecuzione, cosa accada dopo dipende dal software di gestione delle interruzioni e dal tipo di evento segnalato. Il gestore delle interruzioni è un modulo specifico del Sistema Operativo e per la precisione uno dei moduli che agisce a più basso livello, quindi a stretto contatto con l'hardware del sistema.
L'interruzione più antica di cui sia rimasta traccia e quella usata per segnalare un overflow nell'UNIVAC 1, poi man mano sono stati affidati al gestore delle interruzioni altri compiti, fino a divenire una delle caratteristiche più importanti di un'architettura, tanto è vero che un'errata valutazione, in fase di progetto, dell'incidenza delle interruzioni può portare a prestazioni più che deludenti con relativo accantonamento dello stesso o portare ad una profonda e più accurata riprogettazione.
Le interruzioni possono essere classificate in diversi modi come mostra la figura qui sotto:
Prima di proseguire è bene soffermarsi su cosa si intenda con i seguenti termini:
Ripristinabili: l'esecuzione del codice sospeso dal sopraggiungere di un'interruzione deve poter riprendere come se non fosse mai stata sospesa la sua esecuzione, l'unico effetto tangibile deve essere una latenza maggiore nel produrre i risultati.
Non ripristinabili: l'esecuzione del codice sospeso dal sopraggiungere di un'interruzione non può riprendere ed il programma va brutalmente terminato, queste interruzioni sono causate da mafunzionamenti software o hardware, quindi non ha più senso completare il compito in esecuzione quando si è rilevato un errore.
Mascherabili: solo le interruzioni che possono essere disattivate momentaneamente agendo su di un apposito registro del processore che agisce da maschera, ovvero decide quali interruzioni possono essere servite e quali no.
Non mascherabili: sono dette anche NMI e rivestono una grande importanza gestendo eventi che non possono essere assolutamente, neanche temporaneamente, ignorati dal processore.
Sincrone: si verificano sempre nel medesimo punto quando il sistema si trova nelle medesime condizioni sia di stato interno (PSW, PC) e sia di stato esterno (memoria centrale).
Non sincrone: Non sono legate a particolari configurazioni di stato, sono qundi non prevedibili a priori.
Interne: Si verificano durante l'esecuzione di una istruzione (logica cablata/dedicata) o del micro-programma ad essa associato (logica programmata) e sono le più facili da gestire nelle architetture scalari, mentre divengono le più difficili nelle architetture pipeline.
Esterne: Sono generate da eventi verificatisi al di fuori del processore.
Un'interruzione può essere classificata in più modi diversi, per esempio la pressione, da parte dell'utente di un calcolatore, del tasto RESET produce un evento esterno al processore di tipo NMI ed anche non ripristinabile provocandoil riavvio a caldo del sistema.
Passiamo a vedere i lavori sporchi affidati alle interruzioni:
1) richiesta di I/O da parte di una periferica
2) richiesta di un servizio del Sistema Operativo da parte di un programma utente o di un altro modulo del Sistema Operativo
3) Valutazione dei tempi di esecuzione di una porzione di codice da parte di un Profiler
4) Inserzione di Break Point (punti di controllo) da parte di un Debugger
5) Errore aritmetico (Overflow, Underflow, Division by Zero, ...)
6) Page Fault nei Sistemi Operativi con la gestione della Memoria Virtuale
7) Accesso disallineato alla memoria
8) Violazione dei diritti di accesso alla memoria nei Sistemi Operativi con la gestione di Memoria Protetta
9) Codice operativo dell'istruzione non riconosciuto
10) Malfunzionamento dell'hardware
11) Caduta della tensione di alimentazione
Come debba comportarsi il processore in ciascuno dei casi sopra elencati dipende dal progettista (sia esso hardware o software), p. e. su alcune macchine l'interrupt 7 può essere ripristinabile su altre non ripristinabile. Nel primo caso il gestore delle interruzioni, decodificata la richiesta, avvia una apposita routine del Sistema Operativo, che ha il compito di risolvere, mediante accessi multipli alla memoria, il disallineamento e trasferendo il dato nel o dal registro indicato nell'istruzione richiedente l'interruzione, in modo che l'esecuzione possa proseguire come se l'accesso fosse stato allineato. Su altre macchine il gestore si limita a segnalare il verificarsi di un malfunzionamento software, che porta ad una prematura e brutale terminazione del programma incriminato. La stessa tecnica può essere usata per estendere il codice riconusciuto da un certo processore, ogni volta che un codice operativo non viene riconosciuto il gestore delle interruzioni passa il controllo ad un emulatore che provvedere a decodificare l'istruzione ed eseguire, a livello di macroistruzioni, un programma che produca l'effetto desiderato, oppure determini la prematura terminazione del programma.
Il gestore delle interruzioni, a sua volta altro non è che un programma, quindi il processore non fa altro che variare il flusso del codice quando risponde ad un'interruzione, con l'aggravante che al termine della stessa, se è di tipo ripristinabile deve riprendere l'esecuzione del programma originario e per far ciò è necessario che l'interruzione, e con essa tutte le altre che possono subentrare, non alteri lo stato del procesore (banco registri, PC, PSW, ...) rappresentante una sorta di segnalibro all'interno di una elaborazione. Le interruzioni devono produrre un'istantanea dello stato del processore, che useranno per ripristinarlo un attimo prima di restituire il controllo al programma ibernato, in modo che questo possa proseguire come se nulla fosse accaduto durante la sospensione. Una delle tecniche più usate consiste nel salvare tutti i registi (utili) nello stack riservato al programma all'avvio dell'interruzione e riprenderli al suo termine, su alcune macchine ciò non avviene in modo automatico, ma è demandato a chi scrive il gestore delle interruzioni occuparsi del salvataggio e del successivo recupero di tutte le informazioni ritenute indispensabili, ciò ha l'indubbio vantaggio di semplificare notevolmente l'architettura del processore. Il DLX segue questa filosofia.
Nella prossima puntata parleremo delle interruzioni nelle architetture scalari e pipeline.