La memoria virtuale Tecniche di gestione della memoria nella famiglia x86 e in Os/2

Transcript

1 La memoria virtuale Tecniche di gestione della memoria nella famiglia x86 e in Os/2 A cura di Antonio Arreghini

2 Indice Generale Premesse e cenni al funzionamento di un programma...3 Capitolo 1: Tecniche per la gestione della memoria : La memoria reale : La segmentazione : La paginazione : La segmentazione con paginazione...11 Capitolo 2: La gestione della memoria sulle architetture x : La memoria nell' : La memoria nell' : La memoria nell' : La modalità reale : La modalità protetta : La memoria nell' p : La paginazione : La segmentazione : La paginazione con segmentazione : La modalità V Capitolo 3: La gestione della memoria in Os/ : Os/2 a 16 bit : Os/2 a 32 bit : I 3 formati di indirizzi : Primo livello di traduzione in indirizzo lineare : Le arene di sistema : La Paginazione a 2 livelli : La gestione delle pagine fisiche e virtuali : La gestione dei moduli : Il file di pagina : L'High Memory Support...28

3 Premesse e cenni al funzionamento di un programma Questo documento si propone di illustrare il funzionamento dei sistemi di indirizzamento a memoria virtuale, con particolare attenzione alle implementazioni delle varie tecniche sui processori x86 e a come Os/2 sfrutta queste possibilità. In ogni capitolo, per prima cosa vengono spiegati i concetti generali, quindi vengono forniti maggiori chiarimenti di natura tecnica. Il lettore non interessato ai «tecnicismi» può tranquillamente saltare dette parti senza pregiudicare la comprensione grossolana dell'argomento. Per agevolare colore che non conoscono neanche in parte le nozioni che in questo documento vengono date per scontate, ho voluto scrivere le seguenti (ahimè tutt'altro che esaurienti) righe per indirizzare meglio la comprensione di un argomento piuttosto complesso. Un programma è una sequenza ordinata di istruzioni che viene caricata nella memoria primaria (la RAM) e viene quindi ordinatamente eseguita dal processore. Il programma al suo interno contiene istruzioni (che sono i comandi che il processore deve eseguire, ad esempio somma, sottrai, carica un dato...) e operandi. Queste due categorie di dati sono apparentemente indistinguibili dall'esterno, infatti si tratta semplicemente di numeri binari. Come vedremo è il processore (o meglio il compilatore) ad operare la distinzione: in pratica il processore legge il programma dall'inizio supponendo che il primo dato sia un'istruzione, poi procede con i successivi dati sempre supponendo che siano istruzioni... se si arriva ad un blocco di operandi, questo dovrà essere preceduto da un'apposita istruzione che dica alla CPU l'indirizzo della successiva istruzione. La memoria è quindi una sorta di pila di contenitori di numeri binari a 8 bit (ossia celle da 1 byte). Ogni locazione di memoria (ossia ogni «celletta di memoria») è identificata univocamente da un indirizzo, che a sua volta ovviamente è un numero. I dispositivi fisici di controllo della memoria permettono di recuperare dati o salvarli in qualunque posizione si trovino (e per questo la memoria è detta ad accesso CASUALE, in quanto i tempi di accesso non dipendono dalla posizione che il dato occupa). Il processore colloquia con la memoria tramite tre bus distinti o «multiplexati» (ossia «fusi» nelle stesse piste) a seconda del processore stesso: questi sono il data bus, che permette di scambiare i dati puri, l'address bus, che permette al processore di specificare su quale locazione di memoria operare e il control bus, che permette di sincronizzare i due dispositivi, di richiedere dati, di specificare se si vogliono effettuare letture o scritture, ecc... Le istruzioni si classificano in tre specie fondamentali: Istruzioni di operazioni in memoria: il processore prima di poter eseguire qualunque operazione deve caricare al suo interno (in cellette chiamate registri) gli operandi presenti in memoria. Ecco quindi che servono determinate istruzioni per specificare quali dati caricare prima di ogni operazione matematica. Queste istruzioni servono anche per movimentare dati da un posizione all'altra, oppure per caricarli o inviarli alle periferiche (dischi fissi, scanner, stampanti, schede di rete, modem, ecc...). A questo proposito va infatti detto che tali dispositivi esterni dispongono di un proprio indirizzo di memoria. Istruzioni matematiche: prevedono operazioni logiche e aritmetiche sui dati precaricati nei registri del processore; se l'operazione viene compiuta su numeri interni si utilizza l'unità denominata ALU (Arithmetic Logic Unit) se su numeri in virgola mobile (numeri reali) entra in gioco l'unità FPU (Floating Point Unit). Istruzioni di salto condizionato: come detto prima in teoria l'istruzione successiva a quella in esecuzione si trova in memoria all'indirizzo immediatamente seguente all'istruzione corrente: c'è Memoria Virtuale Pag. 3

4 pertanto un «contatore di programma», il Program Counter, che viene incrementato al termine di ogni istruzione e il suo contenuto di fatto rappresenta l'indirizzo dell'istruzione da caricare; questo sistema tuttavia permette strutture di programmazione estremamente elementari. È stata quindi introdotta questa classe di istruzioni che consente di caricare un nuovo valore all'interno del program counter, di fatto effettuando un «salto». Tale salto può essere incondizionato (avviene sempre) oppure condizionato (avviene se si verificano certe situazioni, ad esempio se il contenuto di un certo registro è minore di 0). Si possono così implementare strutture di programmazione molto più complesse quali i cicli e le chiamate a funzione. La distinzione in queste 3 classi è netta solo in una architettura nota come «RISC» (Reduced Instruction Set Computer) che prevede istruzioni semplici e tutte della stessa lunghezza (ogni istruzione è lunga 16, 32 o 64 bit a seconda del parallelismo della macchina). I processori della famiglia Intel x86 (quelli su cui funziona Os/2) usano invece delle istruzioni più complesse (da questo il nome di CISC, Complex Instruction Set Computer) la cui lunghezza è variabile (da 1 a 17 byte) e la cui esecuzione prevede di «confondere» le prime due classi (ossia ci sono istruzioni matematiche che specificano gli operando direttamente in memoria). Quando si parla di programmi a 16 o a 32 bit si intende quella che è la dimensione della word standard che si adotta per quel programma: la word (detta anche parallelismo) è il numero di bit su cui il processore può lavorare in parallelo. Nella modalità a 16 bit numeri, dati e istruzioni (sui RISC) saranno in genere lunghi 2 bytes (16 bit); di conseguenza il program counter conterà a passi di 2 bytes alla volta. Il vantaggio di avere un computer a 32 bit piuttosto che uno a 16 è quello di poter lavorare con operandi più larghi su un tempo minore. Al giorno d'oggi quasi tutti i computer sono a 32 bit; i server di rete e i supercomputer sono generalmente a 64 bit. Memoria Virtuale Pag. 4

5 Capitolo 1 Tecniche per la gestione della memoria 1.1: La memoria reale Come visto la memoria è un contenitore di bytes: ciascuna cella ha un indirizzo univoco identificato da una variabile a lunghezza finita. Questo vuol dire che ogni processore riesce ad indirizzare solo una quantità finita di memoria. La tecnica più antica ed intuitiva di gestione della memoria, è nota come «memoria reale». In pratica è una non gestione della memoria, ossia gli indirizzi specificati nel programma corrispondono sempre ad indirizzi fisici di memoria. I sistemi operativi e gli hardware che permettono ai programmi di lavorare direttamente sulla memoria fisica sono molto antichi e molto semplici e quindi hanno a disposizione una quantità molto limitata di memoria fisica, tanto che la stragrande maggioranza dei programmi che riescono ad eseguire richiedono più spazio di quanto sia effettivamente presente all'interno del computer. Per fortuna accade che questa memoria ha una dimensione nota a priori e in genere sempre disponibile in toto (solo nei sistema più evoluti è possibile installare solo parte della memoria allocabile dal processore) per cui non è complicato escogitare una soluzione: il codice essenziale del programma viene caricato in una parte di memoria, i dati essenziali in un'altra area; è fondamentale che queste due sezioni riescano ad entrare completamente nella memoria disponibile (che in genere è la memoria totale installata, sottratta dello spazio usato dal sistema operativo). La parte del codice non essenziale viene invece caricata solo quando strettamente necessaria (ossia quando il programma deve eseguire quelle istruzioni); una volta terminata l'esecuzione di quel pezzo di codice e il medesimo non è più utile, i dati essenziali vengono salvati (o aggiornati) nella zona dei dati globali, quindi quel codice viene cancellato per lasciare il posto ad un'altra sezione a sua volta da caricare dal disco. L'area di memoria in cui avvengono questi processi di scambio è chiamata Overlay. Indirizzi crescenti Sistema operativo Dati programma Area di overlay Codice programma Overlay Overlay Overlay Memoria Disco fisso La struttura della memoria reale con overlay Questa tecnica ha più svantaggi che vantaggi: anzitutto il caricamento da memoria di secondo livello (il disco fisso) è decisamente lento, ma questo è uno svantaggio che non si può colmare in alcun modo se non aumentando la dimensione della memoria fisica (in questo caso il tempo di caricamento viene assorbito per intero all'inizio dell'esecuzione del programma che poi procede «fluido»). In secondo luogo il compito della gestione dell'overlay è interamente sotto il controllo del Memoria Virtuale Pag. 5

6 programma stesso, che deve monitorare quindi le risorse ed agire di conseguenza. In terzo luogo questo modello non si adatta bene alla multiprogrammazione, ossia a quella pratica che prevede il caricamento e l'esecuzione contemporanea di diversi programmi. Questi programmi ovviamente non verranno eseguiti contemporaneamente (essendo in genere la CPU una sola): il sistema operativo farà lavorare a turno per pochi millisecondi ciascuno di esso, dando l'impressione che i programmi avanzino parallelamente. Resta però il fatto che tutti i programmi sono effettivamente residenti in memoria; ancora peggio, ogni programma deve essere indipendente l'uno dall'altro. Quando si lavora in memoria reale i programmi al loro interno specificano direttamente gli indirizzi fisici per ogni locazione di memoria. Questo implica che più programmi possano richiedere l'uso della stessa locazione di memoria (ad esempio tutti iniziano in posizione 0000, hanno degli operandi in 0E01 e via dicendo). Una possibile soluzione è quella di salvare in un puntatore (ossia una variabile di memoria che contiene un indirizzo) l'indirizzo a cui inizia il programma e specificare al suo interno soltanto indirizzi relativi a questo: l'indirizzo della memoria fisica si ottiene perciò sommando al puntatore la posizione del codice da caricare relativa all'inizio del programma; questo indirizzo relativo prende il nome di offset. In realtà questa tecnica è piuttosto scomoda da implementare per il programmatore (che deve programmare tenendo conto di questo fatto), è decisamente più lenta (ogni indirizzamento necessita di una somma), non permette ai programmi di espandersi (infatti dopo la fine del proprio spazio può benissimo iniziare un nuovo programma) e specialmente non è sicura, infatti un indirizzo sbagliato può comportare la lettura (o peggio la scrittura) di una cella di memoria che appartiene ad un altro programma. In altre parole è inaccettabile. 1.2: La segmentazione Per compensare queste carenze del modello a memoria reale (che trova comunque spazio in vecchi sistemi monoprogrammati come il DOS) è nata la cosiddetta segmentazione. Gli indirizzi di un programma non si riferiscono più ad una locazione fisica nella memoria, ma ad una «locazione virtuale». In sostanza i programmi lavorano con una memoria «teorica» (chiamata memoria virtuale); la traduzione e la mappatura di questa memoria virtuale nella RAM del computer è un compito che spetta al sistema operativo ed al processore, liberando così definitivamente il programmatore dal gestire questa problematica (come invece non succedeva per l'overlay). Gli indirizzi vengono specificati come una coppia di due numeri: un selettore e un offset. Il primo identifica il «segmento» su cui si sta lavorando, il secondo indica la posizione all'interno del segmento stesso. Memoria Virtuale Pag. 6

7 Segmento 1 Indirizzi crescenti Segmento 2 Libera Segmento 3 Libera Memoria Un esempio di segmentazione L'implementazione di questa tecnica necessita di un hardware apposito che agevoli la traduzione di questi indirizzi virtuali in indirizzi fisici. In sostanza la CPU deve avere un'unità (chiamata MMU, Memory Management Unit) che all'interno deve contenere il puntatore ad un tabella dei segmenti: all'interno di questa sono presenti una serie di voci (entry) che descrivono tutti i segmenti presenti nel sistema. La traduzione procede automaticamente seguendo questa trafila: La MMU carica il selettore del segmento dall'indirizzo virtuale fornito dal programma La MMU conosce già l'indirizzo base della Segment Table (che identifica l'inizio della medesima) e gli somma il selettore trovando così la posizione (l'entry) nella tabella dei segmenti dove è descritto il segmento in questione Le informazioni del descrittore del segmento contengono l'indirizzo base del segmento cui viene sommato l'offset ottenendo finalmente l'effettivo indirizzo fisico. Tale procedimento è riassunto nella figura sottostante. Indirizzo base segment table B + S Indirizzo Virtuale Selettore Offset B Segment table O B+S S' + S'+O Indirizzo fisico Descrittore La traduzione secondo il sistema di segmentazione Memoria Virtuale Pag. 7

8 Un programmatore può a questo punto scrivere il codice di un programma su diversi segmenti; il bello è che quando un programma richiede al sistema operativo di creargli un segmento di una certa dimensione, il SO controlla se c'è tale spazio libero in memoria; in caso contrario lui automaticamente copia sul disco fisso uno o più segmenti, liberando spazio in memoria fisica; tutto ciò viene fatto all'insaputa del programma e del programmatore che quindi può dimenticarsi la fastidiosa gestione degli overlay e la «condivisione della memoria tra programmi» e concentrarsi esclusivamente sulla programmazione. Appena qualche programma richiederà un segmento che era stato copiato sul disco il SO provvederà a liberare lo spazio necessario in memoria (sempre copiando altri segmenti sul disco) e a ricaricare quello richiesto; questo sempre in modo totalmente trasparente all'utente. Ovviamente il lavoro di copia è piuttosto lungo e rallenta l'esecuzione, per cui la segmentazione prevede anche che sia installata una quantità di memoria fisica adeguata alle esigenze dei programmi che vengono eseguiti (per evitare di trascorrere la maggior parte del tempo a copiare segmenti e non ad eseguire i programmi). Un altro vantaggio della segmentazione è la protezione dei dati: la CPU automaticamente controlla se l'offset richiesto si trova all'interno del segmento oppure se un certo programma cerca di accedere a segmenti che non gli appartengono. Se queste condizioni pericolose si verificano la CPU notifica al sistema operativo l'errore; il programma viene quindi terminato prima che possa nuocere agli altri processi caricati in memoria. Purtroppo non sono tutte rose e fiori. Anzitutto bisogna considerare che i segmenti hanno dimensioni diverse; inserirli e toglierli dalla memoria provoca molta frammentazione, per cui si generano tanti «buchi» in memoria difficili da riutilizzare (spesso un segmento non riesce ad entrarci). Una soluzione potrebbe essere una ricompattazione periodica della memoria, ma è un'operazione lunga e costosa. Inoltre il SO deve possedere algoritmi relativamente complessi per sapere qual è la posizione migliore in cui caricare un certo segmento. Segmento 1 Segmento 2 Indirizzi crescenti Libera Segmento 3? Segmento 4 Libera Memoria Disco fisso Questo è un esempio di frammentazione: ci sarebbe sufficiente memoria libera per caricare il segmento 4, ma non essendo continua non è possibile caricarlo se non ricompattando il segmento 3 oppure swappandolo su disco Memoria Virtuale Pag. 8

9 Un altro svantaggio è che il copiare su disco segmenti molto lunghi richiede molto tempo; a questo proposito c'è da dire che ai programmatori non piace molto lavorare con questi segmenti, per cui cercano di far stare tutto il programma su un singolo segmento molto grande (e quindi scomodo da copiare sul disco!); infatti quello che succede all'interno di ogni segmento è che l'offset rappresenta un indirizzo lineare: c'è a disposizione l'indirizzo 0000, il 0001 e così via per cui sono lecite operazioni matematiche sui puntatori stessi, pratica che può sembrare poco ortodossa se fatta in un linguaggio ad alto livello, ma è indubbiamente comoda da utilizzare (e utilizzata moltissimo nella realtà). Un ulteriore svantaggio della segmentazione risiede nella dimensione massima del segmento: questa è necessariamente limitata dalla dimensione della memoria fisica; se uno ha 2 Mb di memoria fisica non può caricare (neanche copiando sul disco tutti gli altri segmenti) un segmento di 3Mb! In sostanza, la segmentazione porta molti vantaggi ma non risolve tutti i problemi. 1.3: La paginazione Una soluzione a parte dei problemi si trova nella tecnica chiamata paginazione. Si tratta di dividere lo spazio di indirizzamento lineare (è così chiamato l'insieme di tutti gli indirizzi di memoria virtuale, lineare perché gli indirizzi sono contigui) in tante pagine di memoria; ognuna di queste è piuttosto piccola e la dimensione è prefissata ed immodificabile. Ogni pagina rappresenta la minima quantità allocabile dal sistema operativo. Questo sistema permette di ridurre la frammentazione perché non ci sono «buchi troppo stretti» nei quali non si possa caricare un'altra pagina. Per caricare una pagina in una memoria piena basta scaricarne esattamente una sola! Inoltre in questo modo è possibile che un programma sia più grande dell'effettiva dimensione fisica della memoria, questo perché eventuali eccedenze dello stesso programma vengono compensate semplicemente copiando su files parte di questo. Indirizzi crescenti Memoria Disco fisso Il sistema di paginazione evita il problema della frammentazione: ogni pagina swappata entra esattamente in ogni pagina libero in memoria Memoria Virtuale Pag. 9

10 La paginazione è totalmente trasparente all'utente: non è più necessario specificare il numero di segmento (di pagina in questo caso) perché questo è insito nell'indirizzo stesso, indirizzo che viene appunto chiamato indirizzo lineare. Siccome la dimensione della pagine è fissa ed è pari ad una potenza esatta di 2, l'offset è costituito esattamente dagli ultimi bit dell'indirizzo lineare e il numero di pagina è costituito dai primi bit: ad esempio in un indirizzo a 32 bit i primi 20 possono rappresentare il numero pagina e gli ultimi 12 l'offset. Il meccanismo di traduzione da indirizzo lineare a indirizzo fisico assomiglia molto a quello della segmentazione: La MMU carica il numero di pagina dall'indirizzo lineare fornito dal programma La MMU conosce già l'indirizzo base della Page Table (che identifica l'inizio della medesima) e gli somma il numero di pagina trovando così la posizione (l'entry) nella tabella delle pagine dove è descritta la pagina in questione Le informazioni del descrittore della pagina contengono l'indirizzo base in memoria fisica cui viene sommato l'offset ottenendo finalmente l'effettivo indirizzo fisico. Indirizzo base page table B + P Indirizzo Lineare Numero di pagina Offset B Page table O B+P Page table entry P' Indirizzo fisico La traduzione secondo lo schema della paginazione Questo meccanismo ha però anche dei punti deboli: anzitutto con dimensioni di memoria piuttosto grandi è facile che si generi una page table molto grande e quindi difficile da gestire; la soluzione per questo è quella di adottare la cosiddetta paginazione a due livelli: si tratta di dividere il numero della pagina in due parti (ad esempio ciascuna di 10 bit): la prima parte identifica la posizione della page table nella directory delle pagine, la seconda parte identifica il numero di pagina dentro la page table selezionata. Memoria Virtuale Pag. 10

11 Indirizzo base page directory F + P Indirizzo Lineare Indice 1 Indice 2 Offset O F Page Directory P' F+P Indirizzo fisico Page dir. entry B' + B' Page Table B'+P' Page table entry La traduzione secondo lo schema della doppia paginazione Un ulteriore problema è dovuto al fatto che il programmatore non avendo alcun controllo sulle pagine non può imporre che parte del codice stia in certe pagine piuttosto che in altre. Succede allora che il concetto di protezione diventa totalmente inapplicabile (pur essendoci la possibilità di assegnare una protezione ad una certa pagina). Un altro svantaggio è che la paginazione (a differenza della segmentazione) prevede un unico spazio di indirizzamento lineare creando così non pochi problemi in ambienti multiprogrammati. Anche qui esiste una soluzione che è quella di assegnare ad ogni programma una sua page table (o una page directory); all'atto del context switching (ossia quell'insieme di operazione che il sistema operativo deve compiere per cambiare il processo attivo) viene caricato l'indirizzo nella MMU della page table corretta; in questo modo si può realizzare anche una certa protezione della memoria.. 1.4: La segmentazione con paginazione Quello che però effettivamente si usa nella maggior parte degli ambienti operativi commerciali è la combinazione delle due tecniche per sfruttare i vantaggi dati da ognuna delle due; si utilizza infatti un sistema di segmentazione che permette ai programmi di avere quanti spazi di indirizzamento lineari desiderano; poi questi vengono paginati in modo da poter essere comodamente gestiti dall'hardware. Certo che la MMU deve essere decisamente più potente e all'interno deve prevedere un'unità di paginazione e un'unità di segmentazione. La traduzione degli indirizzi virtuali in indirizzi fisici avviene con due stadi successivi: prima si adotta la traduzione secondo il sistema di segmentazione per passare da indirizzo virtuale a indirizzo lineare. Poi si adotta la paginazione su questo indirizzo lineare e si arriva all'indirizzo fisico. Memoria Virtuale Pag. 11

12 Indirizzo base segment table B + S Indirizzo Virtuale Selettore Offset B Segment table O Indirizzo fisico B+S Descrittore B' + O' Indirizzo lineare Numero di pagina Offset' Indirizzo base page table B'' P B'' Page Table + B''+P Page table entry P' La traduzione secondo lo schema della segmentazione con paginazione La tabella sottostante riassume schematicamente le caratteristiche delle tecniche analizzate. Il programmatore ne è consapevole? Spazi lineari disponibili Si può superare il limite della memoria fisica? Prevede forme di protezione? Perché viene implementata? Overlay Paginazione Segmentazione Paginazione + Segmentazione SI NO SI Solo della segmentazione Uno solo Uno solo Molti Molti SI SI NO SI NO NO SI SI Per superare il limite della memoria fisica Per superare il limite della memoria fisica Creare più spazi di indirizzamento lineari Combinare tutti i vantaggi Memoria Virtuale Pag. 12

13 Capitolo 2 La gestione della memoria sulle architetture x86 2.1: La memoria nell'8086 Il primo processore della fortunata famiglia x86 di Intel è stato l'8086; si trattava di un processore che in parte riciclava i vecchi lavori di Intel e le sue vecchie istruzioni; la base è infatti facilmente riconducibile al vetusto 4004, primo microprocessore a 4 bit della ben nota ditta californiana (e anche primo microcomputer in assoluto). Questo si è poi evoluto nell'8008 (a 8 bit) e successivamente nell'8080 trovando grande diffusione dentro i primi sistemi IBM. Quando IBM decise di entrare nel mercato dei Personal Computer per fare concorrenza alla Apple, l'intel preparò un'evoluzione a 16 bit del precedente processore, l'8086 appunto. Il fatto che il processore fosse a 16 bit implicava che la dimensione interna dei registri e del data bus avessero proprio questo parallelismo. La maggior parte delle istruzioni (che erano ereditate dal vecchio sistema CISC a 8 bit) erano lunghe 16 bit, ma gli operando potevano aumentare il numero di letture in memoria. L'address bus e il program counter erano a 20 bit e questo significava che la massima memoria indirizzabile da questo processore era 1 Mb (un bel passo avanti rispetto ai 64 KB dei vecchi 8080). Gli indirizzi venivano scritti su due parole distinte: della prima (i primi 16 bit) soltanto i 4 bit meno significativi venivano utilizzati, i rimanenti ignorati; questi identificavano l'area di memoria su cui operare (Intel parla di segmento di memoria, ma questa tecnica aveva ben poco a che vedere con la segmentazione in quanto mancava ogni forma di protezione e mancava la segment table, per cui in questo documento parleremo di aree di memoria); la seconda word rappresentava l'offset; erano quindi possibili 16 aree di memoria da 64 Kb, per un totale di appunto 1 Mb. Inutilizzati Area Offset 12 bit 4 bit 16 bit Si mostra qui come venivano sfruttate le 2 parole di memoria degli indirizzi. In realtà non tutte queste aree erano accessibili ai programmi, parte era riservata ai sistemi di controllo hardware ed al BIOS. In particolare le prime 10 aree (640 Kb) erano allocabili dai programmi e dal sistema operativo (allora il vetusto MsDOS 1) e formavano quella che fu chiamata memoria convenzionale. Le ultime 6 aree (384 Kb) formavano la cosiddetta memoria superiore (o anche UMB, Upper Memory Block). Memoria Virtuale Pag. 13

14 1024 Kb 960 Kb 816 Kb 800 Kb 768 Kb 640 Kb System BIOS ROM ROM to RAM option Hard disk controller Video Bios Option Video Ram Space Memoria Convenzionale 0 Kb La figura mostra come venivano distribuite questi aree: in particolare si noti che le prime due aree di memoria superiore erano riservate alla memoria video, le successive 3 servivano per copiare il codice dei BIOS di sistema e della scheda video sulla RAM per accelerare la loro esecuzione (per attivare questa copia c'è tuttora una opzione nel BIOS) e per contenere il codice di controllo dei dischi fissi. L'ultima invece conteneva il sistema di controllo hardware. Questo Megabyte di memoria era necessariamente sempre presente in tutti i computer e il processore non poteva funzionare in sua assenza. Col passare del tempo 1 Mb cominciava a diventare una dimensione un po' limitata, per cui occorreva trovare un rimedio; una soluzione fu quella di inserire dei connettori sulla scheda madre per poter leggere un nuovo tipo di memoria (fisicamente diverso dal precedente) chiamato memoria EMS (expanded memory specification, ossia memoria espansa). Così si poteva aggiungere memoria oltre il primo Mb, ma per poterla sfruttare un programma doveva utilizzare un complicato meccanismo di allocazione che era del tutto simile alla paginazione. Non entriamo ulteriormente nei dettagli, ma in questo modo era possibile espandere la memoria di 32 Mb rispetto alla dimensione iniziale. L'8086 fu anche prodotto in una variante: l'8088. La differenza stava nel data bus, che era di soli 8 bit. In questo modo si riuscì a montare l'8086 anche sulle vecchie schede madri IBM basate su Per questo l'architettura x86 ebbe successo e fu adottata quasi subito. In realtà l'8088 era necessariamente più lento perché ogni lettura da memoria andava fatta con due operazioni distinte per recuperare 8 bit alla volta dei 16 della parola. All'8086/88 seguì un nuovo processore: l'80186 (prodotto anche nella versione 80188). Questo chip segnò un'importante lezione per Intel: oltre a piccole migliorie interne praticamente trascurabili erano state integrate nella CPU una serie di chip esterni (controllori IRQ, buffer di memoria e altri chip di servizio simili) per semplificare la circuiteria sulla scheda madre. Purtroppo così facendo la compatibilità con l'8086 non era perfetta; questo decretò l'immediato fallimento del progetto su mercato, che vedeva il problema della compatibilità come quello principale. Memoria Virtuale Pag. 14

15 2.2: La memoria nell'80286 Il successore dell'8086/88 fu chiamato e venne prodotto in una singola versione (non c'era l'80288); si prese consuetudine allora di chiamarlo semplicemente 286. La grande novità di questa CPU era la presenza di una prima unità MMU in grado di sfruttare realmente un sistema di segmentazione. L'address bus e il program counter erano stati allargati a 24 bit, di conseguenza la massima memoria installabile era 16 Mb. Ma tale tipo di memoria non era fisicamente diversa dal primo MB (come nel caso dell'ems); era situata sugli stessi banchi, i «vecchi» moduli SIMM a 30 contatti. Poiché il DOS e tutti i suoi programmi non erano compatibili con formati di indirizzi a 24 bit, ma solo a 20 bit, in teoria il DOS non poteva essere eseguito sul 286; ulteriore ostacolo stava nel fatto che il 286 non era vincolato ad avere installati tutti e 16 i MB di memoria. La soluzione fu di dotare il processore di un dispositivo per poter far funzionare la macchina in due modi diversi: la modalità reale e la modalità protetta : La modalità reale Il sistema di modalità reale è lo stato nel quale la macchina si accende di default (anche gli attuali computer partono nella stessa modalità reale di allora). La memoria installata viene configurata come se si stesse usando un 8086: il primo Mb viene diviso al solito in 640 Kb di memoria convenzionale e 384 di memoria superiore. La memoria installata in eccesso (e non utilizzabile direttamente con indirizzi a 20 bit) viene vista dal sistema come XMS (extended memory specification, ossia memoria estesa). Tale memoria è utilizzabile dai programmi che la prevedono, ma tramite un meccanismo piuttosto lento e macchinoso. Non per questo restava comunque inutilizzata, infatti con il DOS 3.3 in poi venivano forniti alcuni dispositivi che ne facevano uso: l'himem.sys: serviva per creare nei primi 64 Kb di XMS un'area di memoria nota come HMA (High memory area, memoria alta) nella quale si poteva caricare il sistema operativo DOS liberando memoria convenzionale il ramdisk.sys: serviva per creare un «disco fisso» virtuale in memoria lo smartdrive: era una cache per disco con caratteristiche write back che utilizzava l'xms per accelerare le operazioni l'xaem86.sys (solo nel DOS 4): permetteva di emulare nell'xms una memoria EMS in modo che potesse essere utilizzata (tutto sommato più agevolmente dell'xms) dai programmi che la prevedevano 2.2.2: La modalità protetta Per fortuna però la memoria aggiuntiva poteva essere sfruttata anche in modo più dignitoso, nella modalità protetta: veniva abilitato un sistema di memoria virtuale, comandato dall'mmu del processore e dal sistema operativo (occorrevano sistemi operativo che fossero compatibili, come Windows 3.0 e Os/2). Gli indirizzi virtuali erano indirizzi segmentati nel formato 16:16 (16 bit di selettore e 16 di offset). Il selettore era fatto nel seguente modo: 13 bit di identificatore del segmento, 1 bit di selezione della segment table, 2 bit di RPL (Requested Privilege Level); questi ultimi servivano a definire il livello di privilegio necessario per poter accedere a quel segmento: 00 => ring 0, 01 => ring 1, 10 => ring 2, 11 => ring 3, dove il ring 0 ha la priorità massima d'accesso, il ring 3 quella minima. Il bit di Memoria Virtuale Pag. 15

16 selezione permette di specificare se il segmento di trova nella GDT o nella LDT: ogni processo ha infatti a disposizione una tavola dei segmenti proprietaria (Local Descriptor Table) e condivide con tutti gli altri processi una tavola condivisa (Global Descriptor Table) nella quale sono contenuti i segmenti che possono essere letti da qualunque programma. All'atto del context switch il sistema operativo doveva caricare la LDT corretta. Numero segmento ST RPL Offset 13 bit 1 bit 2 bit 16 bit L'indirizzo virtuale Di conseguenza ogni programma aveva a disposizione teoricamente 8192 segmenti da 64 Kb l'uno, per un totale di 512 Mb di memoria. La divisione del programma in segmenti era necessaria vista la limitata dimensione dei segmenti stessi. Il 286 in questa modalità era quindi in grado di allocare 512 MB di codice condiviso e 512 MB di codice privato; per cui ogni spazio di indirizzamento (=ogni programma) constava di 1GB al massimo. All'interno della segment table (chiamata descriptor table sui sistemi Intel) ci sono tutti i descrittori dei segmenti che includono dati quali l'indirizzo base, la lunghezza, la protezione, il DPL (Descriptor Privilege level) e la presenza o meno del segmento in memoria. Qualora la memoria fisica (che poteva contenere soltanto 16 Mb al massimo) fosse piena uno o più segmenti potevano essere swappati su disco nello swapfile per estendere così la memoria virtuale oltre il limite di quella reale. 2.3: La memoria nell' p5 Il processore che arrivò dopo il 286 fu chiamato o semplicemente 386. Rispetto a tutti gli altri modelli il 386 era un processore a 32 bit: possedeva nuove istruzioni a 32 bit, dati interi standard di 32 bit, larghezza dei bus interni, esterni e dei registri di 32 bit. Anche l'address bus e il program counter avevano 32 bit. Era quindi possibile montare sul sistema un massimo di 4 Gb (2^32) di memoria, una quantità che tuttora è ancora lontana dall'essere raggiunta anche se si sta gradualmente avvicinando. Il 386 poteva funzionare in modalità reale (con istruzioni a 16 bit), in modalità protetta (con istruzioni a 16 bit) e in modalità protetta «386» (con istruzioni a 32 bit). Un'importante novità fu poi l'introduzione della modalità virtual86. In pratica il 386 poteva emulare in pieno un 286 (anche se effettivamente era più lento di questo), in più introduceva questo nuovo set di istruzioni che permetteva di sfruttare il maggior parallelismo, le maggiori quantità di memoria e le nuove potenzialità della MMU che integrava sia l'unità di paginazione che di segmentazione. I processori successivi (486, Intel Pentium, AMD K5 e AMD K6) utilizzano questo stesso modello e non fanno altro che migliore le prestazioni con l'introduzione della pipeline normali (nel 486) e superscalari (dal Penitum in poi), ossia la possibilità di eseguire più istruzioni contemporaneamente. Se si eccettua l'mmx (improbabile estensione «multimediale») l'unica novità nell'instruction set sta esclusivamente in 4 nuove (e quasi inutili...) istruzioni nel 486. Altri processori (gli Intel Pentium PRO, Pentium 2, 3 e 4, nonché gli AMD K6 2 e 3 e i K7 Athlon) Memoria Virtuale Pag. 16

17 invece introducono una serie di migliorie nelle istruzioni, aggiungendo le «istruzioni per il 3D» e aggiungendo una nuova modalità di paginazione a 4 MB (con dimensioni dell'address bus di 36 bit). Queste CPU dovrebbero in teoria essere in grado di installare 64 GB di memoria, ma in pratica non esistono sistemi operativi sul mercato che fruttino questa nuova paginazione. La modalità protetta a 32 bit funziona in 3 diverse sottomodalità: il sistema a paginazione, il sistema a segmentazione e il sistema a segmentazione paginata : La paginazione La paginazione permette di applicare la tecnica che abbiamo già visto su uno spazio di indirizzamento lineare di 4 Gb. I programmi possiedono indirizzi a 32 bit che vengono paginati dal sistema con pagine grandi 4 Kb. Sarebbe perciò possibile che ogni programma teoricamente potesse disporre di 4 Gb lineari; una page table proprietaria di quel programma potrebbe essere caricata dal sistema operativo (all'atto del context switch) nella MMU; purtroppo c'è una limitazione: le parti del «codice condiviso» nonché la zona del sistema operativo devono essere SEMPRE visibili (per chiamate a sistema, ecc...). Di conseguenza parte dello spazio di indirizzamento viene destinato esclusivamente a questo scopo; le page tables che mappano tale area non subiscono sostituzione. Questo ovviamente riduce anche lo spazio disponibile per il singolo programma. Codice condiviso Page tables Programma 1 Programma 2 Page tables inattive Page tables inattive Programma 3 Spazio di indirizzamento lineare attivo Page tables attive 4 Gb O Ad ogni context switch vengono attivate diverse Page Tables per mappare la parte dell'indirizzo lineare privata. La parte condivisa invece non subisce la sostituzione delle page tables Per gestire in modo efficiente la memoria, il 386 prevede la paginazione a due livelli: i primi 10 bit dell'indirizzo lineare identificano all'interno della page directory l'indirizzo della page table da caricare. Ogni entry nella page directory è lunga 4 byte (indirizzo fisico della page table) per cui la dimensione totale della page directory è di 4 K. I secondi 10 bit dell'indirizzo identificano la pagina richiesta all'interno della page table selezionata; anche qui ci sono 4 byte per pagina e quindi una page table è grande 4 Kb: in altre parole occupa esattamente una pagina di memoria, per cui è facile swappare anche le page tables qualora la situazione lo richiedesse. Come sempre gli ultimi 12 bit rappresentano l'offset dentro la pagina selezionata. Da notare che nella page table solo 20 bit servono ad identificare l'indirizzo base della pagina (che di fatto differisce ogni volta di 4 Kb); gli altri 12 bit sono utilizzati per ulteriori informazioni sulla pagina: ad esempio indicano il PPL (page privilege level, ossia i privilegi che un programma deve avere per poter accedere al contenuto di quella pagina), il permesso di solo-lettura/scrittura, la presenza della pagina in memoria oppure nello swapfile, il tipo di pagina (di programma, di sistema Memoria Virtuale Pag. 17

18 operativo), il permesso di poter copiare sul disco quella pagina (alcune pagine non possono essere swappate, come quelle del sistema operativo), ecc... Prima di caricare una pagina un'opportuna unità della CPU (l'unità di protezione e test) controlla questi dati. Se si verifica una violazione questa viene notificata attraverso un apposito interrupt al sistema operativo che può così prendere le sue precauzioni. Da notare che lo spazio di indirizzamento di ogni singolo programma è quindi di 4GB, ma in tale spazio deve risiedere anche il codice condiviso. Per comodità quello che molti sistemi operativi fanno è quello di utilizzare 2 page directory: entrambe mappano gli stessi 4GB di memoria, ma la prima contiene solo le pagine di codice condiviso e la secondo di codice privato. Il context switch si riduce quindi a dover sostituire questa seconda page directory : La segmentazione La funzione di segmentazione è analoga a quella vista per il 286, ma più potente: questa volta l'offset è di 32 bit, ossia con la segmentazione gli indirizzi virtuali sono composti da addirittura 48 bit (16 di selettore e 32 di offset). Ogni descrittore di segmenti nelle descriptor tables è composto da 64 bit (8 bytes): 32 di questi vengono utilizzati per identificare l'indirizzo base del segmento, 20 la dimensione, 1 identifica se si sta utilizzando la paginazione a 4 Kb (vedi in seguito); 2 bit sono il DPL (descriptor privilege level, che specifica quale ring ha accesso all'oggetto),1 bit descrive se si tratta di un segmento di sistema operativo o di programma, 1 se il segmento è presente in memoria, uno definisce la dimensione degli operandi, gli altri 3 definiscono la politica di lettura e scrittura per il segmento. Vedi anche la figura sottostante. La protezione della segmentazione è quindi più completa di quella della paginazione. Tuttavia questa modalità non viene usata così com'è da alcun sistema in commercio. Limite (Prima parte) Base (prima parte) S, Tipo, DPL, P Limite Flag 16 bit 24 bit 8 bit 4 bit 4 bit 8bit Il descrittore del segmento per l'intel 386 Legenda: Limite: diviso in due parti (tra i bit 0 e 15 e tra il 48 e il 51) indica la lunghezza del segmento Base: divisa in due parti (tra i bit 16 e 39 e il 56, 63) è l'indirizzo fisico a 32 bit di partenza del segmento. S: (bit 44) Tipo di segmento, 0=di sistema, 1=di applicazione Tipo: (bit 40->43) bit 40: 0=non acceduto, 1=acceduto A seconda del bit 44, ci sono diversi significati per i bit 41->43, oggetto dati/codice, espandibilità in alto/basso, Read-only/read-write, solo-esecuzione/lettura-esecuzione. In caso di un segmento di sistema: LDT, TSS, Call Gate, Interrupt Gate, ecc... DPL: (bit 45-46) Descriptor Privilege Level Descrive quale ring ha accesso all'oggetto. P: (bit 47) Presente, 0=segmento non presente, 1=segmento presente Flag: (bit 52-55) bit 52: usato dagli oggetti UVirt; bit 53: dimensione degli operandi 0=16 bit, 1=32 bit; bit 54: grandezza degli indirizzi 0=16 bit, 1=32; bit 55: 0= il limite è espresso in bytes, 1= il limite è espresso in pagine da 4 Kb. Base Memoria Virtuale Pag. 18

19 Usando la sola funzione di segmentazione è quindi possibile avere per ogni programma 32 TB di memoria, più altrettanti sempre disponibili per il codice condiviso. Il context switch non fa altro che sostituire la LDT : La paginazione con segmentazione Si tratta della variante più potente del precedente schema a segmentazione e rispecchia in tutto e per tutto quanto già espresso in precedenza. Come visto nei descrittori dei segmenti si può specificare che il segmento sia paginato: questo non solo permette di avere segmenti da 4 Gb, ma permette specialmente di attivare la paginazione all'interno del segmento. Dai 48 bit di indirizzo virtuale viene ricostruito uno spazio di indirizzamento lineare a 32 bit, che poi viene paginato con le tecniche già viste della paginazione a 2 livelli. Questo sistema permette di combinare il meglio delle due tecniche: la protezione avviene sia a livello di segmenti che di pagine, il programmatore ha teoricamente a disposizione più spazi di indirizzamento (se usa anche il selettore) oppure può accontentarsi di un solo segmento evitando di specificare il selettore. È possibile usare segmenti con programmi a 16 bit e a 32 bit; nonché segmenti ii modalità virtuale (vedi sotto). Permangono però delle limitazioni: anzitutto l'hardware di paginazione prevede spazi di indirizzamento di soli 4 GB e non di 64 TB come prevedeva la segmentazione pura. Questo può considerarsi irrisorio viste le comunque generose dimensioni di cui si parla, ma è pur sempre una limitazione. Come se non bastasse i segmenti della GDT (ossia quelli che devono essere visti sempre e da tutti i programmi) devono essere mappati in tutti gli spazi lineari; per cui in effetti un programma non può struttare nemmeno tutti e 4 i GB messi a disposizione. Anzi, più codice condiviso c'è e meno spazio resta per il codice proprietario. La figura sotto riassume gli aspetti della paginazione con segmentazione nel 386. Memoria Virtuale Pag. 19

20 2.3.4: La modalità V86 Uno dei limiti introdotti con la modalità protetta nel 286 era quello di non poter eseguire alcun programma DOS (né il DOS stesso) quando questa era attiva. Ciò creava diversi fastidi in quanto i programmi erano limitati a 640 Kb, l'accesso all'xms era difficoltoso e sotto Windows non era teoricamente possibile eseguire programmi DOS se non interrompendo il multitasking. Una soluzione venne con il 386, il quale era in grado di creare all'interno di un segmento speciale della modalità protetta una macchina virtuale dos (VDM, Virtual Dos Machine); il processore per eseguire quel segmento entrava nella cosiddetta «modalità Virtual 86»: all'interno del segmento veniva ricostruita (in realtà emulata) la struttura classica della modalità reale ed era così possibile eseguire la maggior parte dei programmi DOS. Il primo ambiente a sfruttare questa possibilità fu Windows 3.0 se fatto partire con il comando win /386, che abilitava la cosiddetta «modalità 386 avanzata»; al suo interno era quindi possibile caricare programmi DOS. Anche il DOS stesso con la versione 5 abilitò un particolare supporto per lavorare sui 386: il driver emm386.exe. Questo permetteva di portare la macchina in modalità protetta e di creare un segmento Memoria Virtuale Pag. 20

21 VDM; il vantaggio di ciò era la possibilità di avere un controllo molto maggiore della memoria stessa e di poter caricare i driver e i TSR in memoria superiore liberando spazio in memoria convenzionale. Un altro gestore di memoria molto comune era il qemm386, una versione ancora più avanzata che permetteva anche di estendere la memoria HMA a 384 Kb e sfruttarla per caricarci sopra tutto quanto non ci stava nell'umb. Memoria Virtuale Pag. 21

22 Capitolo 3 La gestione della memoria in Os/2 3.1: Os/2 a 16 bit La prima versione di Os/2 realizzata da IBM e Microsoft per fornire un'alternativa valida alla pietosa accoppiata DOS+Windows era nata per poter essere eseguita sui processori 286. Era quindi basata su un codice a 16 bit e i programmi che poteva eseguire erano a loro volta a 16 bit. Per fornire la Crash Protection e gestire al meglio l'ambiente multiprogrammato Os/2 usava ovviamente la modalità protetta. Una parte del kernel denominata Memory Manager si occupava di colloquiare con la MMU e di gestire le segment tables. In accordo con le specifiche del 286 il sistema di segmentazione prevedeva 2 segment table (tabelle dei descrittori) per processo, la GDT e la LDT. Nella prima erano contenuti i segmenti che erano visibili da tutti i programmi (fino ad un massimo di 8192 segmenti) e in essi venivano caricate le DLL condivise, il kernel e i dispositivi del sistema operativo, nonché gli IFS e le cache per il disco. Tale codice funzionava a ring 0 ed aveva quindi il massimo del controllo su tutto il sistema. Ogni programma aveva la sua LDT, lista che specificava tutti i segmenti allocati dalla singola applicazione; ogni LDT ovviamente era a sua volta un'entry della GDT ed era protetta in modo che solo il sistema operativo potesse averne l'accesso in scrittura. Il codice applicativo girava a ring 3, per cui aveva il minimo dei privilegi di accesso e di fatto non poteva colloquiare direttamente con l'hardware (a dire il vero c'erano alcuni moduli nel sistema a ring 2 i quali potevano avere accesso diretto all'hardware). Quando la memoria fisica era piena veniva utilizzato uno swapfile e i segmenti meno utilizzati venivano scaricati su disco; quando un programma li tornava a richiedere questi venivano ricaricati in memoria. 3.2: Os/2 a 32 bit Con l'avvento dei processori 386, IBM (la Microsoft aveva abbandonato il progetto per dedicarsi a Windows e a Windows NT) creò la prima versione a 32 bit del suo Os/2, che di fatto fu il primo sistema operativo a 32 bit sull'architettura x86. La versione 2.0 manteneva la compatibilità con il vecchio formato di programmi a 16 bit e inoltre sfruttava la modalità virtual 86 per poter eseguire anche programmi DOS e Windows al suo interno. Per fare tutto questo il sistema sfruttava (e sfrutta tuttora) la modalità protetta a 32 bit nella versione «segmentazione con paginazione» : I 3 formati di indirizzi Os/2 32 bit supporta 3 diversi formati di indirizzi all'interno di un programma: Il formato 16:16 -> 16 bit di selettore e 16 di offset, è il formato di indirizzo virtuale usato dai programmi a 16 bit per Os/2; ci sono alcuni moduli del sistema che per necessità o limitazione sono ancora a 16 bit, anche questi adottano tale formato. Ad ognuno di questi programmi è assegnata una specifica LDT in modo da poter emulare le funzioni di segmentazione pura. Il formato 16:32 -> 16 bit di selettore e 32 di offset, è il nuovo formato di indirizzo virtuale possibile in Os/2 a 32 bit. Le parti interne a 32 bit del sistema operativo specificano sempre il Memoria Virtuale Pag. 22

23 loro indirizzo in questo formato; trattandosi di elementi strutturali del sistema (e quindi globali) non è necessario assegnare loro una LDT. Il formato 0:32 -> 0 bit di selettore e 32 di offset. È stato ritenuto che difficilmente si sarebbero visti programmi di dimensione superiore a 4 Gb; inoltre ai programmatori non è mai piaciuto lavorare su segmenti multipli, per cui avendo a disposizione uno spazio di indirizzamento da 4 Gb avrebbero comunque scritto i loro programmi per un unico segmento. Ecco quindi che prevedendo questa esigenza (che invero si concretizza in tutti i sistemi operativi per personal computer) è stato deciso che i programmi a 32 bit dovessero avere un unico segmento. La LDT contiene quindi un descrittore di un unico segmento la cui dimensione è variabile ma il cui indirizzo base è sempre 0. Questo indirizzo virtuale «implicito» non necessita quindi di venir tradotto in indirizzo lineare, in quanto tale traduzione darebbe come risultato l'offset stesso. Se da un lato questa scelta comporta la perdita della maggior parte dello spazio virtuale di un'applicazione (che potrebbe essere 8192 volte maggiore), rappresenta un buon compromesso in termini di velocità (si salta la prima traduzione, o meglio è implicita) e permette di risparmiare spazio in quanto si codificano gli indirizzi come soli 32 bit e non come 48 bit. Certamente però per accedere ad un segmento del sistema operativo (di memoria condivisa) occorre specificare l'indirizzo a 48 bit completo. È possibile passare facilmente dal formato 16:16 al formato 0:32 semplicemente shiftando alcuni bit, mentre la conversione inversa necessita di una somma e di una moltiplicazione : Primo livello di traduzione in indirizzo lineare La traduzione da indirizzo virtuale in formato 16:32 e 16:16 segue fedelmente gli schemi già visto per la segmentazione nel 386: all'interno del processore viene caricato l'indirizzo base della GDT e della LDT (questo cambia ad ogni context switching). Il selettore identifica la posizione dentro queste due tabelle del descrittore del segmento attivato. Identificato il descrittore avvengono una serie di operazioni di controllo: anzitutto si verifica che l'offset sia minore della massima dimensione specificata in quel segmento, quindi si controlla che l'rpl dell'indirizzo attualmente attivo in memoria abbia privilegi sufficienti (sia ad un ring minore o uguale) a quello specificato nel campo DPL del descrittore. Poi si verificano le flag read-only/read-write per sapere se è possibile scrivere su dato segmento oppure soltanto leggere. Se i controlli non vanno a buon fine si genera un «segment fault» (detto anche trap D) che viene notificato al sistema operativo, e Os/2 non può far altro che terminare il programma che ha causato il problema; se invece i controlli passano l'offset del segmento viene sommato all'indirizzo base. In questo modo si può determinare l'indirizzo lineare univoco. Le applicazioni a 32 bit non ammettono più di un segmento per applicazione, il che significa che non possono avere più di una singola voce nella LDT. Di questa voce molti dei campi sono standard: un'applicazione viene eseguita a ring 3, ha sempre i permessi di scrittura da parte dello stesso ring negati, ha sempre lo stesso indirizzo base ( ) ed è sempre paginata; cambia solo la lunghezza del segmento: di default ai programmi vengono assegnati segmenti di 64 MB, ma questo segmento può crescere in dimensioni su richiesta dell'applicazione stessa : Le arene di sistema Come accennato in precedenza il 386 prevede la mappatura obbligatoria nello spazio di indirizzamento lineare del codice contenuto nella GDT perché questo sia disponibile per tutte le Memoria Virtuale Pag. 23