Trattamento delle interruzioni:

Il test sulla presenza di interruzioni è effettuato da IU. Il trattamento dell’interruzione non è

concettualmente diverso da quello visto per il processore elementare, in quanto si traduce in un salto (una
chiamata a procedura) generato da una qualunque istruzione verso una istruzione appartenente allo stesso
spazio di indirizzamento del processo che ha ricevuto l’interruzione. In questo modo si permette che
istruzioni precedenti a quella che ha ricevuto l’interruzione proseguano normalmente lungo il pipeline.
Talvolta questo modo “normale” di operare prende il nome di interruzioni imprecise. Il termine è dovuto,
probabilmente, al fatto che, in alcuni sistemi, si desidera invece (per motivi vari, non tutti razionali)
provocare, in modo pressoché istantaneo, l’interruzione del programma, come se l’interruzione si fosse
verificata prima che venissero iniziate le istruzioni attualmente in fase di elaborazione nei vari stadi. La
tecnica, detta delle interruzioni precise, necessita di metodi di “recovery” basati su salvataggio di stato,
identificatori unici e segnalazioni da parte di IU.
Interruzioni imprecise: all’interruzione fa seguito un salto (come se fosse una chiamata – call – di un
sottoprogramma). Comunico all’IM che voglio l’handler dell’interruzione. Il termine “impreciso” deriva dal
fatto che in qualche maniera continuo a fare un po’ di cose che logicamente non dovrebbero accadere.
NOTE LIBRO: In un funzionamento pipeline, ricevendo l’interruzione durante una certa istruzione, altre
istruzioni precedenti sono ancora in una fase dell’elaborazione e non concluse. Poiché la fase assembler
(handler) è una procedura chiamata dall’istruzione interrotta, essa rappresenta una sequenza di istruzioni
logicamente successiva alle istruzioni attualmente in corso. Quindi il trattamento di interruzioni/eccezioni
non comporta alcun problema in un funzionamento di IU in-order. Infatti lo stato della macchina (registri
generali e in virgola mobile) è sempre quello consistente con la semantica del programma, quindi è quello
logicamente aggiornato dalle istruzioni precedenti. In altri termini, la procedura Handler dell’interruzione
verrebbe eseguita nell’ordine del programma, e quindi opererebbe o su valori dei registri temporanei
propri o su valori consistenti dei registri modificati dalle istruzioni precedenti. Un problema implementativo
nasce quando il funzionamento di IU sia out-of-order, e deriva proprio dallo stabilire un punto della
computazione che sia caratterizzato da uno stato consistente, cioè caratterizzato dai contenuti che i registri
avrebbero avuto al termine dell’esecuzione sequenziale o in-order della sequenza precedente la chiamata
dello handler.

Ciò si può ottenere principalmente in due modi:

Interruzioni precise: Vorrei che nell’istante in cui l’istruzione ISTR2 subisce l’interruzione, ISTR2 venga
effettivamente completata, mentre l’esecuzione della successiva istruzione (ISTR3) venga cancellata.
Salvando lo stato e scrivendo nel processore i cambiamenti solo quando sono sicuro che non ci sono
interruzioni.
-> Con la tecnica del checkpointing, cioè salvando periodicamente lo stato della CPU in opportuni registri
buffer (ad esempio, il buffer di riordino), e ripartendo da tale stato, oppure