di  -  mercoledì 14 gennaio 2009

Basta soltanto il nome: 8086. Simbolo, nel bene e nel male, di una famiglia di microprocessori che ha fatto LA storia, essendo diventata l’ISA più diffusa e dominando da anni incontrastata il mercato dei computer.
Come sappiamo un po’ tutti, la sua fortuna è legata a doppio filo ai PC, e in particolare al Personal Computer col quale IBM decise di entrare in un mercato diverso da quello che era stato fino ad allora oggetto delle sue attenzioni (cioé i mainframe), facendo diventare la CPU di Intel il cuore del sistema.
Come capita tante volte, nel mercato non s’impone il prodotto migliore, ma quello che si riesce a vendere meglio. Non fa eccezione il PC e il processore che si porta dietro, che presenta delle soluzioni architetturali che fanno un po’ storcere il naso agli appassionati.

Alcuni ricorderanno il motto tristemente noto e attribuito erroneamente a Bill Gates (ma pronunciato da un ingegnere IBM): “640K should be enough for everyone“. Tradotto: “640KB dovrebbero bastare per chiunque”. Si riferiva al massimo quantitativo di memoria libera a disposizione delle applicazioni (sistema operativo incluso) che offriva il PC.
Il limite teorico era rappresentato dai 20 bit d’indirizzamento dell’8086, che permettevano di accedere a 1MB (1024KB, cioé 2^20 byte) di memoria in totale. Purtroppo a causa di scelte poco felici da parte degli ingegneri di IBM, buona parte di questo spazio d’indirizzamento fu riservato alle periferiche e al BIOS, riducendone la quantità utilizzabile ai famigerati 640KB (in realtà si trovò poi il modo di sfruttare parte dei 384KB riservati, ma rimaneva una magra consolazione).
Il limite dei 1024KB restava però a carico del microprocessore, e veniva fuori anch’esso da una scelta che, anziché poco felice, personalmente definirei perversa, per il meccanismo che vi sta dietro. Probabilmente il limite dei 20 bit d’indirizzamento nasceva dall’esigenza di ridurre i costi di packaging del chip; all’epoca erano di moda package con 40 pin, per cui usarne 20 soltanto per generare l’indirizzo ne lasciava pochi per i segnali di controllo.
Risultava impossibile, infatti, pensare di allocarne altri 16 per i dati: avrebbe richiesto un package con molti più pin e, quindi, più costoso. Ciò comportò la necessità dell’uso del multiplexing per poter trasferire dati diversi sugli stessi pin, cambiandone di volta in volta utilizzo in base ai segnali di controllo. Infatti i primi 16 dei pin riservati alla generazione dell’indirizzo finirono per essere impiegati anche per trasferire i dati.
Giudicare simile scelte come “perversione” sarebbe, però, eccessivo. Il multiplexing era una comoda ed economica pratica abbastanza diffusa, e quando lo spazio è tiranno la differenza fra la soluzione elegante e quella di compromesso può essere la stessa che c’è fra una soluzione che arriva oppure no sul mercato.
Dunque rimane il limite dei 20 pin che portano al già citato MB di memoria indirizzabile. 20 bit, però, è un numero “strano” per un processore a 16 bit, che è dotato, appunto, di registri a 16 bit. In che modo, quindi, viene calcolato l’indirizzo a 20 bit? Lo schema seguente mostra l’operazione eseguita dall’8086:

La soluzione fu rappresentata dall’utilizzo di speciali registri chiamati segmenti che portano in sé quei 4 bit necessari per arrivare ai fatidici 20 a disposizione.

I registri di segmento erano ovviamente a 16 bit, e in numero di quattro per la precisione: CS per indirizzare il codice (assieme al registro IP “puntava” all’istruzione correntemente eseguita), SS per lo stack (col registro SP “puntava” alla locazione di memoria a 16 bit libera per memorizzare un valore, mentre col registro BP era possibile accedere ai dati memorizzati nello stack), DS per i dati (accessibili in vari modi; in particolare coi registri indice BX, SI e DI) e infine ES quale segmento “extra” per accedere ad altri dati (alcune istruzioni, inoltre, utilizzavano implicitamente ES e DI).
Un esempio chiarirà in che modo saltano fuori i 4 bit per comporre l’indirizzo a 20 bit. Supponiamo di voler accedere alla locazione di memoria che ha indirizzo (a 20 bit ovviamente) 0xB8000 in formato esadecimale (qualcuno magari ricorderà che rappresenta l’inizio della memoria della gloriosa scheda video CGA). Possiamo caricare in DS il valore 0xB800 e in BX il valore 0x0000.
Per arrivare all’indirizzo voluto l’8086 procede in questo: moltiplica DS per 16 (che, in gergo informatico, equivale a shiftare DS a sinistra di 4 posti; ed equivale anche ad aggiungere uno 0 a destra a un numero esadecimale) e gli somma il valore del registro BX.

Nello specifico, quindi, avremo: 0xB800 * 16 + 0x0000 = 0xB8000 + 0x0000 = 0xB8000, che è l’indirizzo desiderato. Il valore a 16 bit prelevato dal registro BX per formare l’indirizzo viene chiamato offset, per cui un indirizzo viene definito sempre dall’accoppiata segmento + offset, e in genere rappresentato in questo modo: B800:0000 (coi due punti a separare i due valori).
Ma quella di porre DS = 0xB800 e BX = 0x0000 è soltanto una scelta e non un obbligo. E’ possibile, infatti, trovare altre coppie di valori che generano lo stesso indirizzo. Ad esempio B000:8000 rappresenta esattamente la stessa cosa: 0xB000 * 16 + 0x8000 = 0xB0000 + 0x8000 = 0xB8000 (il tutto sempre in esadecimale). E così via, le combinazioni possibili non si ottengono soltanto giocando con le cifre B e 8.
Quindi possiamo dire che una coppia segmento:offset non rappresenta in maniera univoca un indirizzo. Ciò porta a risultati alquanto bizzarri. Dalla formuletta di cui sopra si potrebbe, infatti, pensare che almeno l’indirizzo 0x00000 sia, matematica alla mano, univoco in quanto l’unica coppia che può generarlo è 0000:0000.
In realtà anche FFFF:0010 genera 0x00000, e il perché è presto detto: 0xFFFF * 16 + 0x0010 = 0xFFFF0 + 0x0010 = 0x100000 che… è un indirizzo a 21 bit! Poiché l’8086 è in grado di riportare soltanto i primi 20 bit, il 21esimo viene eliminato dal calcolo, e il risultato finale diventa, quindi, 0x00000.
Quello che sembra un comportamento poco sensato e ancor meno utile, in realtà venne sfruttato dal BIOS per poter accedere alle prime locazioni di memoria del PC (dov’erano memorizzate importante informazioni sul sistema). Il BIOS dei primi PC risiedeva negli ultimi 8KB di memoria, all’indirizzo 0xFE000. Quindi il registro CS poteva esser caricato col valore 0xFE00, e per accedere all’indirizzo 0x00000 (e superiori) sarebbe stato sufficiente usare come offset 0x2000 (e superiori).
E’ abbastanza perverso? Per chi ha usato microprocessori come il Motorola 68000, col suo indirizzamento perfettamente lineare, lo era sicuramente; nonché fonte di disperazione.
Personalmente continuo a non capire perché Intel non abbia preferito una soluzione molto più semplice, cioé quella di utilizzare i segmenti per memorizzare i 16 bit più significativi dell’indirizzo finale che sarebbe stato a 32 bit (con tutti i vantaggi che si possono immaginare: ben 4GB di memoria indirizzabili sulla carta).
Vista la limitazione dei 20 pin per l’indirizzo, sarebbe bastato “tagliare via” i 12 bit più alti, senza precludere un aumento dello spazio indirizzabile con future versioni con più pin del chip. Ma non solo: non sarebbe stato neppure necessario far uso di un circuito sommatore per effettuare il calcolo dell’indirizzo precedentemente illustrato… risparmiando dei (preziosi, all’epoca) transistor!
Chissà cosa sarà passato nella mente degli ingegneri di Intel che si sono inventati questo meccanismo così contorto. Rimarrà sicuramente un’altra delle misteriose “stravaganze” dell’informatica…

47 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
    Ilruz
     scrive: 

    “Come capita tante volte, nel mercato non s’impone il prodotto migliore, ma quello che si riesce a vendere meglio”

    Capita praticamente il 100% delle volte – una delle regole auree del marketing e che il prodotto piu’ diffuso non e’ quello migliore, ma *quello che e’ stato venduto meglio*: attenzione! non “quello che si vende meglio”!

  • # 2
    Cesare Di Mauro
     scrive: 

    Grazie per la correzione. Come avrai ben capito, di marketing sono diciamo… a digiuno. :D

  • # 3
    v1
     scrive: 

    ma adesso è cambiato tutto no? quando si dice che un processore è a 64bit non ci si riferisce proprio a questo?
    è ancora necessario sommare l’indirizzo di memoria a questo offset?

  • # 4
    Ilruz
     scrive: 

    Percarita’Cesare, non e’ una correzione :D e’ una precisazione, leggo i tuoi articoli sempre avidamente, e in genere piu’ di una volta, proprio per capirli meglio – il breve spazio a disposizione vi costringe a dei sunti funambolici, e a volte forzosamente ermetici.

    anyway, se non si fosse capito io ODIO il marketing, ma “Se conosci te stesso e conosci il tuo nemico, non dovrai mai temere la sconfitta” (Sun Tzu). Economia, Guerra e condividono molte strategie, e il marketing come la propaganda sono dei “mali necessari” per vincere una battaglia o migliorare il fatturato.

    Il processore 8086 e’ tutt’ora presente in molte componenti dello shuttle; tanto che la nasa ha serie difficolta’ di approvvigionamento – ed e’ il processore sul quale sono *nato* informaticamente parlando: vedere come hai illustrato il calcolo dell’indirizzo a 20 bit mi portato indietro per un attimo di 20 anni circa. Sigh.

  • # 5
    Riccardo C. [Gibbo]
     scrive: 

    Interessante… mi ricordavo qualcosa di vago dall’introduzione fatta dal prof di sistemi qualche anno fa, ma allora capii quel che bastava per prendere il mio bel 6 in laboratorio :-D

    In effetti l’unico modo di definire scelte del genere mi sembra “stravagante” :-P

  • # 6
    Kersal
     scrive: 

    Un sacco di tempo fa lessi un libro che parlava della nascita dell’8086 e del perchè della somma dell’Offset. Non ricordo bene il libro nè il titolo, tuttavia ricordo che non fu progettato così bensì si trasformò in questo. In pratica il progetto iniziale era diverso e mirava ad avere un sistema lineare ma per problemi di tempo, in quanto dovevano consegnare il prodotto, non ebbero il tempo di ristrutturare il tutto proponendosi di farlo più avanti…

  • # 7
    massimo m.
     scrive: 

    se e’ per questo l’8088 e’ ancora peggio.
    e ovviamente ibm scelse l’8088 per risparmiare.

    comunque se c’era veramente una ragione per quell’idea offset+indirizzo (gia’ all’itis mi chiedevo il perche’ di sta cosa, quando cpu simili avevano l’indirizzamento lineare), era veramente una cosa dettata puramente dal risparmio.
    il risparmio intel, ovviamente, non certo quello degli sviluppatori.
    sinceramente non sono esperto di calcoli di prezzi sulle pcb, ma davvero costa tanto meno mettere meno linee di indirizzo accollandosi poi in cpu tutti i calcoli di offset+vari ed eventuali? credo sia solo una scelta fatta per raschiare il fondo del barile. anche se costasse qualcosa in piu’, la semplicita’ di sviluppo ripagherebbe la cosa.
    forse motorola non ha saputo “vendere” altrettanto bene le sue cpu.

  • # 8
    mario
     scrive: 

    Non vorrei sbagliarmi ma se non erro l’Ibm scelse i processori intel perchè all’epoca motorola fu una delle prime ditte ad avere uno stabilimento in giappone e l’ibm temeva una legge che imponeva un contingentamento della merce proveniente da quel paese.

  • # 9
    Cesare Di Mauro
     scrive: 

    @v1: no, i processori x86 attuali sono ancora (quasi) perfettamente compatibili col vecchio 8086 quando funzionano in modalità reale (tranquillo: ne riparleremo in futuro).
    Un processore a 64 bit potrebbe funzionare anche con la segmentazione, ma… avere già indirizzi a 64 bit è più che sufficiente per accedere alla memoria.

    @Ilruz: non ti preoccupare. Ti ringrazio per le precisazioni perché mi permettono di arricchire il mio bagaglio culturale. :)
    Sì, la NASA qualche tempo fa si aggiudicò a un’asta una quantità di 8086 proprio perché li usa per lo Shuttle, e non le conviene riprogettare i sistemi con un processore più moderno ma, soprattutto, di ben più facile reperibilità.

    @Kersal e massimo m.: francamente mi sembra molto strano che si sia partiti da un sistema lineare idealmente, per poi finire “per necessità” a uno con una segmentazione così astrusa. Lo dicevo anche nell’articolo: un sistema lineare sul modello che auspicavo è molto più semplice, economico e performante da implementare.
    Semplice perché l’indirizzo di memoria si ottiene semplicemente “accostando” segmento e offset (che occuperebbero rispettivamente i 16 bit più alti e più bassi dell’indirizzo finale a 32 bit).
    Economico proprio perché un tale sistema farebbe a meno del sommatore, che invece è assolutamente necessario nel caso del modello dei segmenti “overlapped” che purtroppo ha scelto Intel.
    Performante perché introdurre un sommatore nella pipeline di un processore equivale ad allungare il tempo di calcolo, e a produrre pure chip che arrivano a frequenze meno elevate (perché nella circuiteria viene introdotto un ritardo causato dal calcolo da effettuare, appunto). Cosa che non succederebbe con un modello lineare.
    Ecco perché l’articolo parla di “bizzarie” e “stravaganze”: non ci sono motivi razionali per cui Intel avrebbe dovuto optare per questa soluzione così contorta.

    @massimo m.: vero. E’ peggio, ma… è anche più economico, visto che il package è più piccolo. Purtroppo all’epoca il costo di un package era rilevante.

    @mario: è strano, perché comunque Motorola non è un’azienda giapponese, ma americana e con stabilimenti negli USA, appunto.

  • # 10
    Alberto
     scrive: 

    L’8080 è una versione castrata del 8086 ed è uscito dopo il suo fratello normodotato.
    IBM lo scelse non per risparmiare ma perché temeva (sigh) che un processore a 16 bit potesse fare concorrenza ai suoi mainframe.

  • # 11
    Cesare Di Mauro
     scrive: 

    Immagino ti riferissi all’8088 che ha citato anche massimo m., perché l’8080 è un processore a 8 bit di cui abbiamo già parlato tempo fa (qui http://www.appuntidigitali.it/2817/intel-8080-inizia-lera-dei-processori-a-8-bit/ esattamente). ;)

    Comunque si tratterebbe di una scelta protezionista sensata da parte di IBM, ma l’8088 e 8086 rimanevano in ogni caso compatibili a livello di codice. Per cautelarsi sarebbe stato, quindi, più saggio prendere un considerazione un vero processore a 8 bit. Il tutto IMHO, ovviamnete.

  • # 12
    blackshard
     scrive: 

    ES:DI, quanti ricordi!
    Dopotutto avere segmenti e offset da 64k non è poi tutto male. Alla fine se uno deve scorrere all’interno dello stesso segmento se ha registri a 16 bit si risparmia qualche conto nel momento in cui deve accedere alla memoria.
    Di certo la scelta sarà stata dettata da problemi economici, visto che è abbastanza infelice simulare 20 bit usando due registri da 16 bit. Poi alla fine abbiamo dovuto aspettare i 386 per avere finalmente una modalità flat realmente fruibile. :/

  • # 13
    Filippo1974
     scrive: 

    Ho trovato un’interessante interpretazione dei vantaggi dell’indirizzamento a segmenti dell’8086. Piuttosto tecnico, ma potrebbe essere uno spunto.

    http://wiki.answers.com/Q/What_are_the_advantages_of_using_segment_registers_in_the_8086_microprocessor

    Ciao
    Filippo

  • # 14
    nico
     scrive: 

    Se non erro Ibm scelse 8088 perchè le periferiche ad 16 bit costavano più di quelle a 8 che erano più diffuse.

    Bye
    Nico

  • # 15
    Banjo
     scrive: 

    Aaaah mi ricordo le lotte per portare quanta più roba in “memoria alta”, altrimenti non si riusciva a caricare i giochi…

  • # 16
    Banjo
     scrive: 

    Ah già ma la cosa riguardava 80286, 80386 o 80486.. sorry!

  • # 17
    Cesare Di Mauro
     scrive: 

    @blackshard: il problema è che quando accedi alla memoria, devi comunque prendere 2 quantità a 16 bit e combinarle. :)

    @Filippo1974: ho letto il link, ma francamente non vedo vantaggi. Anche la paginazione permette di allocare codice e dati partendo da un indirizzo virtuale base 0 e, quindi, garantendo la rilocabilità del codice e dei dati.

    Inoltre molti processori hanno istruzioni di salto o modalità d’indirizzamento della memoria relative al PC, per cui anche qui si ottengono gli stessi obiettivi senza far ricorso alla segmentazione.

    Ciò non toglie che la segmentazione abbia anche dei vantaggi, ma di questo ho intenzione di parlerne meglio in un futuro articolo. :D

    @nico: più che altro un sistema a 16 bit complessivamente era più costoso da produrre rispetto a uno a 8 bit.

    @Banjo: sì, e tra l’altro si poteva sfruttare un “bug” di quei microprocessori per poter accedere a 64KB – 16 byte di memoria in più rispetto al MB disponibile normalmente. Anche di questo ne parlerò meglio in un altro articolo che affronta alcune affascinanti stranezze (ma molto utili) dell’architettura x86. :)

  • # 18
    godson
     scrive: 

    il 68000 ha venduto BENISSIMO.
    ma che cavolo scrivete su sti forum, documentarsi prego.

  • # 19
    Cesare Di Mauro
     scrive: 

    Primo non è un forum, ma un blog tecnologico.
    Secondo, dove hai letto che il 68000 non avrebbe venduto bene? Nemmeno nei commenti c’è nulla del genere.

    Non è che hai alzato il gomito un po’ di più questa sera? :D

  • # 20
    Massimiliano
     scrive: 

    Due motivazioni possibili (e probabilmente entrambe vere):
    A) Quando è stato progettato l’8086, la memoria era costosa e ne veniva usata poca alla volta. I primi PC spesso non avevano neanche 640k ma solo 512k. Se i progettisti dell’8086 avessero considerato 640k un fattore limitante avrebbero sempre potuto spostare BIOS, memoria video e altre periferiche più vicine al limite dell’1mb, liberando più di 640k. Invece 640k erano molti, pure troppi quella volta (ricordatevi, per fare un paragone, che i dischetti erano da 360kb e talvolta anche meno!)
    B) Un modello 16bits+16bits come proposto avrebbe sprecato troppa memoria. Questo perché la “granularità” sarebbe stata di 64k invece che di 16 bytes. Mi spiego: l’architettura era a 16 bits, quindi i programmi usavano “blocchi” da max 64kbytes (i famosi segmenti), usando i registri selettori (CS, DS ecc) per accedere a più blocchi da 64kbytes. Avendo i “segmenti” sovrapposti a “passi” da 16 bytes si ha che la memoria può essere usata al massimo. Se per esempio il programma occupa 16kbytes di codice, nell’8086 il segmento di dati può iniziare subito dopo i 16kbytes di codice (tecnicamente ci sono al max 15 bytes sprecati). In un modello 16+16 bits (“finto 32 bits”) il segmento del codice avrebbe in ogni caso occupato 64kbytes (questo perché i programmi ovviamente suppongono che quando ricevono un segmento dal SO questo è libero e non è gia “mezzo mangiucchiato”). Questa cosa avrebbe reso impossibile l’avere più programmi assieme in memoria. Ogni programma avrebbe occupato come minimo un intero segmento da 64kbytes, e questo se fosse stato costruito per avere codice, dati e stack nello stesso segmento. Se pensate che un 8086 avesse un solo programma alla volta in memoria, beh… ricredetevi. Anche quella volta c’erano i TSR (Terminate and Stay Resident), simili ai demoni dello Unix o ai programmi che se ne stanno nella Tray Area del Windows (tecnicamente a entrambe… potevano essere TSR che davano “servizi” oppure anche interi programmi, come il Sidekick, che era un’agena più utilities varie). Inoltre anche se pochi c’erano anche drivers del SO che erano programmi a tutti gli effetti (i files .sys).

  • # 21
    Cesare Di Mauro
     scrive: 

    a) I primi PC addirittura avevano soltanto 64KB. :D Comunque i progettisti avrebbero potuto scegliere in maniera più oculata lo spazio d’indirizzamento per le periferiche.
    Purtroppo è un problema comune a molti computer (anche per l’Amiga non m’è mai piaciuta l’organizzazione per la memoria).

    b) Vero. Specialmente su un’architettura esclusivamente segmentata, è necessario un compromesso fra lo spazio di memoria indirizzabile e la granularità (per chi non lo sapesse, s’intende la minima quantità di memoria allocabile a fronte di una richiesta).

    Altre CPU a 16 bit (di cui parlerò a breve) al posto dei segmenti usavano un concetto simile, quello dei banchi di memoria (facendo uso di un apposito registro a 8 bit allo scopo).
    In questo caso però la memoria era indirizzata linearmente, come il modello che avevo in mente, e portandosi dietro quindi dei problemi legati alla granularità troppo elevata (64KB per banco) che hai giustamente citato.

    Il problema, però, si può risolvere in due modi:
    – utilizzare dei memory pool per la gestione delle richieste di allocazione della memoria, cercando quindi di “condividere” i segmenti ove possibile;
    – sfruttare un rilocatore per “patchare” gli indirizzi.

    E’ chiaro che lasciando i segmenti “overlapped” e con una granularità di soli 16 byte, il problema è risolto senza particolari dispendi di risorse (16 byte sono pochi effettivamente) e senza far ricorso a politiche da implementare a livello di s.o. (le due soluzioni che ho proposto poco sopra).

    Personalmente, però, avrei preferito un sistema con una granularità più elevata, ma una maggior quantità di memoria indirizzabile.

  • # 22
    Quando i 16 bit stavano stretti: Zilog Z8000 - Appunti Digitali
     scrive: 

    […] vedere con la notevole complessità della sezione di decodifica di un microprocessore come l’8086 di Intel, che nelle versioni moderne occupa una considerevole area del chip e incide […]

  • # 23
    Nel cuore del SuperNintendo: WDC 65816 - Appunti Digitali
     scrive: 

    […] opcode come prefissi per estenderne il numero, similmente a quanto fatto da Intel con l’8086 e Zilog con lo […]

  • # 24
    Una (vecchia) finestra su Symbian - Appunti Digitali
     scrive: 

    […] che faceva girare il DOS grazie a IBeM (il cui nome è tutto un programma), il primo emulatore 8086. Meraviglia che si ripeté quando arrivò l’emulatore Commodore 64 dell’arcinota […]

  • # 25
    Intel 80286: fra protezione della memoria e… call gate! - Appunti Digitali
     scrive: 

    […] (diventati, appunto, selettori) per l’accesso alla memoria (ho già parlato di segmentazione in precedenza, quando ho introdotto l’8086, per cui non mi soffermerò sull’argomento), che hanno […]

  • # 26
    marco parri
     scrive: 

    tutto molto bello ma un po povero di illustrazioni sulla questione della segmentazione

  • # 27
    Cesare Di Mauro
     scrive: 

    Se ti può essere utile, ho affrontanto l’argomento in un successivo articolo: http://www.appuntidigitali.it/3381/intel-80286-fra-protezione-della-memoria-e-call-gate/

    Comunque l’articolo descrive in maniera precisa il meccanismo, fornendo anche degli esempi. Se qualcosa non dovesse essere ancora chiaro, chiedi pure e cercherò di aggiungere qualche altra informazione, dettagli, o esempio.

  • # 28
    Sinclair PC 200: il PC travestito da Amiga - Appunti Digitali
     scrive: 

    […] cotanta scocca, non pulsava tuttavia un Motorola 68000, magari corredato di custom chips, ma un 8086 a 8Mhz, accompagnato da una miserrima CGA/MDA, suono affidato al classico beeper, 512KB di RAM e […]

  • # 29
    National Semiconductor 16032: il perfetto (e sconosciuto) CISC a 32 bit? - Appunti Digitali
     scrive: 

    […] è stata sempre dominio di due soli nomi: Intel e Motorola, che con le rispettive famiglie 80×86 e 68×00 si sono contese il mercato dei computer “casalinghi” (e non) per una […]

  • # 30
    Dalla collaborazione di Apple e Acorn arriva l’evoluzione degli ARM - Appunti Digitali
     scrive: 

    […] contrasto con la linea seguita da Intel con la sua famosissima x86 è evidente, visto che tutt’oggi viene mantenuta piena compatibilità con l’arcivecchia […]

  • # 31
    rmio
     scrive: 

    Salve a tutti,
    Volevo condividere la mia meraviglia per l’accanimento contro la segmentazione in modalità reale in quanto essa è prima di tutto un primitivo sistema di aliasing della memoria (uno stesso indirizzo può essere accesso in 4096 modi diversi, con la linea A20 mascherata).
    Inoltre permette di scrivere agevolmente codice PIC, basta che vi diate uno sguardo alle specifiche degli eseguibili MZ e a come funziona la loro rilocazione.
    Certo il base address dei descrittori (siamo in modalità protetta) è effettivamente piuttosto inutile data la possibilità di usare la paginazione ma questo è un altro discorso.
    Vorrei anche precisare che l’utilizzo della segmentazione non è così difficile come sembra, per ottenere un’enumerazione lineare degli indirizzi a partire da un indirizzo SSSS:OOOO basta incrementare OOOO e ogni volta che wrappa a 0 aggiungere 1000h al registro segmento. Se si è capita la segmentazione è facile rendersi conto di come sia semplice questo meccanismo ;)

  • # 32
    Cesare Di Mauro
     scrive: 

    Non è difficile (si tratta di sfruttare una delle tante configurazioni ottenibili dalla combinazione di segmenti e registri), ma… bizzarra, come dicevo.

    Più che di aliasing, comunque, parlerei di granularità di accesso alla memoria, come ho discusso anche nei commenti.

    E’ un modello che personalmente non mi piace, e penso sia chiaro. Non credo che ci sia da meravigliarsi se delle persone hanno dei “gusti” o idee diverse. ;)

    Ad esempio, e ancora una volta al contrario di ciò che pensi, il base address nei descrittori della modalità protetta lo trovo estremamente utile, anche avendo abilitata la paginazione della memoria.

    Detto in altri termini, la paginazione non porta necessariamente ad escludere la segmentazione per sopravvenuta “inutilità”. ;)

    Di questo ne parlerò più approfonditamente in futuro articolo. Abbastanza remoto comunque, perché la scaletta che ho è già stracolma di argomenti; ma mi segno tutto, e prima o poi toccherà anche questo che è decisamente sottovalutato causa assuefazione ai meccanismi della paginazione. :D

  • # 33
    E’ giusto pagare un programmatore? - Appunti Digitali
     scrive: 

    […] non sempre possiamo fare tutto ciò che vorremmo. Costretti a seguire una pallosissima lezione sui segmenti dell’8086, quando con la testa vaneggiamo sui favolosi chip custom […]

  • # 34
    Riflessioni sull’architettura ARM - Appunti Digitali
     scrive: 

    […] proceduto in maniera diametralmente opposta. Infatti queste hanno sempre permesso, fin dall’8086, l’accesso a dati disallineati (che hanno, quindi, richiesto uno o due accessi alla memoria), […]

  • # 35
    Flash su ARM, la caduta di un dogma - Appunti Digitali
     scrive: 

    […] con cui da qualche anno a questa parte, Intel risponde a chi solleva dubbi sull’idoneità di un’architettura evolutasi in maniera incrementale a partire dai lontani anni ‘70, a rappresentare la risposta […]

  • # 36
    Grid Compass, il computer venuto dallo spazio - Appunti Digitali
     scrive: 

    […] Grid Compass offre alcuni spunti di grande interesse. Al cuore del sistema troviamo una CPU Intel 8086 con FPU 8087, servite da 256 KB di RAM espandibile fino a 512. La funzione di memorizzazione di […]

  • # 37
    Mario
     scrive: 

    Scusate vorrei chiarire dei concetti in quanto mi sono avvicinato da poco al linguaggio assembly.
    1) in modalità real mode la capacità di indirizzamento è 2 alla 20 quindi sono possibili “diciamo” 1048576 indirizzi. La memoria invece è divisa in 65536 segmenti di 64KB ciascuna, quindi la quantità di memoria gestibile di quanto é? 65536*64kb? Grazie

  • # 38
    Cesare Di Mauro (Autore del post)
     scrive: 

    No, perché anche se i segmenti sono di 64KB l’uno, in realtà la memoria è, in parte, condivisa.

    Esempio. Il segmento $0000 si estende da $00000 a $0FFFF. Il segmento $0001 si estende da $00010 a $1000F. Quindi questi due segmenti condividono 64KB – 16 byte di memoria (cioè da $00010 a $0FFFF).

  • # 39
    Mario
     scrive: 

    Quindi la memoria risulterebbe divisa in 16 segmenti di 64 kb massimo. Ma quei 64 kb sono suddivisi in altre parti individuabili dall’offset giusto? Se ho capito la parte più piccola di un segmento dovrebbe essere di un byte? Forse inizio a capire qualcosa. Grazie sei gentilissimo

  • # 40
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sì, diciamo che basterebbero 16 segmenti per indirizzare tutta la memoria (1MB).

    Tutto il resto è corretto.

  • # 41
    Mario
     scrive: 

    Quindi perdonami, un segmento va da una grandezza minima di 16 byte ad una massima di 64 kbyte. Forse l’informazione più piccola contenibile in memoria è di un byte. Cerco di approfondire il tutto al massimo in modo tale che mi sia tutto chiaro per poter andare avanti. Sto studiando il linguaggio PC assembly di Paul Carter. Però tu sopra parli di memoria condivisa: cosa significa più esattamente? Lo so sono banalità per te ma devo trovare il coraggio di chiederle a qualcuno per comprendere :-) GRAZIE

  • # 42
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sì, un segmento va da 16 a 64KB, a passi di 16 byte. L’informazione più piccola rimane sempre il byte, indirizzabile tramite la coppia segmento:offset.

    La memoria è condivisa nel senso che segmenti diversi ma “vicini” possono “coprire” la medesima zona di memoria, come puoi vedere dal mio esempio precedente.

    Giusto per farne un altro, se prendiamo il byte all’indirizzo $A0000, questo può essere indirizzabile sia tramite la coppia segmento:offset $A000:0000, che tramite la coppia $B800:8000. Ma esistono moltissime altre coppie di segmenti e offset che permettono di indirizzare quel byte.

  • # 43
    Mario
     scrive: 

    Puoi indirizzarmi per approfondire la memoria condivisa dei segmenti? Il perchè è stata introdotta e come funziona? Grazie

  • # 44
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ne parlo già nell’articolo. Comunque qualcosa si trova su Wikipedia: http://en.wikipedia.org/wiki/8086#Segmentation

    Se non dovesse bastare, dovresti leggerti i manuali di Intel.

  • # 45
    Mario
     scrive: 

    Perdonami ma la curiosità è troppo forte: mi sfugge come nell’8086 avvenga in controllo che impedisce a due indirizzi fisici di accedere in scrittura alla stessa locazione di memoria. Il compilatore fa in modo che i registri nel caso di un programma scrivano in determinati segmenti ma chi è che tiene traccia della segmentazione della memoria? Grazie

  • # 46
    Mario
     scrive: 

    Forse è la famigerata Segment Table che tiene traccia della memoria già segmentata!

  • # 47
    Cesare Di Mauro (Autore del post)
     scrive: 

    Con l’8086 non c’è nessun controllo del genere: ogni segmento, se si sovrappone con altri, può tranquillamente scriverci sopra.

    Discorso diverso con la modalità protetta. In questo caso i segmenti non si chiamano selettori e qui entrano in gioco dei meccanismi di protezione.

    Comunque il discorso è troppo lungo per essere trattato qui. Intanto puoi leggerti l’articolo in cui parlo del 286 e della sua modalità protetta: magari ti sarà utile come infarinatura per affrontare poi più approfonditamente l’argomento, se t’interessa.

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.