03/09/2025
Articolo di András Vajda
Margaret Hamilton è divenuta negli ultimi anni una figura quasi mitologica, più che storica, all’interno della narrativa popolare legata al programma Apollo. Il problema non è certo il merito, che fu enorme e documentato, bensì l’accumulo di leggende urbane che finiscono per confondere la realtà tecnica e l’apporto concreto con racconti che, sebbene affascinanti, rischiano di banalizzare la portata vera di quel lavoro. Per questo conviene mettere in chiaro alcuni fatti essenziali, ricostruiti alla luce delle fonti storiche e tecniche disponibili.
Anzitutto: la Hamilton non scrisse "tutto" il codice per Apollo, né per il calcolo delle orbite, né per le sale controllo di Houston, né per i sistemi a terra. Questi erano domini affidati ad altri centri e contractor: al Mission Control del Manned Spacecraft Center (oggi Johnson Space Center), a IBM per i calcolatori di terra, a TRW e North American per altre parti di software e avionica. Il suo compito specifico, che già da solo fu monumentale, riguardava la direzione del Software Engineering Division al MIT Instrumentation Laboratory. Questo laboratorio fu incaricato di sviluppare il software del computer di guida Apollo, il cosiddetto Apollo Guidance Computer o AGC, sia per il modulo di comando sia per il modulo lunare. Hamilton ebbe quindi la responsabilità non solo di una parte del codice, ma soprattutto della struttura metodologica, dei processi di test e validazione, e della concezione stessa del software come disciplina ingegneristica autonoma. Non era la programmatrice solitaria che scriveva listati senza sosta, bensì la mente che organizzava un gruppo di decine di specialisti, coordinava lo sviluppo e gestiva le priorità in un’epoca in cui persino il concetto di “software engineering” non era ancora codificato, figuriamoci quello di Systems Architect.
Secondo mito: "il codice era tutto scritto a mano, minuto dopo minuto, con ritualità quasi monacale". No. In realtà il codice dell’AGC era sviluppato in linguaggio assembly dedicato, attraverso un assembler noto come MAC o YUL. I programmatori scrivevano i listati a mano, li revisionavano, li verificavano su carta (come in qualsiasi altro progetto dell'epoca, sia ben chiaro).
Ma successivamente questi listati venivano trasferiti su schede perforate e caricati nei mainframe IBM, come il System/360, che assemblava il codice e generava gli oggetti binari. Quindi sì, esisteva una fase manuale di stesura iniziale, ma era prassi comune dell’epoca, non un rituale romantico. Il lavoro era collettivo e metodico, non solitario e quasi artigianale come la leggenda vorrebbe.
Terzo mito: "schede perforate ovunque". Anche qui, parzialmente vero, ma soprattutto falso per AGC. Le schede perforate erano effettivamente usate, ma solo come mezzo di input per l’assembler e la compilazione su mainframe. Una volta prodotto il binario finale, il codice non rimaneva su schede, bensì veniva memorizzato in una memoria speciale, la rope memory, che era il cuore della robustezza dell’AGC. A bordo delle navicelle Apollo non c’erano pile di schede perforate: il software definitivo era cucito in moduli hardware.
Quarto mito: l’AGC era un computer a 16 bit. Anche qui, non esattamente. La sua architettura era da 15 bit più un bit di parità, quindi in totale 16 linee fisiche, ma solo 15 dedicate a dati e istruzioni. Non era un 16 bit nel senso classico di macchine come il PDP-11, bensì un’architettura personalissima, word-addressable, con 2 KB di RAM e 36 KB di ROM.
La rope memory merita un discorso a parte, perché è qui che si coglie l’originalità dell’approccio e il genio della soluzione. Si trattava di una memoria a corde intrecciate, detta rope proprio perché i fili di rame smaltato venivano tessuti manualmente attraverso o attorno a piccoli nuclei di ferrite. Ogni bit era rappresentato dal percorso fisico del filo: se passava attraverso la ferrite, il bit era letto come uno; se passava all’esterno, era letto come zero. Non c’era nulla da mantenere con correnti o stati elettrici volatili: il bit era deciso dal cablaggio fisico. Questo rendeva la rope memory intrinsecamente resistente a radiazioni, vibrazioni, campi magnetici esterni.
Non a caso, fu l’unica tecnologia di memoria a sola lettura davvero praticabile e certificabile per ambiente spaziale alla fine degli anni Sessanta.
La produzione era quasi artigianale: il codice, validato su mainframe, veniva tradotto in uno schema di cablaggio, e operaie specializzate della Raytheon intrecciavano i fili letteralmente a mano. Non è retorica dire che il software di Apollo fu cucito. Da questa operazione usciva una ROM definitiva, immutabile, pronta per il volo. Una volta cucita, la rope non poteva essere modificata: era frozen software, destinato a rimanere identico per tutti gli esemplari di una missione. Per Apollo furono prodotte centinaia di rope identiche, da mo***re sia sui moduli reali sia sui simulatori.
Il risultato era straordinario: 36 KB di rope memory e 2 KB di core RAM costituivano la totalità dello spazio di memoria a disposizione dell’AGC. Ma questo bastò a guidare uomini sulla Luna. La rope memory era compatta, affidabile, resistente alle radiazioni, e perfetta per un computer che doveva operare senza margine d’errore.
Questa logica di progettazione, che vede il software definire e congelare l’hardware, non si è fermata agli anni Sessanta. Trenta anni dopo, negli anni Ottanta e Novanta, Raytheon ripeté in un certo senso la stessa operazione, portandola però nell’era dei microprocessori complessi. Con la diffusione dei sistemi VAX di Digital, il Dipartimento della Difesa e l’avionica avevano ormai accumulato una massa enorme di software mission critical sviluppato su VAX e su VMS. Ma i sistemi commerciali non erano adatti a essere imbarcati su aerei da caccia, su carri armati, su satelliti o su navi. Non erano certificati, non erano rad-hard, non sopportavano vibrazioni, escursioni termiche o attacchi elettromagnetici.
La soluzione fu la creazione dei cosiddetti MilVAX: sistemi VAX compatibili, ma militarizzati, certificati, compatti, progettati per resistere ad ambienti estremi. Raytheon sviluppò chipset dedicati che replicavano in silicio rad-hard l’intera architettura VAX, mantenendo piena compatibilità binaria con VMS. In questo modo si poteva prendere il software esistente e trasferirlo su piattaforme avioniche o terrestri senza riscrivere nulla.
I MilVAX erano spesso implementati su doppia Eurocard, con raffreddamento conduttivo e connettori rugged. Interfacce standard per avionica come ARINC-429, ARINC-653 o il bus MIL-STD-1553B li collegavano al resto dei sistemi. Tutti i chip a bordo erano marchiati Raytheon: non si trattava solo di orgoglio aziendale, ma di requisito normativo. Per garantire tracciabilità, qualità e certificazione, ogni componente doveva avere un part number militare e passare test ambientali severissimi. Persino EPROM e SRAM, anche quando basate su wafer di altri produttori, venivano ricodificate e marchiate Raytheon, a garanzia della loro qualifica.
In pratica, così come negli anni Sessanta Raytheon cuciva a mano il software nelle rope memory, negli anni Novanta marchiava e garantiva chip VAX compatibili come propri, offrendoli all’avionica e ai veicoli corazzati come soluzioni a vita lunga e certificate.
Il paradosso è evidente: la rope memory e i MilVAX rispondono alla stessa esigenza, distanziati di trent’anni. Nel primo caso, il problema era come far eseguire software affidabile in un computer a bordo di una navicella spaziale. Nel secondo caso, come continuare a eseguire software mission critical sviluppato su VAX in ambienti ostili e senza poter riscrivere milioni di righe di codice. In entrambi i casi, la risposta è stata congelare il software nell’hardware, rendere fisico ciò che altrove era logico, garantendo che ciò che era stato validato rimanesse immutabile.
Questa genealogia porta con sé una lezione fondamentale. Troppo spesso si racconta la storia della tecnologia spaziale e militare come una sequenza di innovazioni lineari, quando in realtà si tratta di scelte obbligate imposte dal contesto.
La rope memory era l’unica opzione praticabile per Apollo, così come i MilVAX erano l’unica opzione praticabile per portare VAX e VMS in ambienti avionici e corazzati. Non si trattava di estetica, ma di necessità: l’affidabilità e la certificazione hanno sempre avuto la precedenza sulla moda e sulla miniaturizzazione.
Margaret Hamilton, con il suo lavoro pionieristico al MIT Instrumentation Lab, incarnò questa logica già negli anni Sessanta, definendo non solo un software, ma un metodo, una disciplina e un modo di pensare in cui il software era inseparabile dal suo ambiente di esecuzione. Raytheon, con le sue memorie cucite e con i suoi chip marchiati, fece da garante materiale di quella visione. E ancora decenni dopo, nei MilVAX e nei sistemi rugged, la stessa filosofia si è ripetuta: il software prima di tutto, e l’hardware adattato, congelato, certificato per esso.
Se si guarda questa storia nel suo insieme, scompare la leggenda della singola programmatrice che scrive tutto il codice a mano, e si rivela invece la realtà di una filiera complessa, che univa scienza dei materiali, elettronica custom, organizzazione industriale, e processi di ingegneria del software in senso pieno. È una storia che vale la pena raccontare proprio perché più solida, più concreta, più vera delle semplificazioni giornalistiche.
