Il mio primo post inaugura una nuova rubrica che si terrà il mercoledì e si occuperà di software a 360°, spaziando dai linguaggi di programmazione agli ambienti di sviluppo, alle architetture degli elaboratori, e andando anche a pescare dal passato (come in questo caso) per ricordare in che modo si è evoluta l’arte dello sviluppo del codice…
L’arrivo degli home computer nelle case durante la prima metà degli anni ’80 ha portato con sé un’importante novità: l’introduzione degli interpreti BASIC con cui generalmente erano accompagnati e che ha permesso di diffondere la programmazione alla “massa”, come abbiamo riportato in quest’articolo.
Ben presto, però, ci si scontrò coi limiti intrinseci di questo linguaggio, i cui principali erano due: la notevole lentezza nell’esecuzione e l’impossibilità di gestire qualunque aspetto dell’hardware della macchina.
Il primo, in particolare, era molto sentito. All’epoca esplose la passione per l’insieme di Mandelbrot. Ne parlarono i telegionali, con interviste al matematico dell’IBM e le riviste erano piene di quelle ammalianti immagini, chiamate frattali, che venivano generate:
Per i programmatori in erba (e non) il calcolo dei frattali era una tentazione troppo grande per non cedervi, e poiché la carne è debole i programmini in BASIC sull’argomento si sprecarono, per sano interesse verso l’argomento o per mostrare agli altri la propria bravura.
Purtroppo con la potenza disponibile all’epoca i tempi di elaborazione erano a dir poco biblici: ci voleva anche un’intera giornata per sfornare una sola immagine, per non parlare poi di chi si dimenticava di aggiungere il codice per conservarla su cassetta o dischetto al suo completamento, ma questo è un altro discorso…
Fortunatamente tutti i BASIC permettevano, tramite apposite istruzioni, di invocare dei programmi in linguaggio macchina, le cui “leggende” che circolavano esaltavano le gran doti velocistiche. Praticamente era considerato il Sacro Graal o la pietra filosofale dell’informatica.
In effetti sulla carta (e non solo) le differenze era a dir poco abissali: mentre gli interpreti BASIC erano costretti a scorrere il sorgente del programma carattere per carattere, convertirlo in un formato intermedio (i token), tradurlo in un elenco di istruzioni direttamente interpretabili dalla CPU e infine eseguirlo, col linguaggio macchina si saltava direttamente a quest’ultima fase. Insomma, il codice macchina letteralmente “volava”.
Ma non era tutto oro ciò che luccicava. Il linguaggio macchina si portava dietro, infatti, problemi di non poco conto. Innazitutto richiedeva una dettagliata conoscenza della macchina e della CPU in particolare, e poi era oggettivamente difficile lavorarci. Individuato uno spazio libero nella memoria in cui andare a memorizzare il codice macchina, si presentava infatti il problema di realizzarlo. Codice che consisteva in una sfilza di numeri apparentemente senza senso: 169 1 160 0 153 0 128 153 0 129 153 130 153 0 131 200 208 241 96.
In realtà si trattava della rappresentazione numerica delle istruzioni che la CPU doveva poi andare a eseguire. Era necessario, quindi, non soltanto conoscere le istruzioni (e ovviamente gli effetti generati dalla loro esecuzione), ma anche la loro codifica che doveva essere opportunamente riportata.
Generalmente un’istruzione era rappresentata da uno o più numeri che venivano chiamati opcode. Ricordo ancora che, per facilitare il compito, su una nota rivista dell’epoca (Commodore Computer Club) fu pubblicata una tabella che conteneva l’elenco degli opcode della CPU del Commodore 64, la famosa Rockwell 6510.
Questo perché non era facile trovare informazioni su linguaggio macchina, CPU, ecc., e le riviste specializzate erano la fonte economicamente più accessibile che le riportava di tanto in tanto. Oggi tutti i produttori pubblicano gratuitamente libri sull’architettura delle loro CPU, che contengono in appendice l’elenco delle istruzioni coi loro opcode.
Nonostante questi utilissimi strumenti, la scrittura del codice macchina rimaneva comunque molto difficile. I programmi, infatti, non sono costituiti soltanto da una elenco di istruzioni che la CPU deve eseguire sequenzialmente, dalla prima all’ultima: con un modello come questo le tipologie di calcoli eseguibili si riduce drasticamente.
Per aumentare enormemente le potenzialità sono presenti delle particolari istruzioni chiamate di salto che consentono di cambiare il flusso dell’esecuzione, sia a fronte di particolari eventi verificatisi, sia incondizionatamente (si salta e basta).
In genere le istruzioni di salto specificano anche la zona di memoria a cui saltare, e questo poneva un altro problema: quello del calcolo di questo indirizzo (le zone di memoria, dette anche “locazioni”, sono sempre identificate da un numero chiamato, appunto, “indirizzo”). Inutile dire che la calcolatrice era sempre a portata di mano per farsi i conti e tirare fuori i numeretti a esso associati…
Superate tutte queste complicazioni e generato l’elenco dei numeri che rappresentavano il codice macchina che si era scritto, rimaneva soltanto il problema di trovare il modo per caricarlo nella giusta zona di memoria, da cui poi dovevano venir richiamate.
La soluzione era molto semplice, perché i BASIC avevano delle particolari istruzioni che permettevano di leggere una sequenza di dati; dati che, una volta letti, venivano poi ricopiati nella giuste zone di memoria. Il tutto, quindi, si traduceva nell’esecuzione di (poche) istruzioni BASIC che sistemavano il codice macchina, per permetterne quindi l’invocazione:
A questo punto la strada era aperta: quando serviva maggior potenza di calcolo, le parti critiche venivano riscritte in linguaggio macchina e inserite direttamente nel programma BASIC. Le porzioni di codice macchina rimanevano comunque molto piccole proprio a motivo della difficoltà della loro scrittura. In ogni caso ebbero una notevole diffusione, e le riviste dell’epoca non mancavano di presentare listati contenenti copiose parti che caricavano questo codice.
Listati anche molto lunghi che richiedevano parecchio tempo (ore) per essere digitati. Non mancava, al solito, chi si dimenticava di conservare il programma su cassetta o floppy, oppure imprecava contro l’Enel a causa di un black-out o di uno sbalzo di tensione che aveva mandato in fumo tutto il lavoro. Ma anche questa è un’altra storia…
