di  -  mercoledì 3 settembre 2008

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:

Insieme di Mandelbrot

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.

OpcodesGeneralmente 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:

Caricamento linguaggio macchina da BASIC

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…

9 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Giove
     scrive: 

    Articolo interessante, complimenti! E’ vero anche che l’approccio di abbinare a un linguaggio di alto livello uno di livello più basso quando si deve ottimizzare il codice o interagire con l’hardware è ancora attuale. Per esempio è sempre possibile chiamare da MATLAB, IDL, oppure da uno script open source (es phyton), funzioni critte in C. In questo modo si ha il vantaggio di lavorare con un linguaggio più produttivo dal punto di vista delle linee di codice e del tempo uomo senza rinunciare a nulla.

  • # 2
    Peppe
     scrive: 

    Ricordo alcuni di questi listati “da ricopiare” dalle riviste che con una somma di controllo ti avvisavano se avevi sbagliato a digitare i DATA :-) . Ovviamente non ti dicevano quale dei 10.000 numeri che avevi inserito era sbagliato.

  • # 3
    sidew
     scrive: 

    Quando mi manca l’Assembly 6502….

    Quando avevo il Vic20, per superare la lentezza del basic, mi ero messo a studiarmi l’assembly 6502 ( la cpu del Vic era un 6502)

  • # 4
    Cesare
     scrive: 

    x Giove: ti capisco benissimo. Sono un programmatore Python incallito e lo trovo enormemente più produttivo rispetto a linguaggi più “tradizionali” e/o di più basso livello. :D

    x sidew: il Vic20 non l’ho mai avuto. Ai tempi aspettavo con impazienza il PostalMarket o il Vestro per ammirare il Commodore Vic 20 e successivamente il 64.

  • # 5
    Anonimo
     scrive: 

    I frattali sono talmente complessi che ancora adesso le cpu dual core hanno degli attimi di esitazione a far uscire immagini ad alta risoluzione

  • # 6
    Cesare
     scrive: 

    Ironia della sorte, la formula però è semplicissima… :D

  • # 7
    Ale
     scrive: 

    Frattali, eh? Ai tempi, dei compagni di liceo di mia sorella (qui sto parlando di 16 anni fa!!) hanno creato in Pascal un programmino che permetteva di visualizzare il frattale principale (quello in figura), di selezionare un rettangolo a piacere e rielaborare l’immagine per vedere cosa ne veniva fuori… e salvarla pure!

    Non ho mai avuto accesso al codice sorgente (e nemmeno ci avrei capito molto, avevo 7-8 anni, ora ne ho 23, ma perlomeno avrei potuto copiarlo), ma ricordo che il programma era vagamente veloce anche su un 286… ci metteva meno di un’ora per creare il nuovo frattale :D

  • # 8
    Cesare
     scrive: 

    Beh, un 286 era decisamente più veloce di un 6502; tra l’altro il Turbo Pascal era compilato. :-P

    Comunque se fatto in Pascal dovrebbe essere semplice comprenderne il funzionamento: l’algoritmo per il calcolo dell’insieme di Mandelbrot non è complicato. Tutt’altro. :)

  • # 9
    I “monitor” che non visualizzavano immagini… - Appunti Digitali
     scrive: 

    […] Scrivere codice in linguaggio macchina agli inizi degli anni ‘80 servendosi della tabella degli opcode e della calcolatrice era un lavoro a dir poco massacrante: bastava modificare qualcosa e quasi sicuramente si dovevano ricalcolare gli indirizzi dei salti, come ho accennato in un precedente articolo. […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.