Bonjour tout le monde  
 
Quelqu'un peut-il m'expliquer la différence entre un programme en mode réel sur 16 bits et un programme en mode protégé sur 32 bits ?  
 
ps: j'ai bien trouvé une définition mais je n'arrive pas a saisir correctement, donc si quelqu'un peut m'expliquer a sa maniére ce serait sympa

disons que'en mode réel tu fais tout ce que tu veux au niveau hardware (genre instructions privilégiés et tout) tandis que le mode protégé permet de separer les applications et l'os, et permet aussi le multitasking.

Mouais disons que le mode réél (16 bits) est le mode par defaut du processeur et te permet d'avoir des interraction avec le BIOS (te servir des interruption en gros). Dans ce mode la memoire est gerée par segment de 64ko (16bits), et tu en as 16 a dispo --> 1024 ko donc 1 Mo et pas plus. En mode protégé (32 bits) adieux le BIOS et les interruption, par contre tu as accès à la totalité de ta mémoire en 32 bits , mais ça seulement si tu as initialisé des sélecteur et registres spéciaux. Tu peux aussi faire de la segmentation et de la pagination.
Attention le mutitasking n(est pas automatique et la "séparation" des appli se fait par niveaux de privilège que tu doit gerer.Et tu peux aussi faire ce que tu veux au niveau hardware, sauf que c plus dur.

Bonjour
puisqu'il s'agit de programme, la différence au niveau mnémonique sera assez grande par contre la différence au niveau héxadécimale sera légère dans le cas où l'ensemble des variables ne dépasse pas 64Ko et l'ensemble du code ne dépasse pas 64Ko. Si on dépasse la barrière des 64Ko pour le code et / ou les données la différence sera sensible et le codage plus compliqué en mode 16 bits réel car il faut jouer avec les segments
Il n'y a pas 16 segments de 64Ko mais 64K segments de 64 Ko avec énormément de recouvrement entre eux et de toute façon 1024Ko avec possibilité d'utiliser un segment de 64Ko -16 au dessus de 1 Go
Cordialement

db_ tu les sort d'ou tes 64K segment ??
Tu sais que le calcul d'adresse en mode réél est le suivant :
 
segment: offset ---> adresse réelle = segment<<4 + offset  
 
Donc meme si tu as 64k possibilités pour le segment tu n'as de toute facon que 16  segment de 64k  different

oki, merci beaucoup a vous tous!

les registres de segment font 16 bits donc 64K combinaisons d'adresses possibles donc autant de segments. Comme je l'ai précisé, il y a énormément de recouvrement. Il n'empèche que à quelques adresses près, il y a une multitude de façon d'exprimer par un couple segment:pointeur la même adresse physique.
Tu as le droit dans ta pratique courante de n'utiliser que 16 segments de 64Ko, certains ne le font pas, chacun son style.

Effectivement db__ il y a du recouvrement, c le nombre qui m'avait choqué.
Par contre je ne comprend pas quand tu dis "avec possibilité d'utiliser un segment de 64Ko -16 au dessus de 1 Go"
Y'a peut etre un truc a apprendre

C'est un vieux défaut datant du 80286 si mais souvenir sont bons. Lorsque l'on charge un registre de segment avec la valeur 0ffffh, sur les machines adressant plus de 1024Ko, les 64Ko - 16 au dessus sont accessibles au lieu de revenir vers les adresses basses physique.
De nos jours cela ne sert plus à grand chose.

Oui mais ça parait logique en fait, pas sur que ça soit un defaut. Quoi qu'il en soit c sur que l'utilité n'est pas evidente

Ah là là, ces jeunes : aucune culture informatique. Sortis des SMS pour la Starac et des MP3 de Ilona, ça va pas loin...
 
   http://google.com/search?q=a20+gate

le mode réel est le mode historique du 80x86 où l'adressage physique est issu de la construction des deux mots de 16bits segment : offset avec adressage physique = segment<<4+offset.
 
ceci pour réduire le coût du CPU, et la taille des instructions:référencement implicite à un registre de segment => instructions potentiellement toujours avec offset 16btis etc... alors qu'ils aurait pur designer un cpu à adressage linéaire 32bits dont les 12bits supérieurs étaient non cablés un peut partout. (un peu comme l'était le 68K et l'est actuellement l'Athlon 64).
 
bref c'est le passé, le PC traine son histoire.
 
après est venu le 386 qui est passé en adressage 32bits avec le mode protégé. mais les segments ont étés conservés pour permettre au MMU de séparer clairement le code des données, et de renforcer la sécurité au niveau hardware.
 
en conclusion:
 
en mode réel, la construction segment : offset est un compromis en complexité hardware, et une plaie au niveau software pour nous les programmeurs.
 
en mode protégé, la construction segment : offset existe entre  "" toujours, mais le segment sert à pointer sur un descripteur qui décrit au MMU une couche hardware de droits d'accès aux données couvertes par le segment.  
d'un point de vue programmation ça nécessite un peu de boulot (pour les concepteurs d'OS et la création de contexte de process), mais hormis le boulot nécessaire ce n'est que des avantages, et plus vraiment de désavantages pour le programmeur d'application final.
 
en contraste, si on prends cette époque, soit entre 1980 & 1985-88, quand on mets un 68000 face à un 8086, le 8086 se fait oblitérer par le 68K (amiga/atari/mac vs PC), mais quand tu mets un 386 face au 68K sans mmu, c'est le 386 qui gagne haut la main:
 
le mode protégé permet une isolation de contexte des process par voie hardware grâce au MMU+segmentation en mode protégé, le système de swap / allocation optimale des ressources mémoires grâce à la pagination, + chose qui n'on rien à voir avec le mode protégé mais qu'il convient de noter:
 
les capacitées calculatoires en entier pour la 3D vu que sur le 68K un mul c'est 16bits x 16bits => 32bits, et sur un 386 un mul, c'est 32bits x 32bits => 64bits, la réciproque pour les div, ceci étant très utile pour les calculs d'incréments pour le traçage de polygone, etc...  
 
malheureusement le DOS étant en mode réel, il a ralenti l'évolution du software par rapport au hardware, et il y eu des solutions batardes offertes par microsoft (himem/emm386), pour beaucoup de programmeurs nécessistant un truc praticable pour des choses un peu poussées, le salut est venu par les DOS-Extenders qui permettait d'utiliser une application en mode protégé sous le DOS en mode réel. (parmi les plus aboutis: PMODE, DOS/4G, etc.. etc...)
---
 
donc pour en revenir au sujet "mode réel vs mode protégé", le mode réel c'est plus datant de l'époque cpu basique & cheap (où motorola maitraisait intel je dirais, vu que le 68K a débarqué sensiblement plus tôt que le 80386), et le mode protégé c'est plus l'époque de la maturité, où un défaut est presque transformé en qualité. (la saloperie de segmentation qui se transforme en assistance en protection grâce au MMU pour les OS multi-tâches, etc...).

le 286 ayant un mode protégé dont je ne connais pas les restrictions (notemment je suppose que l'offset est toujours sur 16bits vu que les GPRs étaient toujours sur 16bits, donc ça devait être assez pourri dans la pratique, mais ye ne sais po ye l'avoues ).

 
Sauf qu'a part dans le developpement de mon OS je ne l'ai jamais implémenté , donc utilité peu évidente dans un autre contexte    
 
C 'est koi la starac , une nouvelle unité de traitement de la memeoire des proc Intel ?  

Bonjour
Lors de la mise en service du 386, il a été rajouté 2 selecteurs de segments fs et gs. Ils ne sont hélas pas asseccibles en mode normal. Il n'y a donc pas moyen d'allouer de tableaux où le processeur ferait le contrôle de dépassement. Il y a bien une instruction pour faire cela mais elle déclenche une exception accessible seulement au mode privilégié donc inutilisable pour une application. Comme les OS ne permettent pas l'accès au détournement d'interruption, on ne peut pas utiliser les propriétés de la MMU pour contrôler les débordements et c'est dommage. Ceci est probablement du au fait qu'il n'existe qu'un seul numéro d'interruption pour toutes les fautes mémoires. On peut toujours espérer qu'un jour, on rajoute dans le descripteur de segment l'adresse du code à appeler en cas de faute de segmentation et un accès à la LDT en mode utilisateur.