Newsgroup: it.comp.lang.c++
Titolo: Compilatore a 32 bit e indirizzamento della memoria

Ho notato che i registri di segmento di una CPU a 32 bit sono tutti a
16 bit ed alcuni puntatori sono formati appunto dal relativo segmento
a 16 bit e da un offset a 32  .
Ma allora i vari segmenti di un compilatore a 32 bit sono ancora al
max di 64K ? No sicuramente ci sara' qualcosa che mi sfugge ...  .
Come funziona allora l'indirizzamento della memoria in un ambiente a
32 bit ?
~~~~~~~~~~~~~~~~~
MAINARDI Gianfranco
Burago di Molgora (MI)
Italia
Email : 
main...@tin.it
ICQ# number : 11607125
~~~~~~~~~~~~~~~~~

32 bit ?
Dipende dall'ambiente, comunque: la maggior parte dei
compilatori, nella ragionevole ipotesi che la maggior parte
dei processi se la possano cavare benissimo con soli
4gigabyte indirizzati, settano normalmente tutti i registri
di segmento allo stesso valore, usando quindi un segmento
solo (di 4gigabyte o meno) per tutte le esigenze del processo.
D'altronde, molti sistemi operativi impongono un limite del
genere (se non piu` stretto) a ciascun processo che essi
ospitano.  L'architettura dei segmenti si usa in questi casi
solo per scopi del tutto diversi, come distinguere codice a
16 da codice a 32 bit (e` un attributo del segmento di
codice), il livello di "fiducia" di cui il codice gode (dal "ring"
piu` basso, quello di "user mode", al piu` alto, quello di
"kernel mode" -- anche questi sono attributi di segmento),
e cosi` via.
Alex

 max di 64K ? No sicuramente ci sara' qualcosa che mi sfugge ...  .
Il registro selettore di segmento 16 bit indica che si possono avere
64KB segmenti distinti, il registro offset di segemento a 32 bit
significa che si possono avere segmenti fino a 4GB.
Questo in parole povere poi il tipo di gestione della memoria che ha
ogni S.O. puo' cambiare un po' le cose (ad esempio alcuni bit nei
selettori di segmento vengono usati per la protezione, ma questa e'
un'altra storia...).
-- 
     (ZZZ)       Filippo Salotti, Bagni di Lucca, Lucca, Italy.
    //   \\  _                 E-mail : 
fil...@humnet.unipi.it
   /Y\    ZD<_o===============================================o
 .oZZZZZo.     | Studente Ingegneria Informatica Automatica  |
<OXXXXXXXO>    | Dip. Sistemi Elettrici Universita' di Pisa. |



Cerchero' di spiegarmi meglio .
La circostanza mi si e' presentata mentre eseguivo un debug con il C++
Builder  ( versione trial ) ispezionando una finestra CPU - Adesso non
ricordo se tutti i registri di segmento erano allineati ,ma ricordo
perfettamente che questi erano riportati a 16 bit -
Quindi un semplice puntatore ai dati era definito da un segmento a 16
e un offset a 32 -
Se come tu dici ,tutti i registri di segmento sono allineati allora si
potrebbe dire che questo compilatore produce ( facendo una analogia
con il vecchio Dos) del codice in un modello di memoria "tiny"  , solo
che in questo caso un programma puo disporre di 4 Giga di memoria .
Volendo superare questo limite ( e non so se il S.O. Win 95  ed il
compilatore della Borland possono farlo) presumo che gli indirizzi
presenti nel registro di segmento non siano reali ,ma puntano ad un
selettore di segmento (forse a 32 bit ) che indicano l'indirizzo
fisico della memoria (un po come succede per il "DAC" nella
generazione dei colori in una scheda super VGA) .
Ad ogni modo per poter indirizzare una memoria di oltre 4 Giga il bus
dati deve essere maggiore di 32 bit . Mi viene in mente il trucco che
operava il dos per generare un indirizzo a 20 bit con registri a 16  .
Non potrebbe essere lo stesso anche in questo caso ?


 Non potrebbe essere lo stesso anche in questo caso ?
Non mi e` ben chiaro il senso di questa domanda, comunque,
e` sicuramente possibile che l'Intel (o un suo imitatore)
se ne esca domani con un chip di CPU che permette un accesso
fisico a piu` di 4 gigabyte di memoria fisica (per i soli
SO che supportano questa estensione, naturalmente, o se no
con "sporchi trucchi" come tanti se ne sono visti in passato,
tipo la virtualizzazione dello stesso SO da parte di un
"super-supervisore", ecc ecc), senza pero` che ciascun
singolo processo in esecuzione superi comunque i 32 bit
di spazio d'indirizzamento virtuale, che sono un limite
architetturale.
Cosa c'entri tutto questo col fatto che un processo puo`
accedere a non piu` di 65536 segmenti diversi (ciascuno
di al massimo 4giga), visto che i registri di segmento
hanno solo 16 bit, continua pero` a sfuggirmi totalmente.
Alex
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/
       Search, Read, Discuss, or Start Your Own    


Stiamo facendo molta confusione .
Io vorrei sapere semplicemente  come fa una CPU a 32 bit  con S.O. win
95 ad indirizzare la memoria .
Le CPU a 16 bit se ben ricordi per indirizzare un solo MB di memoria
usano il trucco del segmento  spostato a sinistra di una cifra
esadecimale ,in questo modo riusciva a emettere un indirizzo fisico a
20 bit .
I nuovi registri a 32 bit e' pur vero che possono indirizzare 4 Giga
di ram ,ma non avrebbe senso se calcolassero l'offset da un segmento a
16 bit (tali registri di segmento non servirebbero a niente, ne
basterebbe uno per tutti ) per cui ritengo debba esistere un altro
modo di combinare il segmento e relativo offset ( accennavo per
analogia ai registri del dac delle VGA) .
Tale sistema dicevo potrebbe funzionare in modo tale che l'indirizzo
presente nel registro di segmento non sia l'inizio effettivo di un
segmento ,ma una specie di puntatore 16 ad un  puntatore a 32 bit . 
Il puntatore  a 32 bit rappresenterebbe a questo punto il vero
indirizzo fisico del registro di segmento .
Qualcuno parlava di descrittori, ebbene esso sarebbe uno dei 65536
descrittori16 di puntatori32 a segmento .
Spero di aver illustrato il mio concetto ....... aspetto un
chiarimento ,grazie .


chiarimento ,grazie .
Riassumendo: scordati completamente l'8086 e qualsiasi
altro processore Intel di 20 anni fa o giu` di li`; lo shift and
add non svolge nessun ruolo nell'indirizzamento delle CPU
Intel a 32 bit; la segmentazione, molto complessa, e` oggi
del tutto marginale, usata per poche cose "strane" come
l'accesso a codice a 16 e a 32 bit da entro lo stesso
processo, e puoi praticamente dimenticarla quando fai
"normali" programmi a 32 bit, anche in assembler; e` la
paginazione che rimappa gli indirizzi logici in fisici, nel
modo piu` flessibile e dinamico, a cura del S.O che stai
usando.  E il numero di bit presenti nei vari diversi
registri e` pure un fattore non primario in questo 
meccanismo (eccetto per il fatto che ciascun singolo
segmento e` limitato a 4 gigabyte).
Alex