Il Quarto Membro dell’Equipaggio (9) – L’Interpreter

Una parte del codice di Luminary

Il linguaggio macchina (assembly) dell’AGC svolgeva il suo lavoro in modo egregio per codificare le routine di sistema a basso livello che costituivano il cuore dell’Executive.

Ma pensare di far codificare ai programmatori le complesse equazioni necessarie ai programmi relativi a fasi delle missioni Apollo come l’allunaggio, il decollo o la navigazione utilizzando le stesse istruzioni non era possibile. Era necessario ideare un sistema che permettesse un superiore livello di astrazione, ovvero un linguaggio di programmazione di più alto livello, e anche un lavoro di superamento dei limiti dell’architettura dell’AGC per permettere l’utilizzo di tipi di dati più complessi.

Non potendo realizzare un vero e proprio linguaggio di alto livello con relativo compilatore (ovvero un traduttore tra il suddetto linguaggio e l’assembly dell’AGC), l’MIT ideò l’Interpreter.

Si trattava di quello che oggi verrebbe probabilmente definito un ambiente virtualizzato, una architettura diversa dall’AGC completamente definita a livello software, una architettura dotata di un set di istruzioni ben più esteso di quello dell’AGC (che veniva chiamato Basic), con una serie di tipi di dati ben più complessi e di tutta una serie di funzionalità aggiunte e/o migliorate:

  • Variabili in singola, doppia e tripla precisione

  • Tipi di dati complessi, come vettori e matrici

  • Operazioni vettoriali come il prodotto scalare e il prodotto vettoriale

  • Un set di funzioni trascendentali, come radici quadrate e funzioni trigonometriche

  • Due registri per l’indirizzamento indicizzato della memoria

  • Un ampio stack gestito tramite uno stack pointer

  • Indirizzamento semplificato,senza l’utilizzo dei registri di banking

L’Interpreter era complementare e non alternativo al codice scritto con il Basic ACG: veniva utilizzato per scrivere i cosiddetti ‘mission programs’. Ma per operazioni di basso livello come I/O, gestione degli interrupt e altre, veniva comunque utilizzato codice dell’Executive. In altre parole: l’Executive era perfetto per gestire l’hardware e le attività di basso livello di un sistema operativo, ma con l’Interpreter era molto più semplice realizzare le routine di alto livello per le specifiche parti della missione.

Il formato delle istruzioni

Uno degli obiettivi dell’Intepreter era quello di fornire un set di istruzioni più ampio e versatile. Per poterlo fare venne drasticamente cambiato il formato delle istruzioni. Non si utilizzava più una sola word che connetteva l’opcode e l’indirizzo (o il dato numerico diretto) su cui operare.

Si adottò un formato spalmato su più word. Esisteva una Instruction Interpretative Word (IIW) che conteneva 2 opcode, ciascuno identificato da 7 bit (quindi il set di istruzioni veniva esteso a 128), con il 15˚ usato solo per selezionare il registro indice (quando utilizzato). L’IIW era complementata.

Ciascuna IIW era poi seguita da 0,1 o più Interpretive Address Word (IAW), che rappresentavano i dati o gli indirizzi su cui operavano le istruzioni dell’IIW immediatamente precedente. Non veniva eseguito alcun controllo sulla validità di quello che era contenuto in una word.
L’insieme delle IIW e IAW costituivano la ‘interpreter string‘. Questo è importante, poiché per l’AGC la singola unità di esecuzione dell’Interpreter non erano gli opcode nella interpreter string bensì l’intera stringa gestita dalla routine Interpreter.

Le istruzioni dell’Interpreter erano suddivise in diverse categorie :

  • Caricamento ed archiviazione
  • Aritmetica dei vettori
  • Funzioni trascendentali
  • Funzioni vettoriali
  • Operazioni di scorrimento (bit shift)
  • Gestione dei salti a subroutine
  • Istruzioni di test e diramazione
  • Manipolazione dei registri indice
  • … e altre istruzioni

Un’altra parte del codice di Luminary

Per quanto riguarda la memoria, utilizzando i 15 bit puri di una parola, senza banking registry, veniva utilizzata la tecnica dell’half memory: una routine dell’Interpreter accedeva ad una sola metà della memoria dell’AGC, quella in cui era memorizzata.

L’area utilizzata dall’Interpreter per i suoi calcoli era l’MPAC, che abbiamo già incontrato parlando delle aree di memoria riservate ai job. L’MPAC veniva utilizzato in maniera non strutturata dal codice Basic, ovvero si trattava di 7 word disponibili individualmente per manipolare informazioni. L’Interpreter invece strutturava l’MPAC in maniera diversa a seconda dei dati che andava a trattare (MPAC multimodale):

  • poteva contenere 3 variabili scalari in doppia precisione (usando due word per valore)

  • poteva contenere 2 variabili scalari in tripla precisione (usando tre word per valore)

  • poteva contentere un vettore (tre variabili in doppia precisione)
    Essendo tutto guidato a livello software, l’MPAC era una struttura estremamente flessibile.

I datatype dell’Interpreter

Per quanto riguarda la gestione dell’overflow, al contrario delle operazioni effettuate con il set Basic di istruzioni, non veniva generato nessun interrupt. Era compito del programmatore far si che la routine verificasse lo stato del flag OVFIND (indicatore di una condizione di overflow).

Il flag OVFIND era uno dei flag aggregati nelle flagword: un concetto in tutto e per tutto simile a quello dei canali di I/O. Si tratta di word in memoria in cui ogni singolo bit rappresentava un differente parametro (il cui valore ovviamente poteva essere ovviamente solo binario). Un altro esempio era il flag MOONFLAG del CSM che indicava se ci si trovava nella sfera di influenza gravitazionale della Luna o della Terra (valore poi usato nella risoluzione delle equazioni di navigazione).

Un paio di curiosità su come vennero realizzate alcune delle istruzioni dell’Interpreter:

  • le operazioni su matrici potevano essere effettuate nativamente solo con matrici grandi fino a 3 righe x 3 colonne. Se si doveva lavorare su matrici più grosse si usano dei trucchi, delle tecniche mtematiche per ricondursi ai casi supportati

  • le operazioni trigonometriche forniva o il risultto tramite approssimazioni polinomiali come l’Approssimazione di Hastings, sufficientemente accurate ma non complesse come le serie di Taylor

Grazie all’Interpreter e al suo set di istruzioni ad alto livello il lavoro dei programmatori dell’MIT venne semplificato. Tutto in maniera relativa ovviamente: creare le routine per guidare il Modulo Lunare durante l’allunaggio fu comunque una grande sfida.

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