Il Quarto Membro dell’Equipaggio (4) – Gli Interrupt

Il Mainframe IBM System/360s

Anche questa settimana il post è super tecnico. Approfondiremo ulteriormente alcuni aspetti dell’architettura dell’AGC. In particolare inizieremo a capire che tipo di computer era e come gestiva una particolare metodologia, ancora in uso, per la comunicazione e la risposta a determinati eventi.

Dal punto di vista concettuale, l’AGC era molto diverso dai mainframe in uso negli anni 60 (ad esempio nei centri di calcolo della NASA stessa). Questi ultimi erano chiamati anche sistemi di calcolo a batch (a lotti): eventuali errori che portavano al blocco del sistema non erano considerati particolarmente gravi. Si poteva riavviare con calma il tutto e far ripartire il batch.

Ma l’AGC era un real-time computer (RTC), chiamati anche reactive computer: computer per cui esistono stringenti vincoli di reazione e risposta agli eventi. Un RTC deve poter reagire a determinati eventi in tempi dell’ordine dei millisecondi o anche meno. La terminazione non controllata di programmi, la mancata gestione di una richiesta, l’arresto del sistema sono tutte condizioni NON accettabili. Pensate ad un blocco irrimediabile dell’AGC durante una manovra, ad esempio durante la fase di allunaggio (ricorda nulla? Allarme 1202?!).

Un’altra importante caratteristica dell’AGC (su cui tornerò prossimamente) era quella di essere un computer multitasking, ovvero in grado di eseguire diverse attività allo stesso tempo: questo non in senso letterale ovviamente. Una serie di attività (job) venivano eseguiti ciascuno per un determinato intervallo di tempo, alternandosi nell’utilizzo delle risorse di calcolo dell’AGC. La percezione per un osservatore esterno (come l’utente) era la contemporaneità nell’esecuzione. Ne facciamo esperienza tutti i giorni usando i PC.

Durante l’esecuzione di questi job, l’AGC era completamente ignaro di tutto quello cha accadeva attorno ad esso: i timer e i dispositivi di I/O operavano indipendentemente e senza coordinarsi con il computer. Il meccanismo utilizzato per far si che che l’AGC potesse prendersi cura, quando necessario, di eventi esterni (errori o condizioni normali di funzionamento di dispositivi esterni) era quello degli Interrupt (Interruzioni), un meccanismo ancora utilizzato oggi in ogni PC.

Tecnicamente, un interrupt è un segnale asincrono, generato per indicare alla logica di un computer che si è verificata una condizione che richiede tutta la sua attenzione. Quando si verifica una richiesta di questo tipo (chiamata Interrupt Request, IRQ), l’esecuzione del job corrente viene sospesa per permettere l’esecuzione di un piccolo programma chiamato Interrupt Service Routine (ISR) o Interrupt Handler, che gestisce l’evento. Al completamento dell’ISR, riparte il job precedente. L’operazione di sospensione del job corrente e lancio dell’ISR e quella di fine dell’ISR e ripartenza del job viene gestita tramite un’operazione di context switching (cambio di contesto): il contenuto dei registri principali del computer viene salvato in modo da poter essere in seguito ripristinato lo stato corretto.

La tabella degli interrupt (immagine tratta dal libro ‘The Apollo Guidance Computer’)

L’AGC rispondeva a diversi interrupt. La tabella qui accanto li riporta tutti. Segnalo in particolare:

  • T4RUPT: scattava ad intervalli regolari ed aggiornava il display del DSKY
  • KEYRUPT: utilizzato per segnalare la pressione di un tasto sul DSKY da parte dell’utente
  • T3RUPT: era generato ad intervalli regolari da uno dei timer hardware ed aggiornava l’orologio interno dell’AGC, oltre a guidare l’esecuzione della waitlist (maggiori dettagli qui sotto)
  • UPRUPT: scattava ogni qualvolta una word a 16-bit proveniente dal sistema di uplink (trasmissione da terra verso l’AGC) veniva caricata all’interno del computer

Ovviamente le risposte ai diversi tipi di interrupt erano diverse, sia per complessità che per ‘urgenza’ o criticità. Esisteva una tabella in memoria dove erano salvati gli indirizzi delle diverse ISR: ad esempio premere un tasto del DSKY (interrupt KEYRUPT) provocava l’esecuzione della ISR a partire dalla locazione 0400248. Le ISR erano delle brevi routine, proprio per limitare la durata della loro esecuzione e ritornare il prima possibile all’attività precedente. Se per caso il procedimento era più lungo, allora la ISR aggiungeva un job alla lista di quelli in esecuzione che veniva poi processato come tutti gli altri. In alcuni casi non era tollerabile che si scatenassero degli interrupt, ad esempio durante la lettura dei dati dalla IMU. Era possibile inibire l’uso degli interrupt eseguendo l’istruzione INHINT.

L’attivazione dell’interrupt T3RUPT (legato al conto alla rovescia effettuato all’interno del timer TIME3) guidava l’esecuzione di un componente chiamato la Waitlist. Questa non era che una lista di semplici attività da compiersi periodicamente: controllare lo stato di determinati interruttori, l’accensione o lo spegnimento temporizzato di una spia, la verifica del funzionamento del pilota automatico digitale (Digital Autopilot) ed altri ancora. Una specie di lista di ‘lavori domestici’ per mantenere l’AGC efficiente. Un’altra serie di programmi denominati Pinball (sempre guidate da interrupt) erano responsabili della gestione dei display e dei tasti del DSKY.

Esisteva poi una serie di 8 registri speciali all’interno dell’AGC chiamati Counters (Contatori): 6 venivano utilizzati per memorizzare le letture delle velocità e degli angoli letti dalla IMU, 2 servivano a memorizzare gli angoli del sestante (nel CM) o la lettura del rendez-vous radar (nel LM). L’idea iniziale fu quella di utilizzare dei normali interrupt per gestirli: al variare della posizione della IMU, un interrupt faceva in modo che la nuova lettura venisse salvata nei registri. Purtroppo questo approccio (con il conseguente context switching e tutto il resto) avrebbe causato un enorme carico sull’AGC durante le manovre più dinamiche (ad esempio durante una fase di discesa verso la Luna o un abort).

Venne allora deciso un approccio differente (definito cycle stealing): dopo l’esecuzione di ogni istruzione l’AGC verificava se un counters interrupt era in attesa di essere processato. In questo caso, il counter corrispondente veniva aggiornato e l’esecuzione proseguiva con l’istruzione successiva: niente context switcing, solo l’utilizzo di un po di tempo dell’AGC.

Osservando la lista degli interrupt si nota l’assenza dell’Invalid Code Interrupt (presente in altri modelli di computer) , dedicato a segnalare l’utilizzo di una istruzione non valida. Nell’AGC non c’era perché non esistevano istruzioni invalide! Il set di istruzioni dell’AGC copriva tutte le possibili combinazioni dei bit dedicati agli op-code nella word.

Un’ultima curiosità spicciola: come parte del context switching, veniva salvato il registro BBANK (usato per l’indirizzamento, come visto la settimana scorsa): la locazione di memoria utilizzata era denominata BANKRUPT (fallito) !!!

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...