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

[wafiwafi]

Bien vu! Je suis maintenant convaincu que toute cette segmentation peut être purement conceptuelle et que l'éditeur de lien peut transformer les segments conceptuels en adressage linéaire puis ensuite filer le bébé à la plate-forme OS/ matériel.
Il n'y a pas de doute!!
Je te remercie en tout cas d'avoir déclenché cette piste de réflexion.
Bon week-end mérité.
Bien à toi

[wafiwafi]

ET oui je reviens avec la réponse. J'aimerais avoir vos avis.

Voila le lien considéré :
http://deptinfo.cnam.fr/Enseignement...ire/gestio.htm

Cette notion de mémoire segmentée peut ou non être prise en compte par le matériel. Lorsqu'elle ne l'est pas, l'éditeur de liens ou le chargeur place les segments dans un espace linéaire, avant de lancer l'exécution du processus.Ce placement est alors statique, et la taille des segments est souvent invariable.
Certains matériels prennent en compte un tel espace, en assurant dynamiquement la traduction d'une adresse segmentée en une adresse dans un espace linéaire, au moyen de tables spécifiques qui contiennent les informations de localisation de chaque segment, encore appelés descripteurs de segment.

Dans cette citation, il y a le passage :

Ce placement est alors statique, et la taille des segments est souvent invariable.

Pourquoi parle on de segments alors qu'il ne doit pas y avoir dans ce cas.

Voici quelques exemples de processeurs disposant de l'adressage segmenté:

* Dans Multics, un processus peut avoir 32768 segments, chacun des segments pouvant atteindre 256 Kmots de 36 bits.
* Dans l'intel iAPX286 (le processeur des PC-AT), la table des descripteurs de segments d'un processus est divisée en deux parties, une table des segments communs à tous les processus, et une table propre à chaque processus. Chacune de ces tables peut avoir 8192 segments, et chaque segment peut avoir jusqu'à 64 Koctets. La mémoire linéaire est la mémoire physique, et peut atteindre 16 Moctets.
* L'intel iAPX386 (et suivants) est assez voisin de l'iAPX286, du point de vue adressage segmenté, si ce n'est que les segments peuvent atteindre 4 Goctets. La mémoire linéaire peut atteindre 4 G octets et peut, de plus, être paginée (voir ci-dessous).

Pour les spécialistes du C++, serait il possible de savoir où se situe ce langage par rapport à la segmentation, est ce que son partage descend côté matériel ou c'est purement conceptuel ????

[Davidbrcz]

La segmentation est une question liée à l'OS et sans doute aux outils que tu vas utiliser. Le C++ "pur" n'a pas notion de segment, de pagination ou what ever. Au mieux on dispose de la notion de "données contiguës en mémoire".

La question est donc à déplacer dans un autre forum (OS sans doute).

[peufeu]

Quand tu fais de la prog "standard" tu n'as pas à te soucier des segments, le compilateur et le linker s'en occupent pour toi.

Si tu linkes en mode PIC (Position Independent Code, lors du chargement du programme, le loader ajuste toutes les adresses dans ton code compilé pour que ça aille bien, quelles que soient les adresses des différents segments. Si tu linke pas en mode PIC, tu auras des adresses en dur.

Dans tous les cas, les appels à des libraries partagées (donc chargées à des adresses non déterminées à l'avance) sont remplacés par les bonnes adresses au chargement de l'exécutable.

Une chose à savoir cependant : quand un segment est marqué en lecture seule, il est chargé par l'OS dans des pages marquées en lecture seule, donc le CPU est au courant, et par exemple si tu as plusieurs cores, le core 1 sait que le core 2 n'est pas en train de modifier ces données là pendant qu'il les lit, ce qui économise beaucoup d'opérations de synchronisation inter-core ou inter-CPU et permet de ne pas perdre de temps.

En embarqué, c'est différent. Par exemple sur un FPGA j'avais une plateforme avec un CPU tout pourri (Microblaze), 16 Ko de RAM statique rapide (1 cycle) et plusieurs Mo de Flash très lente (14 cycles).

Avec plusieurs dizaines de Ko de code d'init (sert qu'une fois, rapidité pas importante) et de debug, plus printf() qui prend plus de 10 Ko, le logo pour le LCD, etc, il faut bien savoir où tu mets tes segments...

Dans ce cas, tu expliques au compilateur dans quel segment doit aller quelle fonction (GCC a des macros pour ça) et ensuite tu configures le linker pour que le segment qui contient les petites fonctions utilisées fréquemment soit chargé à une adresse fixe qui correspond à de la RAM rapide, et les gros machins utilisés rarement soient dans la mémoire lente.

En résumé, si tu fais de l'embarqué sur un système avec tellement pas de RAM que ça rentre qu'avec un chausse-pied lubrifié, c'est important de savoir écrire un script de linker, sinon c'est un peu de la culture générale...

[wafiwafi]

Le C++ "pur" n'a pas notion de segment,

avec tout mon respect :
et qu'est ce que tu fais de segments de données, de code, tas et compagnie même si cela reste conceptuel et n'intervient pas dans la programmation.
C'est une vision fournie à l'utilisateur tout de même!.

Quand tu fais de la prog "standard" tu n'as pas à te soucier des segments, le compilateur et le linker s'en occupent pour toi.

Je le sais. C'est juste une curiosité! néanmoins, j'aimerai bien avoir une réponse à cela!

Si tu linkes en mode PIC (Position Independent Code, lors du chargement du programme, le loader ajuste toutes les adresses dans ton code compilé pour que ça aille bien,

Je comprend par cela que les segments cités peuvent être considérés par le compilateur et le linker et pourquoi pas garder cette représentation en segments dans la gestion de la mémoire physique. je parle d'une possibilité!. C'est le genre de réponse que j'aimerais avoir car tout ce qui a été dit est super intéressant mais aucune réponse n'ose confirmer la possibilité de l'existence de ce que j'ai avancé.
Le truc simple par exemple: le code est considéré regroupé, de façon contiguë, dans un espace mémoire logique (pour ne pas dire segment de données) par le compilateur et le linker; ce même code est regroupé en segment en mémoire physique si le matériel le permet. c'est aussi simple que cela. Je n'arrive pas à avoir une réponse directe!!!

En tout cas, un grand Merci à vous

[gl]

et qu'est ce que tu fais de segments de données, de code, tas et compagnie même si cela reste conceptuel et n'intervient pas dans la programmation.

Je n'ai pourtant pas souvenir d'avoir vu ces notions dans la norme C++.

C'est le genre de réponse que j'aimerais avoir car tout ce qui a été dit est super intéressant mais aucune réponse n'ose confirmer la possibilité de l'existence de ce que j'ai avancé.
Le truc simple par exemple: le code est considéré regroupé, de façon contiguë, dans un espace mémoire logique (pour ne pas dire segment de données) par le compilateur et le linker; ce même code est regroupé en segment en mémoire physique si le matériel le permet. c'est aussi simple que cela. Je n'arrive pas à avoir une réponse directe!!!

Si tu n'as pas de réponses directes et simples à ces questions, c'est peut être tout simplement car il n'y en a pas.

Comme l'ont précédemment fait remarquer Davidbrcz et peufeu, la segmentation et la pagination sont des notions dépendantes de la plateforme et de l'OS. La réponse est donc variable en fonction de l'environnement concerné.

[wafiwafi]

Merci pour ta réponse.

Je n'ai pourtant pas souvenir d'avoir vu ces notions dans la norme C++.

J'ai vu un livre du C++ dont le titre m'échappe, et d'autres cours, qui présentent ce schéma de segments pour l'utilisateur. Il n'y a qu'à se souvenir du segment qui héberge la pile pour les variables locales globales....
Donc cette séparation conceptuelle en zones existe bien en C++.

Pour le reste, tu as peut être raison; le compilateur/linker doivent s'adapter à l'OS tout simplement.
Cordialement

[Davidbrcz]

Je précise ma réponse précédente. Tu vas trouver dans le C++ notions de "données allouées sur la pile" , "sur le tas", "données statiques" et enfin "données contiguës en mémoire"

Mais ces notions sont des garanties que le langage apporte au programmeur au niveau de la portée des variables (principalement).

Derrière, comment c'est géré, c'est dépendant de chaque architecture.

Sur un PC classique, tout est mis en RAM et c'est l'OS qui gère le tout. Mais on peut imaginer (et je crois qu'il a existé, je ne préfère ne pas trop m'avancer) des systèmes où il y avait un type de mémoire différent pour chaque besoin.

Mais dans tous les cas, ce sont des détails qui sont cachés par l'OS.
Si tu veux mettre les mains dans le cambouis, il faut faire de l'ASM.

[wafiwafi]

Oui; c'est bien clair.
C'est purement Conceptuel! C'est super important pour le pointage par exemple: on ne peut pas pointer ce qu'on veut comme on veut.
Je mets le sujet résolu.
Merci beaucoup

[Davidbrcz]

C'est purement Conceptuel! C'est super important pour le pointage par exemple: on ne peut pas pointer ce qu'on veut comme on veut.

?

Tu peux créer un pointeur sur ce que tu veux. Après, il faut faire attention à la durée de vie et à sa destruction (ou pas, justement) d'où les risques classiques liés aux pointeurs mais qui ont presque totalement disparu du C++

[Joel F]

Si tu veux mettre les mains dans le cambouis, il faut faire de l'ASM.

Et encore, y a pas mal de chose pour lesquelles on n'a pas de contrôle directe (je pense à la MMU et autre joyeusetés). Le principe de l'adressage mémoire virtuelle et justement de pas à chercher à gérer ces trucs casse-peids par soit même.

[Invité]

Bonjour,

d'où les risques classiques liés aux pointeurs mais qui ont presque totalement disparu du C++

Les mots clé new et delete seraient donc obsolète?
Je dois être drôlement en retard

[Jean-Marc.Bourguet]

Il y a au moins trois notions différentes mais pas indépendantes de segments.

Tout d'abord le segment peut etre une unite utilisee par l'edition de liens. Celui-ci mettra alors de maniere contigue en memoire ce qui fait partie d'un meme segment et un compilateur peut offrir comme extension le moyen de controler ce qui va dans quel segment ou faire une assignation par defaut.

L'OS peut avoir sa notion de segment, zone de memoire contigue qui est geree d'un bloc (p.e. tout le segment est swappe sur disque en meme temps, la gestion des droits -- ecriture/lecture/execution/... se fait par segment, etc). Si l'OS a une notion de segment, il y a de forte chance que d'editeur de liens aussi. De toute maniere, il va falloir repartir le programme en segments pour l'OS (un segment de l'OS correspondant a un ensemble de segment pour l'editeur de liens; je ne vois a priori aucun sens a decouper un segment de l'editeur de liens en plusieurs segment de l'OS). Cette construction de la gestion de la memoire l'OS en segment s'oppose a une vision paginee ou la memoire est decoupee en pages de taille fixe plutot qu'en segment de taille variable et ayant une unite logique. Naturellement, un OS peut melanger les deux visions si ca lui convient.

Troisieme notion, celle du processeur (ou d'une couche supplementaire de hard). Il s'agit de decouper les adresses logiques en deux parties: le segment et l'offset et d'appliquer un controle de validite sur le type d'acces et l'offset en fonction du segment. Dans les cas les plus connus, le segment est stocke dans des registres speciaux. A nouveau, c'est en opposition avec une gestion de la memoire paginee ou la memoire est decoupee en pages de taille fixe (ou d'un petit nombre de tailles possibles). Et a nouveau, un processeur peut proposer les deux, de maniere combinee ou independante. Et un OS qui a une notion de segment ou de page va utiliser ce que fournit le processeur pour aider a son implementation -- ca me semble assez difficile, au minimum ce sera couteux, de fournir dans l'OS ce genre de concepts sans aide hard.

[Jean-Marc.Bourguet]

Les mots clé new et delete seraient donc obsolète?

Non, ils sont simplement un peu plus encapsule.

Il y a deux problematiques dans la gestion de la memoire. La definition d'une politique adaptee aux structures de donnees choisies et le respect de ces politiques.

L'utilisation de pointeurs intelligents permet de faciliter ce dernier point (au pire, juste en documentant dans le type quelle politique est utilisee, mais en pratique pas mal d'aspects peuvent etre geres automatiquement) pour pas mal de politiques.

Cette facilite d'implementation influence naturellement le choix des politiques lors de la conception. Cette influence est telle chez certains qu'ils n'envisagent meme plus de politiques en dehors de deux ou trois pour lesquelles ils ont deja le pointeur intelligent qui va bien.