di  -  giovedì 9 giugno 2011

In questa serie di articoli analizzeremo il funzionamento di alcuni tipi di sistemi operativi, cercando di mostrarne le caratteristiche salienti ed i meccanismi interni.

Per iniziare, partiremo dall’analisi di un software che, pur non essendo un vero e proprio sistema operativo, presentava le funzioni basilari per leggere il contenuto della RAM, scrivere in essa e, opzionalmente, caricare e salvare intere regioni di memoria su dispositivi secondari (spesso unità a nastro magnetico o perforato).

Stiamo parlando del Machine Code Monitor.

Tali Monitor costituivano il principale software in dotazione dei primissimi sistemi di calcolo personale, parliamo di trainers e di home computers, nel periodo a cavallo tra gli anni ’70 e ’80. Leggendo e scrivendo un byte alla volta, è possibile inserire nella RAM direttamente gli opcode in linguaggio macchina, realizzando così i primi rudimentali programmi.

Generalmente bisognava scrivere prima il programma su carta, aiutandosi con i diagrammi di flusso o altro sistema schematico (pseudo codice, o altro), poi tradurre in linguaggio Assembly il programma, successivamente bisognava tradurre il listato in codice macchina e inserire i valori numerici dei singoli byte tramite il Monitor.

Versioni più evolute dei Monitor prevedevano anche un Assembler e un Disassembler, che evitavano il processo di trascrizione manuale degli opcode. Tali Monitor avanzati possiedono spesso anche delle rudimentali funzioni di debugging, tipicamente gestiscono i breakpoints e lo stepping, per cui vengono anche detti Debug Monitor.

Le funzioni principali di un tipico Debug Monitor:

Assemble: traduce una riga da Assembly a linguaggio macchina, e scrive il risultato all’indirizzo specificato.

Disassemble: legge a partire dall’indirizzo specificato effettuando la traduzione da linguaggio macchina ad Assembly.

Registers: visualizza il contenuto dei registri.

Run: carica l’indirizzo specificato sul Program Counter, di fatto serve ad eseguire un pezzo di codice che inizia all’indirizzo specificato.

Put: inserisce un byte all’indirizzo specificato.

Dump: legge un blocco di Ram e lo stampa a schermo (solitamente in esadecimale).

Load: legge un blocco di dati dalla memoria secondaria (nastro o altro) e lo carica a partire dall’indirizzo dato.

Save: prende un blocco dalla Ram e lo salva su memoria secondaria.

Per eseguire queste semplici operazioni, il Debug Monitor si serve di ulteriori funzioni non direttamente visibili all’utente, ma presenti in memoria a determinati indirizzi e che completano quello che potremmo definire come un rudimentale Sistema Operativo. Alcuni esempi di funzioni o routines, in gergo, sono:

PutChar: scrive un carattere a schermo (è la base dell’output su schermo).

PutString: si serve di PutChar per scrivere un’intera stringa di caratteri.

WriteByte: invia un byte verso una periferica di Output, usato anche per scrivere su memoria secondaria, o per settare dei registri harware.

ReadByte: legge un byte da una periferica di Input, ad esempio la tastiera.

CallMonitor: avvia il Debug Monitor.

Questo è il minimo indispensabile per poter costruire un Debug Monitor, ed è solitamente usato anche dai programmi utente per leggere e scrivere sulle periferiche, acquisire gli Input da tastiera o nastri, inviare gli Output su display o stampante. Possono inoltre essere combinate in routine di più alto livello, per eseguire compiti più sofisticati come ad esempio la gestione di un filesystem, una porta di comunicazione seriale / parallela, ecc…

In tale ambiente è chiaro che un solo programma alla volta può essere eseguito, e tale programma agisce a basso livello su ogni aspetto dell’hardware sottostante, a meno di eventuali astrazioni previste da tale rudimentale Sistema Operativo. So che in questi casi è un po’ esagerato parlare di vero e proprio Sistema Operativo, ma i concetti che introdurremo man mano ci guideranno verso la definizione di OS sempre più sofisticati, fino a giungere a quelli che utilizziamo attualmente nei nostri computer moderni.

L’astrazione è il concetto chiave che approfondiremo nel prossimo articolo, in cui presenteremo un esempio concreto di sistema operativo basato su una semplice raccolta di routines come quelle presentate: il KERNAL dei computer Commodore a 8 bit.

18 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
    Mirco Tracolli
     scrive: 

    KERNAL: secondo te si erano sbagliati veramente a scrivere la documentazione, oppure è davvero l’acronimo di Keyboard Entry Read, Network, And Link? :D

  • # 2
    Antonio Barba (Autore del post)
     scrive: 

    la leggenda dice che l’errore sia stato introdotto da Robert Russell nel 1980 durante la scrittura di appunti sul Vic-20, e che sia stato copiato da chi scriveva la documentazione ufficiale con lo spelling errato che tutt’oggi è rimasto KERNAL.
    Tale nome infatti non era presente nella documentazione del PET (1977) dove invece veniva chiamato correttamente Kernel.

    Pertanto Keyboard Entry Read, Network, And Link non è altro che un acronimo inverso, cioè è stato (molto probabilmente) coniato a posteriori per giustificare la scritta errata :-)

  • # 3
    Pluto
     scrive: 

    Mai avuto un Commodore, ma vedendo il print screen credo proprio che mi sarei divertito ad usarlo.

    Sempre meglio delle JSP che mi tocca fare adesso.

  • # 4
    Antonio Barba (Autore del post)
     scrive: 

    @Pluto: quella schermata appartiene al Commodore 128, con l’uscita video secondaria ad alta risoluzione (80 colonne di testo).

    Uno screen abbastanza particolare :-)

  • # 5
    Massimo M
     scrive: 

    Beh, per S.O. si intende tutto quell’insieme di programmi che permettono di accedere a parti più a basso livello della macchina. Qindi per me si tratta comunque di sistema operativo: E’ comunque un programma che “gira” e che dà accesso a ram, periferiche, nastro etc.
    Parliamo di retro computing quindi perchè no?

    Cmq articolo interessante, aspetto i prox articoli.
    Mi piacerebbe venisse affrontato anche il prob del remote debug …

  • # 6
    Antonio Barba (Autore del post)
     scrive: 

    @Massimo M: ottimo suggerimento, il remote debugging prevede 3 componenti: Un server che gira sul device, un client remoto (postazione del programmatore) e, guarda caso, proprio un Debug Monitor residente sul device. Il server riceve i comandi di alto livello inviati dal client, e li traduce in istruzioni semplici da impartire al Debug Monitor, per settare break points, fare lo stepping, ecc…

    Ne parlerò più approfonditamente in un articolo dedicato ai debuggers, più in là :-)

    Per quanto riguarda la definizione di Sistema Operativo, beh… qualsiasi cosa che ti dia un minimo di astrazione dell’hardware può rientrare in tale definizione, sebbene oggi esistano sistemi molto più sofisticati, come vedremo nei prossimi articoli :-)

  • # 7
    Z80Fan
     scrive: 

    Proprio in questi giorni sto ultimando un programma monitor per il mio computer Z80 che presenterò come progetto di diploma… e sto già pensando a un interprete Basic!

    Questi articoli cadono proprio a fagiolo ;)

  • # 8
    Antonio Barba (Autore del post)
     scrive: 

    @Z80Fan
    eheh bravo :-)
    Ne ho scritti un paio in passato, non è per nulla difficile potendo disporre di un computer di sviluppo… tutt’altra cosa era il “bootstrapping” (cioè la partenza da zero) eseguito dai pionieri con i primi trainers, che dovevano immettere il proprio monitor a mano usando solo degli switch elettrici per immettere i bit uno alla volta…

    Un monitor decente comunque non supera le 500 istruzioni in assembly, si può programmare in un paio di giorni se sei già esperto :-)

    In bocca al loop per il diploma! :-D

  • # 9
    Z80Fan
     scrive: 

    @Antonio

    “tutt’altra cosa era il “bootstrapping” (cioè la partenza da zero) eseguito dai pionieri con i primi trainers, che dovevano immettere il proprio monitor a mano usando solo degli switch elettrici per immettere i bit uno alla volta…”

    Una cosa devo dire che mi ha sempre affascinato era proprio il processo d’avvio di un vecchio calcolatore :)
    Anche io volevo fare un front panel come si deve, ma la mancanza di parti mi ha costretto a usare un Arduino (quindi bootstrappavo un sistema con un altro che ha cento volte la sua potenza di calcolo :D)

  • # 10
    Uebmaestro
     scrive: 

    Questo articolo promette di essere il primo di una serie davvero interessante!

    Intanto darò una scorsa agli articoli correlati ;-)

  • # 11
    Felice Pescatore
     scrive: 

    Complimenti per l’articolo che esplora il cuore dei nostri amati/odiati sistemi

  • # 12
    Antonio Barba (Autore del post)
     scrive: 

    @Z80Fan: beh, potrebbe essere un passatempo per la pensione… costruire un computer a transistor e programmarlo con gli interruttori :-D

    @Uebmaestro: cercherò di fare del mio meglio, grazie :-)

    @Felice: amati/odiati dici? io non ho mai odiato un trapano, nè ricordo di aver mai flirtato con una lavastoviglie! :-D Per me, computer e relativo software sono solo strumenti, al massimo posso odiare/amare chi l’ha progettato/realizzato :-D
    Forse è per questo motivo che uso regolarmente almeno 4 diversi sistemi operativi quotidianamente, senza sentire alcun tipo di preferenza “emotiva” verso l’uno o l’altro :-)

    Spero anche che questa mia obiettività sia utile per stilare degli articoli migliori :-)

  • # 13
    Flauzio
     scrive: 

    volevo dare anche io la conferma del mio interesse a questo argomento.

    buon lavoro

  • # 14
    giovanni
     scrive: 

    Complimenti per la serie di articoli che si preannuncia molto interessante… perciò sono curioso di leggerti nei prossimi!
    Il monitor era anche il programma tipo che veniva descritto nei manuali (e nei testi sacri) della programmazione LM per i personal più diffusi… sia per l’utilità sia per la semplicità del software stesso.
    Il mio primo monitor (approfonditamente sfruttato per scandagliare quotidianamente 64kb) era integrato nella ROM del mio AlphatronicPC… 1984?

    Ciao: Buon RC con JurassicNews.com

    PS: @Z80Fan… come palestra è sempre buona l’idea di un emulatore di cpu (ne ho programmati anch’io per gioco evolvendoli di volta in volta da sistemi fedelissimi a esotiche macchine di fantasia), passi per un monitor, ma davvero molti auguri per l’interprete basic: personalmente lo ritengo troppo impegnativo e poco fruttuoso anche come semplice passatempo… perciò, alla fine, eccessivamente frustrante!… io farei un compilatore

  • # 15
    Antonio Barba (Autore del post)
     scrive: 

    @giovanni: grazie :-)
    per quanto riguarda l’interprete Basic, se Z80Fan si attiene alla sintassi ambigua e grossolana dei primi Basic Microsoft (tipo quello del C64 per intenderci) allora può tranquillamente scriverne un interprete o un compilatore anche in ASM senza troppi problemi.
    La sua sintassi era studiata per essere facile da implementare, non per essere un buon linguaggio :-)
    Già implementare un Basic “strutturato” tipo il visual basic è tutto un’altro paio di maniche :-)

  • # 16
    giovanni
     scrive: 

    Certo, il mio voleva essere solo un parere di ordine pratico. Infatti non mi riferivo certo alla complessità del codice e, sostanzialmente, nemmeno alla sua eventuale lunghezza (che dipende anche dal numero di istruzioni che si vogliono implementare perché la struttura base di un interprete, come dimostrato, può essere contenuta in pochi kappa, sicuramente meno di 4)… ma piuttosto mi deprimerebbe particolarmente la pedanteria del codice stesso. Un interprete poi, necessita di tutta una parte di interfaccia con relativi comandi di editing che lo rendono ancora più “inutilmente” palloso da programmare… soprattutto per questo suggerirei un OS elementare (così ci sono le funzionalità più interessanti da realizzare come le scelte per il filesystem e la sua gestione) a cui aggiungere un piccolo compilatore facilmente adattabile ed espandibile in futuro.
    Se poi non si tratta della necessità di emulazione fedele lo troverei un tema molto più stimolante come argomento del diploma.

    D’altra parte, nel “mondo reale” la diffusione del basic come interprete, ed in particolare come softare già presente in rom è stata un motivo di coincidenze di vario ordine e non necessariamente la scelta migliore dal punto di vista della convenienza: abitudine della pratica a partire dai primi pc, capacità limitate degli home e possibilità di dotarli di interfaccia più umana, moda e recepimento da parte del mercato come linguaggio entry-level, interesse commerciale (specie della prima MS)… e altri motivi, hanno portato a questa abitudine. In realtà lo stesso linguaggio in origine, nasceva come compilatore!

    Ciao

  • # 17
    Z80Fan
     scrive: 

    @ giovanni
    “come palestra è sempre buona l’idea di un emulatore di cpu…”
    emulatore? No no, il mio computer è proprio costruito con i componenti reali! :D

    “…ma piuttosto mi deprimerebbe particolarmente la pedanteria del codice stesso…”
    In che senso? Il codice dell’interprete o il codice che verrà interpretato?

    “soprattutto per questo suggerirei un OS elementare (così ci sono le funzionalità più interessanti da realizzare come le scelte per il filesystem e la sua gestione) a cui aggiungere un piccolo compilatore facilmente adattabile ed espandibile in futuro.”
    Per motivi di tempo l’hardware lo ho dichiarato definitivo, quindi non posso aggiungere un dispositivo di memorizzazione tipo un disco IDE; potrei usare l’Arduino che già uso come terminale ma mi porterebbe via del tempo…
    Poi anche un OS ha bisogno di un’interfaccia a linea di comando, e gli algoritmi di parsing per il compilatore… In un interprete ci metto dentro le due cose assieme :D

    In effetti ero indeciso se portare questo computer Z80 oppure il sistema operativo per PC che sto scrivendo, ma ho ripiegato sul primo perchè prendevo dentro anche elettronica; se riesco a scrivere un programmino stupido e a eseguirlo sull’interprete, faccio contenta tutta la commissione ;)

    PS: l’idea era di usare CP/M ma non ho trovato dei sorgenti adatti a essere portati. Mi sarebbe piaciuto molto.
    PPS: scusate il leggero OT :)

  • # 18
    pit28
     scrive: 

    My partner and I stumbled over here by a different website and thought I should check things out.
    I like what I see so i am just following you. Look forward to going over your web
    page repeatedly.|

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.