Segmentation : Segments de taille variable ?

Papouille wrote:

Je n'ai pas les idéés claires sur la raison d'exister des segments, et
du mécanisme de segmentation en général.

Il n'y a pas de segmentation de mémoire en Win32
Chaque process s'exécute dans son propre espace d'adressage

Christian ASTOR a écrit :

Papouille wrote:

Je n'ai pas les idéés claires sur la raison d'exister des segments, et
du mécanisme de segmentation en général.

Il n'y a pas de segmentation de mémoire en Win32
Chaque process s'exécute dans son propre espace d'adressage

Oui, mais en théorie la segmentation est propre a chaque process. Donc
en Win32, vous voulez dire qu'il n'y a pas de segment de stack, de data
et de code indépendant pour chaque process ?

On 19 jan, 10:08, Papouille <Papoui...@papouille.net> wrote:

> Il n'y a pas de segmentation de mémoire en Win32
> Chaque process s'exécute dans son propre espace d'adressage

Oui, mais en théorie la segmentation est propre a chaque process. Donc
en Win32, vous voulez dire qu'il n'y a pas de segment de stack, de data
et de code indépendant pour chaque process ?

MSDN =>
"each process has a private 32-bit address space from which all of the
memory for the process is allocated--including code, resources, data,
DLLs (dynamic-link libraries), and dynamic memory. "

Après, ça dépend ce que tu appelles "segment".
Les pages de 4K pour le paging de la mémoire virtuelle, ça s'appelle
aussi des "segments de 4K"...

Christian ASTOR a écrit :

On 19 jan, 10:08, Papouille <Papoui...@papouille.net> wrote:

Il n'y a pas de segmentation de mémoire en Win32
Chaque process s'exécute dans son propre espace d'adressage

Oui, mais en théorie la segmentation est propre a chaque process. Donc
en Win32, vous voulez dire qu'il n'y a pas de segment de stack, de data
et de code indépendant pour chaque process ?

MSDN =>
"each process has a private 32-bit address space from which all of the
memory for the process is allocated--including code, resources, data,
DLLs (dynamic-link libraries), and dynamic memory. "

Après, ça dépend ce que tu appelles "segment".
Les pages de 4K pour le paging de la mémoire virtuelle, ça s'appelle
aussi des "segments de 4K"...

J'appelle segment un espace d'adresses virtuelles assigné à un type de
données homogènes : un segment peut contenir soit du code, ou un tableau
de données (ex: une table des symboles si le programme est un
compilateur), ou une pile, ou une collection de données scalaires, mais
normalement ne contient pas un mélange des différentes données.

Les tailles des segments varient d'un programme à l'autre, ce qui n'est
pas le cas des pages qui ont des tailles fixes.

Bref, il s'agit d'un espace mémoire à plusieurs dimensions, dont le
programmeur peut être conscient, ce qui n'est pas le cas de la
pagination, qui est totalement transparent au programmeur....

Dans le MSDN que vous citez, j'y vois moi la définition de l'espace
d'adresses virtuelles. Dans cet espace il pourrait y avoir plusieurs
segment : un pour le code, l'autre pour les données, l'autre pour le code.

Un programme windows au format PE contient des segments "text", "rdata",
"idata", "reloc".... donc pourquoi dites-vous qu'il n'est pas segmenté ?

Ce n'est pas la première fois que je lis que Windows n'utilise pas la
segmentation autorisé par un microprocesseur comme le pentium, mais je
voudrais ne pas prendre cela comme argent comptant et voudrais
comprendre....

On 23 jan, 22:29, Papouille <Papoui...@papouille.net> wrote:

Dans le MSDN que vous citez, j'y vois moi la définition de l'espace
d'adresses virtuelles. Dans cet espace il pourrait y avoir plusieurs
segment : un pour le code, l'autre pour les données, l'autre pour le cod e.

C'est le "flat memory model" en Win32 par opposition au "segmented
memory model" en 16-bits

En résumé : http://www.jps.at/dev/kurs/2-1.html
ou détaillé : doc Intel
"The flat memory model is Intel architecture's answer to "No more
segmentation."" :
http://download.intel.com/design/intarch/papers/esc_ia_p.pdf
ou MSDN :
http://www.microsoft.com/technet/archive/winntas/training/ntarchitectoview/n tarc_7.mspx?mfr=true

Christian ASTOR a écrit :

C'est le "flat memory model" en Win32 par opposition au "segmented
memory model" en 16-bits

Oui, pas de de doute, c'est bien le flat memory model. ça fonctionne
bien... mais il n'y est pas question de segmentation là. Ma question
porte sur la taille des segments lors des mécanismes de segmentation.

En résumé : http://www.jps.at/dev/kurs/2-1.html

Oui, ça je sais ce que c'est ... mais ce sont les segments qui
m'intéressent....

ou détaillé : doc Intel

J'ai les documents détaillés d'Intel. Rien de ce que j'ai déjà lu me
confirme que la taille des segments varie en cours d'exécution.

http://download.intel.com/design/intarch/papers/esc_ia_p.pdf
ou MSDN :
http://www.microsoft.com/technet/archive/winntas/training/ntarchitectoview/ntarc_7.mspx?mfr=true

Oui, je connais la programmation en flat memory model, mais sur des
microcontrôleurs qui ne gèrent pas la segmentation. Mais le sujet du fil
concerne la segmentation...

"Papouille" <Papouille@papouille.net> wrote in message
news:4798E166.1080606@papouille.net...

Oui, je connais la programmation en flat memory model, mais sur des
microcontrôleurs qui ne gèrent pas la segmentation. Mais le sujet du fil
concerne la segmentation...

J'ai l'impression que ca concerne plutot la spécialisation des segments.
Et effectivement sous Windows, je ne crois que le system utilise une
segmentation pour protéger le code, les données, les constantes etc... et à
l'intérieur d'un process tout est dispo de partout sur l'espace d'adressage
de ce process.

VB

Papouille <Papouille@papouille.net> wrote in
news:4798E166.1080606@papouille.net:

Christian ASTOR a écrit :

C'est le "flat memory model" en Win32 par opposition au "segmented
memory model" en 16-bits

Oui, pas de de doute, c'est bien le flat memory model. ça fonctionne
bien... mais il n'y est pas question de segmentation là. Ma question
porte sur la taille des segments lors des mécanismes de segmentation.

Sur les archis x86 ça donne à peu près ça (à quelques entorses près) :

Au bon vieux temps des 8086, les registres faisaient uniquement 16 bits.
Il y avait 4 registres de calcul principaux (AX, BX, CX, et DX) qu'on
pouvait séparer en deux moitiés de 8 bits (AX = AH-AL, BX=BH-BL...) pour
effectuer des opérations diverses. Il y avait aussi quelques registres
système comme IP le pointeur d'instruction (instruction pointer) qui
indiquait au microprocesseur l'adresse de la prochaine instruction a
exécuter, et SP le pointeur de pile (stack pointer) qui était utilisé
pour marquer le haut de la pile d'appels (qui était en réalité le bas de
la pile, celle-ci étant inversée).

En ces temps là, le bus mémoire avait été agrandi à 20 bits. Comme 20
bits c'était pas très pratique à adresser avec des registres qui
n'étaient pas plus grand que 16 bits (probablement que ce fut plus facile
de rajouter des câbles à un bus que de modifier l'architecture d'une
puce, je n'en sais rien je n'étais pas encore né) les concepteurs ont
alors imaginé un mode dit "segmenté" dans lequel les pointeurs mémoire
sont constitués de deux registres, l'un appelé sélecteur de segment (CS,
DS, SS...) et l'autre le décalage "offset" (IP, SP...).

Le couple sélecteur:offset formait alors un couple qui déterminait
l'adresse mémoire complète. Un tel exemple est CS:IP, itilisé pour
connaître l'adresse de la prochaine instruction à exéciter. SS:SP était
utilisé pour connaître l'adresse du haut de la pile d'appels, et DS
combiné aux registres de calcul permettait de lire et d'écrire dans la
mémoire.

La transformation effectuée par les composants pour obtenir l'adresse
physique (sur 20 bits) à partir du couple sélecteur:offset est :
adresse_physique = sélecteur * 16 + offset.

Un des grands avantages des segments est que cette technique permet
d'adresser des quantités toujours plus grandes de mémoire tout en
conservant des registres de petite taille. L'exemple des 20 bits de
mémoire adressés grâce à un registre de 16 bits seulement illustre bien
ça. Il faut garder à l'esprit que plus le nombre de bits augmente, plus
les opérations (additions, soustractions...) sont chères. Il est
probablement plus efficace d'adresser 20 bits avec un registre fixe de 16
bits, et un registre variable de 16 bits, plutôt que de créer un registre
variable de 20 bits.

L'autre avantage des segments est qu'ils rendent possible la création
d'espaces mémoire distincts pour le code, les données, la pile etc. Les
sélecteurs CS, DS, SS pouvant être distincts, chacun dispose de son
propre espace mémoire. Evidemment, sur le 8086 les segments se
chevauchaient. Mais plus tard avec l'apparition de techniques telles que
la mémoire paginée, himem, ou le mode protégé, cette notion a été
généralisée.

Aujourd'hui avec les progrès réalisés en architecture, je pense que cette
notion va disparaître. D'abord il y a très peu de systèmes d'exploitation
et de compilateurs qui utilisent pleinement cette fonction. Ensuite il y
a d'autres techniques plus simples comme la mémoire virtuelle.

Voilà, si tu cherches dans les archives de ce groupe (vers 2001-2002) je
pense que tu trouveras des discussions intéressantes d'AMcD, d'autres
contributeurs et de moi-même sur le sujet.

A+
--
Cyrille Szymanski

Cyrille Szymanski a écrit :

ça. Il faut garder à l'esprit que plus le nombre de bits augmente, plus
les opérations (additions, soustractions...) sont chères. Il est
probablement plus efficace d'adresser 20 bits avec un registre fixe de 16
bits, et un registre variable de 16 bits, plutôt que de créer un registre
variable de 20 bits.

Intéressant, oui. Je n'avais pas envsagé cela : Gain de performance donc...

L'autre avantage des segments est qu'ils rendent possible la création
d'espaces mémoire distincts pour le code, les données, la pile etc. Les
sélecteurs CS, DS, SS pouvant être distincts, chacun dispose de son
propre espace mémoire. Evidemment, sur le 8086 les segments se
chevauchaient. Mais plus tard avec l'apparition de techniques telles que
la mémoire paginée, himem, ou le mode protégé, cette notion a été
généralisée.

OK, mais mis-à-part deux choses :
- posibilité de partager des segments avec d'autres processes
- possibilité de définir des conditions d'accèes propres à chaque segment

... je ne vois pas l'utilité de faire des séparations logiques entre
type de données. Si c'est pour que chacun ait son propre espace mémoire,
alors c'est limité comme avantage puisque le linker pourrait
s'occuper de tout mettre dans un seul espace mémoire sans que l'on ait
besoin d' inventer les registres de segment.

Aujourd'hui avec les progrès réalisés en architecture, je pense que cette
notion va disparaître. D'abord il y a très peu de systèmes d'exploitation
et de compilateurs qui utilisent pleinement cette fonction. Ensuite il y
a d'autres techniques plus simples comme la mémoire virtuelle.

Voilà, si tu cherches dans les archives de ce groupe (vers 2001-2002) je
pense que tu trouveras des discussions intéressantes d'AMcD, d'autres
contributeurs et de moi-même sur le sujet.

Merci beaucoup

A bientôt

Papouille <Papouille@papouille.net> wrote in
news:479e5c56$0$27485$426a74cc@news.free.fr:

Cyrille Szymanski a écrit :

ça. Il faut garder à l'esprit que plus le nombre de bits augmente,
plus les opérations (additions, soustractions...) sont chères. Il est
probablement plus efficace d'adresser 20 bits avec un registre fixe
de 16 bits, et un registre variable de 16 bits, plutôt que de créer
un registre variable de 20 bits.

Intéressant, oui. Je n'avais pas envsagé cela : Gain de performance
donc...

Non, j'ai dit que c'était probablement plus performant, c'est vrai, mais
pas que les concepteurs l'avaient fait pour ça (je n'en sais rien du
tout, je pense que la segmentation existait déjà bien avant...)

J'imagine que ça coûte très cher d'augmenter la taille des registres (car
il faut alors créer de nouveaux jeux d'instructions, câbler de nouvelles
opérations logiques etc. bref c'est du boulot). Alors comment adresser
plus de 2^16 octets quand on est limité à 16 bit par registre ?

Les segments, c'est à dire utiliser deux registres, c'est une solution
(ex: 8086). La pagination c'en est une autre (ex: himem, XMS, vesa...).
Attendre l'apparition de registres plus grands en est encore une autre
(ex: la limite des 4Go de RAM et l'apparition de machines 64 bit).

... je ne vois pas l'utilité de faire des séparations logiques entre
type de données. Si c'est pour que chacun ait son propre espace
mémoire, alors c'est limité comme avantage

Personnellement je trouve que ça fait déjà beaucoup d'avantages même si
c'est vrai, comme dit plus haut, ils sont de moins en moins évidents et
pas forcément utilisés à fond par les systèmes.

Au fond, je ne comprends pas ce qui pose problème ou ce qui n'est pas
clair.

--
Cyrille Szymanski