Newsgroup: it.comp.os.dibattiti
Titolo: modalità reale e protetta

Qual'e' esattamente la differenza tra modalità reale o protetta?
--- (Elimina il papero per le repliche) ---

Qual'e' esattamente la differenza tra modalità reale o protetta?
Non sono un programmatore di assembler (o perlomeno non uso
l'assembler per portare il sistema in modalità protetta, cosa che per
quanto ne so non è poi una cavolata) e non pretendo che la mia
risposta sia esauriente. Comunque il nome "modalità protetta" deriva
dal fatto che quando il processore lavora in tale modalità, ogni
programma può leggere e scrivere solo i suoi segmenti 'privati' di
memoria, pertanto le altre applicazioni risultano protette da errori
del programma. E' anche vero che i crash sono frequenti anche nei
sistemi operativi che operano in modalità protetta (oppure solo in
alcuni? :-D)
Sicuramente le peculiarità della modalità protetta sono anche altre,
ma come ho già detto non conosco questo argomento a fondo, argomento
che per altro interessa davvero solo a programmatori di sistemi
operativi.
Spero di non scatenare alcun flame...
Ciao
Wilmer Ricciotti


Ma queste domande le fai sapendo già la risposta ed accendere un dibattito
con qualcuno che risponde in maniera non corretta oppure perchè non lo sai
proprio?
Scusa l'indiscrezione...
Ciao.
Gabriele Del Giovine

 proprio?
Ma queste domande le fai per accendere una flame war *prima* che venga
scambiata una qualunque informazione utile o perche' non riesci a
resistere?
Scusa l'indiscrezione.
Cheers,
	Alessandro

Ok. Chiudo....

Ma queste domande le fai sapendo già la risposta 
So gia' la risposta, ma non e' corretta. C'e' qualcosa che non quadra. Cerco
la risposta esatta dal punto di vista formale. Cerco informazioni per il mio
gestore di memoria ideale.
Dove voglio arrivare e' semplice. Su un articolo vecchio di Randy Kath ho
visto quanto tempo ci perde il S.O. per lavorare in modalità protetta. Il
context swich mi risulta essere addirittura sui 17 millisecondi. Perche'
però quei pochi R.T.S.O. che conosco, e che girano nel mondo
dell'automazione industriale, vanno in modalita' protetta? Il context swich
ha senso in modalita' reale? Io credo di no, ma magari mi sbaglio.
Con il famigerato (teorico) gestore di memoria non paginato di cui chiedo
potrei trappare gli errori generici almeno in fase di debug. E allora.
Malgrado cio' io non mai sentito di R.T.S.O. moderni in modalita' protetta.
Addirittura pare esista un NT modificato per renderlo real time (ancora da
provare n.d.p.). Non essendo io un esperto in materia, e vedendo che il
trend va in quella direzione, mi chiedo perche'.
Prima di gercare una risposta al perche' pero' devo avere basi solide e
sapere formulare la domanda in modo corretto. Da qui la mia richiesta per
avere la definizione formale di differenza tra modalita' protetta e reale.
Dopo avrei proseguito con il mio ragionamento.
+++
Ma sentito parlare di Socrate? Pare che abbia copiato da lui in questo modo
di portare avanti il ragionamento. A me, tra i filosofi greci, mi piace di
piu' Eraclito detto da me il Papero, ma tant'e' ...


memoria, 
Ovvero se vuoi l'indirizzamento virtuale via hardware devi andare in
modalita' protetta. In modalita' reale non ci riesci.
O non ci riesci solo se non vuoi? Non basterebbe tornare alla memoria
segmentata, e definire i vari range di segmenti che un processo vede?
+++++
In modalita' reale (e non solo sui processori Intel) posso avere i vari
gradi di *protezione* istruzioni CPU di almeno 2 ring?


 protetta?
Io so che per applicazioni "serie" e dove l'investimento vale la candela
si usano macchine adeguatamente "serie", non processori compatibili Z80.
Purtroppo  non ho  la possibilita'  di permettermi  un'ottima sparc  per
casa... :-(
ciao
--
Dalla Silvestra Michele
Key fingerprint = 68 02 A9 C7 FB 05 9E 9C  C7 B6 4A 13 61 25 5B 43

non processori compatibili Z80.
Cos'ha' lo Z80 che non va, adesso???

Dopo avrei proseguito con il mio ragionamento.
L'esistenza dei due modi funzionamento, Real mode e Protect mode e'
dovuta a motivi storici in quanto x86 ha vent'anni di vita ormai.
Real & Protect mode sono una caratteristica unica dei processori x86
(ma non e' merito!).
Tutti i moderni processori RISC ma anche CISC, vedi il 68000,
hanno un unico modo di funzionamento che equivale (ma e' superiore)
al protect mode degli x86.
Per risolvere i tuoi dubbi puoi andare su 
http://developer.intel.com
 e
scaricarti i manuali dell'architettura x86.
Non esiste altro modo per avere un'informazione chiara e ufficiale!
Qui invece c'e' un'ottimo articolo sul pm: 
http://www.x86.org
Lorenzo Allegrucci

papero...@tin.it
 wrote:
 >Dove voglio arrivare e' semplice. Su un articolo vecchio di Randy Kath ho
 >visto quanto tempo ci perde il S.O. per lavorare in modalità protetta. Il
 >context swich mi risulta essere addirittura sui 17 millisecondi. Perche'
 >però quei pochi R.T.S.O. che conosco, e che girano nel mondo
 >dell'automazione industriale, vanno in modalita' protetta? Il context swich
Le versioni piu` recenti di linux fanno il task switching via software,
la stessa intel documenta che usare il TSS e` lento.
 >Malgrado cio' io non mai sentito di R.T.S.O. moderni in modalita' protetta.
QNX? Linux-RT lo e` di certo.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

al protect mode degli x86.
Beh, se vogliamo essere pignoli, il 68000 aveva la modalità user  e
quella supervisor, ma quella era un vantaggio  dato a chi scriveva i S.O...
Ciao, Carlo
altieri@infostudi aggiungere .it

gradi di *protezione* istruzioni CPU di almeno 2 ring?
I processori intel hanno 4 gradi di protezioni.
Linux ed NT ( e penso W95 quando vuole ) ne utilizzano solo due per
facilitare il prorting anche su altre piattaforme ( es alpha ).

trend va in quella direzione, mi chiedo perche'.
Non so' quanto faccia testo ma c'e' una versione di linux RT, e non
credo che gli abbiano tolta la modalita "protetta" ( insomma c'ha i
context switch ).
Penso che alla fin fine e' solo un problema di prestazione. Se ti
accontenti di un sistema con minore precisione *puoi* adottare un
sistema che gira in modalita' protetta.
Altrimenti *devi* adottare un processo in modalita' reale ( ovvero
senza context-switching )

quella supervisor, ma quella era un vantaggio  dato a chi scriveva i S.O...
Volevo dire che non e' mai esistito l'analogo del real mode
nella famiglia 68K. Fin dall'inizio 32 bit pieni e indirizzamento
lineare, senza contare i 16 registri contro gli 8 di x86.
Lorenzo Allegrucci

microsecondo.
Parli di macchine dedicate o di SO ?
Io sapevo ( parlo per SO generici - architettura intel x86 ) che un
context swich aveva bisogna di svariati centinaia di cicli ( durante i
quali non sepre la cache e' pronta, per cui si dovrebbe lavorare a
velocita' di bus : 33MHz fino apoco tempo fa ) per cui mi torna
qualche mS.
Per qunto riguarda i time-slice sulle archietture normali si parla di
decimi.

meglio il 68000 :-)
D'accordo, ma mi pareva che si parlasse di 80x86 compatibili, quando
all'improvviso mi spunta lo Z80...
Obelix

lineare, senza contare i 16 registri contro gli 8 di x86.
E' un po' di anni che non programmo in asm 68000, ma
mi pare di ricordare che il CALL o il JMP non era possibile con
l'indirizzamento assoluto a 24 bit, ma solo relativo a 16 bit,
confermi o mi sbaglio ?


decimi.
In W95 sapevo che era di 20ms. Gli altri non lo so, purtroppo.
Lorenzo Allegrucci

confermi o mi sbaglio ?
Ho qui il manuale .pdf del 68000.
CALL in 68K si chiama BSR, Branch SubRoutine e il displacement
e' a 16 bit nel 68000, qundi solo 32Kb indietro relativi al PC
o 32 Kb avanti al PC. Dal 68020 in poi i 16 relativi sono diventati
32, in pratica assoluti, quindi.
Tuttavia il 68000 aveva anche JSR, Jump SubRoutine che poteva
sfruttare l'indirizzamento assoluto a 32 bit.
JMP aveva tutta una serie di indirizzamenti tra cui un immediato
a 32 bit e ovviamente (An) anch'esso a 32 bit.
Motorola aveva fatto le cose per bene, come sempre.
Lorenzo Allegrucci

 --    |
|____________________________________________________________|

QNX? Linux-RT lo e` di certo.
Con tutto il rispetto, sono molto sospettoso verso quelle cazzabubbole.
Sopratutto verso QNX (Linux-RT non l'ho mai visto n.d.p.). Nel mio settore
non saprei cosa farmene di un R.T.S.O. che prevedere un interfaccia grafica.
e file system. Per il cinema ci sono i PC industriali.
La tendenza (nel settore) e' che i PLC si appoggino sui PC. Se muore il PLC
l'impianto si ferma (ma non si rompono spesso) con un grande scattare di
sicurezze elettromeccaniche, se si rompe il PC, si rompe l'interfaccia
grafica e il sistema di raccolta dati, ma l'impianto va giusto per il tempo
di metterci un PC di ricambio.
Usare PC industriale al posto di PLC lo trovo demenziale. I PLC sono delle
roccie in ambienti veramente ostili (caldo, interferenze elettromagnietiche,
polvere, sovratensioni, e altro). Non credo che Linux-RT possa girare
altrove che su dei sostanziali PC 
Ma magari mi sbaglio e Linux gira su cose strane molto rocciose. Ormai mi
aspetto di trovarlo nel'ascensore.
++++
Ho lavorato per una ditta che usava un RTOS della Pharl Lap. Io praticamente
usavo le win32, tanto il quel sistema operativo le chiamate erano
praticamente le stesse (cosi' mi dissero). Praticamente una manna dal cielo
per me.
Magari mi hanno mentito e' usavano NT.
++++
Mentre la Sega usa Windows CE, la Sony si fa i suoi S.O. proprietari. Io non
credo nei S.O. che fanno tutto. Malgrado il processore a 128 bit della Sega,
tecnologicamente tifo per Nintendo e Sony.
Quando vedo un QNX con il browser mi cadono le braccia. A che serve in un
RTOS? Invece di fare delle librerie per il C perdi tempo in cazzabubbole?
Ztse, ztse!
+++
Chissa' perche' invece la Sony non si fa anche i processori. Sono tra i
maggiori produttori mondiali di VLSI e affini.


Qui invece c'e' un'ottimo articolo sul pm: 
http://www.x86.org
Prima guardero' questo. Sembra piu' indipendente come giudizio.


si usano macchine adeguatamente "serie", non processori compatibili Z80.
Nel 1996 ho lavorato per un controllo numerico sperimentale della Fanuc
(sezione giapponese della General Elettric). Il compilatore C usato era un
cross compiler della Intel. Sospetto i chip fossero NEC (altamente
compatibili con Intel da quel che so).
Credo che fosse un giocattolo da un miliardo di valore per l'utente finale.
S.O. naturalmente proprietario. Mica sono cazzabubbolani come quelli della
Siemens i giapponesi (e gli italiani aggiungo n.d.p.).
Nel mondo dell'automazione io vedo girare dei gran Intel e dei gran PowerPC.
SAIE (svizzeri) per i PowerPC per fare un nome a caso.  Pare che siano
meglio i PowerPC, ma per motivi a me oscuri ho visto molti convertirsi a
Intel
++++
Oscuri si fa per dire. Avere due S.O. sui controlli numerici e affini e' una
soluzione adottata da molti. Prova a fare girare anche NT su PowerPC (che
non e' piu' supportato). OS/2 nel settore e' morto da tempo, e Apple non si
e' mai affacciata (paura degli ambienti sporchi?).
Linux per l'interfaccia grafica con gli umani sarebbe interessante, ma non
l'ho mai vista. Problemi di dovere formare da zero del personale credo. O
forse e' solo questione di tempo.
++++
Per quelche strano motivo non ho mai visto usare Alpha, ma per fortuna la
mia esperienza e' una piccolissima goccia, e di processori che ne sono a
bizzeffe.
++++
Mi risulta che nelle cabine telefoniche della AT&T girano dei 386.


Cosa farebbe il ( teorico ) gestore di memoria non paginato ?
Alloca per i processi user memoria non paginata. Servirebbe per compilare
programmi di debug in C/C++ che possano evitare che uno allochi un byte e
poi gigioneggi dentro una pagina di memoria, come e' possibile in tutti i
S.O. a memoria paginata.
Certo, magari tu P-compili in Java e quindi non usi i puntatori, ma questo
allora sarebbe un altro thread. 
Alla fine non si scappa. qualcuno quei sporchi puntatori li deve usare (e se
non programma in C/C++ allora usa l'assembler).


 >Malgrado cio' io non mai sentito di R.T.S.O. moderni in modalita' protetta.
Errore di scrittura. Mi scuso. Ho riletto il mio post. Parlo chiaramente di
RTSO che girano in modalita' protetta. Non ho mai sentito di RTSO che girano
in modalita' reale.
La mia constatazione voleva essere solo che probabilmente la mia suppozione
che protetta -> qualche millisendo in piu' (forse) non e' corretta.
Per la cronaca in una macchina per impacchettare sigarette si parla di
migliaia al secondo. Oltre avere una meccanica costosuccia, li un
millisecondo in piu' fa veramente la differenza.
Un millisecondo in piu' fa un cent in meno, e ci sono veramente tanti
millisencondi in un anno.


Un numero addirittura buono. E' realistico?
Certo, e' per questo che ritengo il context switch questione
dell'ordine del microsecondo.
Lorenzo Allegrucci

In W95 sapevo che era di 20ms. Gli altri non lo so, purtroppo.
Sono io che non so fare le divisioni : ricordi bene tu; 1/50 di
secondo = 20 ms e non 200ms come avevo pensato.

>Mi risulta che nelle cabine telefoniche della AT&T girano dei 386.
Nelle schede telefoniche di centrale (usate anche dalla Telecom),
all'inizio erano addirittura degli 8086.
In giro sulla rete c'č una Faq di telefonia (anche in italiano, se non mi sbaglio)
interessantissima !


 Ecco spiegato il perche' del maggiore utilizzo di queste CPU!!!
Spero che tu intenda nel campo dell'automazione.
Potresti indicarmi le fonti ?
Incredibile, leggevo che l'architettura da 32bit in su più venduta
per numero di pezzi l'anno scorso è stata la MIPS, per via della
Playstation e del Nintendo 64, qualcuno può confermare ?


Lorenzo Allegrucci


ho confuso i mnemonici.
Di niente, mi dispiace solo che con una semplice JSR avresti
risolto tutti i problemi.
Lorenzo Allegrucci

decimi.
Sul sito della phar lap che produce un RTOS che emula (pare) le win32 e usa
NT per cross compilare c'e' qualche informazione. (Sul sito Intel e
Microsoft non ho trovato nulla). Si parla di minimo 10 microsendi di time
slice per i SO della Microsoft. Deduco che il context switch sia piu' veloce
ol al massimo paragonabile.


risolto tutti i problemi.
E innumerevoli entry point sparsi nel codice, tutto si può fare, mi pare
che la polemica per gli x86 fosse sul come, comunque preferisco
la soluzione dei trap e le tabelle di indirizzi.


INDIRIZZAMENTO LINEARE A 32 BIT !
Scusa, ho preso una tremenda bufala !
Leggendo in fretta la tua risposta ho identificato JSR come un salto relativo e non come una salto a funzione, però non ricordo
perchè ma sull'Atari avevo problemi a chiamare subroutine oltre i 64K, ci penserò ...
(era stata la prima difficoltà incontrata e mi aveva fatto perdere molto tempo, se era solo perchè venivo dallo Z80 e nei mnemonici
JR stava per un salto relativo e non ho mai pensato a leggere la pagina del manuale con il JSR mi inca**o, ero arrivato appunto a
disassemblare altri programmi per capire :-( ).
Ciao, Carlo
altieri@infostudi aggiungere .it
---------------------------------------------------------------------------------------------------
Chiedere scusa e' la supercolla della vita. Puo' aggiustare quasi tutto.
Lynn Johnston
---------------------------------------------------------------------------------------------------
se cerchi altre pagine visita la mia pagina WEB:
www.aspide.it/freeweb/Altieri/Massime.htm

dell'ordine del microsecondo.
Leggendo le specifiche dei Cyrix ho scoperto che non tutte le
istruzione possono essere svolte in un ciclo di clock, molte (
soprattutto se sono in modalita' protetta ) ne richiedono piu'. Il
tutto dipende poi dallo stato della cache. Se il context switch
avviene con un processo non eseguito da parecchio tempo, e' possibile
che non vi siano piu' dati in cache il che implica la non validita' 
( stiamosempre parlando di architetture x86 ) di un ciclo-una
istruzione.

non programma in C/C++ allora usa l'assembler).
Perfettamente daccordo.

Playstation e del Nintendo 64, qualcuno può confermare ?
Probabile. Le due versioni di CPU pero' sono diverse. Non ho ben capito se
la CPU della Nintendo e' a 64 e quella della Sony e' a 32.  In tal caso la
CPU della Nintendo andrebbe tolta dal conteggio.
Adesso uscira' la Sega con CPU 128 (credo ARM, ma e' altamente probabile che
mi confonda). Mi sembra anche che la Sega ha intenzione di fare console con
Windows CE, ma non capisco allora cosa se ne fanno di chip a 128 bit.


CPU della Nintendo andrebbe tolta dal conteggio.
Era specificato da 32 bit in su ...


 Se il context switch [..]
Nella cache di un Alpha, per esempio, ci sono le liste per completare le
assegnazioni di memoria del processo in corso (fonte: "Sistemi Operativi" di
Tanenbaum, Prentice Hall). Il che esclude che ci possa essere troppo spazio
per i dati degli altri processi.
Comunque qualcuno avra' fatto delle statistiche in merito. Sicuramente le
avranno fatte in Motoriola, Intel, Microsoft, Apple (anche se di pubblico
non ho visto nulla).
Magari e' piu' interessante, e piu' aderente alla realta', delle solite
prove sulla FPU tra AMD e Intel.


sufficenza in assembler !
Tutto cio' nasce pero' dalla mia ipotesi di fare un gestore di memoria di
debug che ti permetta di avere un check completo dei memory leak, e delle
sovrascritture dei buffer.
Incomincio a pensare che la soluzione migliore sia usare il C++. In una
newsletter sul C++ ho visto a riguardo della sovrascrittura dei buffer del
codice molto interessante. Ma quanto sara' lento?


differenza abissale (pare, fonte: "Il manuale del Pentium" McGraw Hill). 
In qualsiasi processore la divisione e' piu' costosa della
moltiplicazione.
Infatti il Pentium per esempio:
fdiv 39  clock
fmul 3,1 rispettivamente di latency e throughput.
Lorenzo Allegrucci

codice molto interessante. Ma quanto sara' lento?
Scusa, ma se io dichiaro
int	*p.
Chi mi puo' controllare dove punta 'p' ? Penso solo una MMU e solo con
molti limiti.
Se poi uno vuole evitare i punttatori ... be' vada ad utilizzare java
o il visual basic !

o il visual basic !
Che muoia Sansone con tutti i Filistei e i SenzaPuntatori !


Mettici uno stack, usalo sul serio, e tutto va in crisi. 
This is your opinion, not reality.
Obelix

 Se per esempio l'RPG non ha stack,
Hem.. il fatto che l'RPG non abbia stack non significa che OS400 non
abbia stack.... giusto per chiarezza.
E comunque, in RPG IV puoi definire array a run-time. Quindi, de
facto, il sistema *non sa* quanta memoria servira' al processo (direi
anzi che non lo sa mai... gia' da RPG-II potevo chiamare altri
programmi o no..)
Obelix

Che muoia Sansone con tutti i Filistei e i SenzaPuntatori !
 :))

Complicato, farraginoso, ma si puo' fare.
Non so se si possa realemten fare in modo elegante. Io mi aspetto che quando
definisco la variabile NDEBUG il codice torni veloce.


fissi. Poi su i tipi semplici non funziona.
Sicuro ? Non ricordo bene il C++, ma credo che si possano ridefinere
anche gli operatori sui tipi semplici ( anche se mi sembra un po'
sadomasochista ) ...
Forse e' piu semplice riprogettare il compilatore ....

Forse e' piu semplice riprogettare il compilatore ....
Portiamo la sottoscrizione a 2 milioni di dollari, e rifacciamo anche il
compilatore.
++++
Che ne dici se spostiamo la discussione su it.comp.embedded?
Il gruppo non esiste, e quindi bisogna crearlo prima.
Non mi dispiacerebbe un posto con minori guerre di religioni, in cui si
potesse parlare di algoritmi di ottimizzazione del carico, di DB che stanno
in dischetto, e di cose arcinote agli addetti al settore come le schede
Digiboard.
Prima di iniziare la trafila *burocratica* per tentarr di crearlo volevo
sondare se puo' interessare qualcuno di questo NG.


 usando molti handle. In passato questo ha significato crash. Che facciamo?"
Pure questo non e' lontano stiamo mettendo su un sistema di controllo di
network system management che ha come motore Unicenter TNG della CA che fa
prorio queste cose e Patrol della BMC ( come modulo di conoscenza ).
http://www.bmc.com/corporate/nr1997/p02nj001.html
http://ne2.news.com/News/Item/0,4,6917,00.html
http://www.cai.com/products/dsm/automate.htm
http://www.cai.com/products/unicent/analyst2/ographic.htm
 ( esempio di
monitoraggio servers Exchange ).
Su ogni winzozzo ( ma anche sugli Unix ) c'e' un agente che monitorizza tutti
gli eventi e le anomalie vengono registrate su sistemi intelligenti ( ad ora
il database contiene 900.000 oggetti, ogni oggetto e' una grandezza che
influisce sulle performance della rete e delle macchine ). 900.00o oggetti
non sono tanti se si pensa che solo per monitorare i database 0racle ci sono
50 parametri. 
http://www.bmc.com/technews/982/982tn5.html
Tutto e' monitorato ( pc, routers, bridge, hubs e switch ).
Se una macchina lancia un processo e questo compromette la stabilita' del
sistema o ne riduce di parecchio le risorse mi arrivano ad una console gli
allarmi e possiamo decidere prima che il cliente si accorga del
malfunzionamento le azioni da intraprendere.
--
Ciaaaaaa ciaooooooooooooo :)
Gianluca Lubrano
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/
       Search, Read, Discuss, or Start Your Own    

Ricerca binaria. Credo che sia l'algoritmo piu' veloce che ci sia.
No, ne hanno fatto uno piu' veloce. Solo che devi avere almeno un
milione di rk...
Obelix

sondare se puo' interessare qualcuno di questo NG.
Sarebbe interessante. Ma non ho esperienza di embedded ! E me ne
dispiace, vado pazzo per le macchine semplici che non hanno finestre
svolazzanti. 
Il mio sogno e' un game-boy con la tastiera.
L'informatica si diffondera tra le case, quando faranno un cd con
internet per la playstation ( e guarda che sono molto serio ).
Ciao

internet per la playstation ( e guarda che sono molto serio ).
Vedi annuncio Microsoft di un accordo con la Sega per portare CE sulle
console. Adesso non mi chiedere il link, perche' il sito microsoft e' una
casba


casba
Ci credo. Sapevo che l'IBM urlo' al monopolio quando la sega ( o la
nintendo ) tento' di montare una tastiera alla propria consolle ad 8
bit ...
A proposito lo sapevi che la playstation prevede card da 8MB ?
Che aspetta la sony  ad attaccarci 
- un modem
- una tastiera
- una stampnate 
e a tirarci fuori un WP ?
Il giorno dopo la M$ fallira' ....

Il giorno dopo la M$ fallira' ....
Non ci giurare.


Non ci giurare.
Beh' ci posso sperare :))