Discussion :

[wafiwafi]

Bonjour, une petite question pour laquelle j’aimerais avoir vos réponses.
L’utilisateur a une vision sur le partage de la mémoire en segments :
Il existe différents types de segments :
• Les segments de données statiques
• Les segments de données globales
• Les segments de code
• Tas
……
1- je sais qu’à ce niveau, il s’agit d’un adressage logique. Ce qui m’intéresse c’est de savoir si cette séparation en segments est physiquement respectée dans l’implémentation dans la mémoire physique.
2- le compilateur tient compte de cette segmentation dans la production du fichier en langage machine même s’il s’agit d’adresses logiques. Qu’en pensez vous ?
3-

La segmentation permet la séparation des données et du programme (entre autres segments) dans des espaces logiquement indépendants facilitant alors la programmation, l'édition de liens et le partage interprocessus. La segmentation permet également d'offrir une plus grande protection grâce au niveau de privilège de chaque segment

Cela me prouverait que le compilateur tient compte de la segmentation puisque l'éditeur de lien l'utilise!

La segmentation permet également d'offrir une plus grande protection grâce au niveau de privilège de chaque segment

Ce qui prouverait que la segmentation est tenue en compte dans l'exécution!


Merci à vous

[Invité]

Bonjour,
Ceci est juste mon avis.
Dans les machines actuelles, un grand nombre de processus peuvent s'exécuter en même temps et sans aucune intervention extérieure.
Lorsqu'un processus se lance, une "certaine" mémoire lui est réservée. Donc, théoriquement, que le programme s'exécute correctement ou non, il ne devrait jamais sortir de cette zone qui lui a été allouée. Malheureusement il s'avère que de temps en temps un programme "plante" la machine. Cela signifie naturellement que ce programme fautif a été mettre son nez là où il ne devait pas.
Corollaire, je pense que c'est en utilisant ce principe que des gens malveillants arrivent à faire faire n'importe quoi aux machines.
Je suis sûr que des spécialistes système expliqueront tout cela bien mieux.
Cordialement.

[wafiwafi]

Bonjour,
Ok. Néanmoins, cela ne répond pas à la question posée et qui concerne la segmentation.
Cordialement

[Invité]

Je pense qu'au niveau de la compilation et de l'édition de lien, la segmentation est un problème secondaire.
La compile et l'édition de lien fabriquent un exécutable qui sera utilisé par d'autre machines même si la structure et l'organisation de la mémoire est différente, tant qu'on rentre dans un cadre donné.
A la question "la segmentation est-elle physiquement respectée", à mon avis certainement pas. Déjà ce n'était pas vrai il y a 30 ans, c'est ce qui distinguait à l'époque les ordinateurs des calculateurs à adressage fixe.
Au moment du lancement, puis de l'exécution d'un programme, la machine dispose d'une certaine quantité de mémoire, à un instant t. Presque toute la mémoire disponible est disponible pour le programme. A cet instant t la segmentation est définie, mais connue seulement par la machine. A l'instant t+1, la segmentation sera certainement différente, d'autres processus seront lancés, la mémoire nécessaire pour le programme sera différente, etc.

Mais seul un spécialiste système pourra donner des réponse plus précises et plus détaillées.

[wafiwafi]

A cet instant t la segmentation est définie, mais connue seulement par la machine. A l'instant t+1, la segmentation sera certainement différente

Que veux tu dire par là? Je ne parle pas des inter-processus! c'est une affaire du SE.

Soit un processus P1, dans le cas d'une pagination segmentée, ce dernier peut avoir les segments cités éparpillés sur les pages. Un segment donné, par exemple, peut s'étaler sur plusieurs pages.
En fait, j'ai du mal à admettre qu'une segmentation est intéressante pour l'éditeur des liens par exemple et à la fin, conclure, qu'en fait, qu'elle n'est plus là dans l'exécutable. Dans ce cas, c'est l'anarchie totale dans le fichier binaire produit. D'autre part, en dehors de la structure du gestionnaire de la mémoire, l'exécutable peut tourner sur tous, ou presque, les processeurs courants.

En tout cas, je vais méditer sur ce que tu m'as écrit en reprenant mes notes sur la gestion de la mémoire en assembleur que j'ai déjà eu l'occasion de bien étudier; le problème c'est que cela fait une vingtaine d'année.
Merci à toi

[Invité]

Entre temps, j'ai pensé à une façon de le visualiser.
Si, dans le programme, on imprime la valeur d'une adresse, un pointeur en particulier (format %p). Entre deux exécutions, à moins de se trouver strictement dans les mêmes conditions de mémoire, l'adresse, donc la position physique de la variable sera normalement différente.
Ce n'est pas pour autant que c'est l'anarchie dans le binaire. Au lancement du programme, celui-ci a une adresse 0 logique et une adresse A physique. Tout se passe par translation d'adresses. Quant il faut allouer une zone mémoire, la machine (et non le programme) se débrouille.
Il est fort probable et même certain, qu'avec un programme évolué, ce que permet le C++, à un instant donné où aucune fenêtre n'est ouverte, aucun traitement en cours, sauf l'attente d'un évènement, la partie du programme résident en mémoire est réduite au minimum. Quand l'utilisateur active un menu, ouvre une fenêtre, le programme se met à travailler et charge ce dont il à besoin.
Ce n'a rien à voir avec les dll, dont le but principal est de pouvoir adresser les mêmes parties de binaire à partir de plusieurs exécutable différents. Mais là je ne connais pas les détails.
Bonne réflexion pour le week-end