Discussion :

[wafiwafi]

Je raisonne sur la base d’un processeur i386 / 32 bits.
Je m’intéresse au partage de la mémoire (vision utilisateur) fourni par :
Le segment de text (code) , segment de données initialisées DS, segment de données non initialisées (BSS), et notre chère pile (SS) qui contiendra les variables locales et une partie réservée au TAS. Le tas se situera aux adresses basses de cette pile; je ne vois pas l'intérêt de cette information à l'utilisateur, main bon!
Pouvez vous me confirmer les dires suivants :
Du côté de la gestion mémoire à bas niveau (exécution côté microprocesseur) ; on n’est plus à la vision utilisateur. Il faut raisonner en 3 segments :
Le segment du code CS ( qui contiendra la vision du segment text), le segment DATA (contiendra DS et BSS), la pile (contiendra la vision du SS). Tout cela géré par les pointeurs de piles.
Voila un petit rappel du côté assembleur :
Les registres se classent usuellement en 4 catégories :
1. registres généraux : %eax, %ebx, %ecx et %edx servent à la manipulation de données ;
2. registres de segment :%cs, %ds, %esx et %ss, sur 16 bits, contiennent la première partie d'une adresse en mémoire ;
3. registres d'offset : ils indiquent un décalage (offset) par rapport aux registres de segments :
o %eip (Extended Instruction Pointer) : indique l'adresse de la prochaine instruction à exécuter ;
o %ebp (Extended Base Pointer) : indique le début de l'environnement local d'une fonction ;
o %esi (Extended Source Index) : contient l'offset des données source dans une opération utilisant un bloc mémoire ;
o %edi (Extended Destination Index) : contient l'offset des données destination dans une opération utilisant un bloc mémoire ;
o %esp (Extended Stack Pointer) : le sommet de la pile ;

Mon avis :
La vision fournie à l’utilisateur est très approchée de la réalité par rapport à l’assembleur. La différence réside dans gestion de la pile qui ne respecte pas forcément le partage de cette dernière entre les variables locales (adresses supérieures) et le tas (adresses inférieures)… D’ailleurs, je ne vois pas l’intérêt de fournir à l’utilisateur cette dernière précision encore une fois! peut être qu’il s’agit de limiter le pointage afin de protéger les deux zones...
Il doit certainement exister des instructions (peu importe le langage) qui manipulent des adresses mémoires (utilisateur) qui correspondent à ces zones. Si oui, dans quel but ? sauf pour le tas peut être où il faut faire le ménage régulièrement.

La plage mémoire attribuée à une pile est forcément contigüe sauf si le segment grandit et là je pense que l’OS attribue un espace supplémentaire en utilisant les pointeurs ; pourquoi pas! J’ai dû lire cela quelque part.
Merci d’émettre vos critiques et d’apporter une contribution pour rendre plus claires les choses.
Merci à vous

[Melem]

Du côté (...) du processeur (...) Il faut raisonner en 3 segments :
Le segment du code CS (qui contiendra la vision du segment text), le segment DATA (contiendra DS et BSS), la pile (contiendra la vision du SS).

Il peut y avoir plusieurs segments, mais on n'a pas prévu autant de registres pour les pointer. Il y a aussi les registres ES, FS et GS qui ont le même rôle que DS.

Tout cela géré par les pointeurs de piles.

Hein ?

Les registres se classent usuellement en 4 catégories :

Tu dis quatre mais tu n'en cites que 3 ...

2. registres de segment :%cs, %ds, %esx et %ss, sur 16 bits, contiennent la première partie d'une adresse en mémoire ;

Cela n'est vrai qu'en mode 16 bits. En mode 32 bits, ces segments contiennent numéro d'identification d'un descripteur de segment. La taille d'un segment peut bien sûr se mesurer en octets mais aussi en pages (la taille en octets d'une page est définie par le système, sous Windows c'est 4 Ko). Un descripteur de segment contient entre autres, d'une certaine manière, l'adresse de départ du segment (32 bits) ainsi que sa taille (32 bits). Je ne connais pas de registre esx, que voulais-tu écrire à la place ?

Il y a aussi les registres de contrôle (CR0 et co.).

Mon avis :
La vision fournie à l’utilisateur est très approchée de la réalité par rapport à l’assembleur. La différence réside dans gestion de la pile qui ne respecte pas forcément le partage de cette dernière entre les variables locales (adresses supérieures) et le tas (adresses inférieures)… D’ailleurs, je ne vois pas l’intérêt de fournir à l’utilisateur cette dernière précision encore une fois! peut être qu’il s’agit de limiter le pointage afin de protéger les deux zones...
Il doit certainement exister des instructions (peu importe le langage) qui manipulent des adresses mémoires (utilisateur) qui correspondent à ces zones. Si oui, dans quel but ? sauf pour le tas peut être où il faut faire le ménage régulièrement.

Désolé mais j'ai rien compris, ce qui fait que je ne peux ni te soutenir ni te critiquer.

La plage mémoire attribuée à une pile est forcément contigüe

J'espère que t'es en train de parler de mémoire virtuelle là, c'est-à-dire la mémoire que l'OS nous fait voir. En mémoire physique, ça n'a pas à être forcément contigu.

[wafiwafi]

Merci pour ta réponse. Il est possible, c'est même sûr, que j'aie zappé le détail des regitres. Ce qui m'intéresse c'est plus le principe.

La vision fournie à l’utilisateur est très approchée de la réalité par rapport à l’assembleur

.
les deux raisonnent en données et pile. C'est l'organisation qui diffère (pour moi).

La différence réside dans la gestion de la pile qui ne respecte pas forcément le partage de cette dernière entre les variables locales (adresses supérieures) et le tas (adresses inférieures)

…
Vision de la pile fournie à l'utilisateur:Elle est partagée entre deux zones d'adressages : Adresses hautes pour les variables locales et adresses basses pour le tas.

D’ailleurs, je ne vois pas l’intérêt de fournir à l’utilisateur cette dernière précision encore une fois!

peut être qu’il s’agit de limiter le pointage afin de protéger les deux zones (voir exemple fourni ci-après)

Il doit certainement exister des instructions (peu importe le langage) qui manipulent des adresses mémoires (utilisateur) qui correspondent à ces zones. Si oui, dans quel but ? sauf pour le tas peut être où il faut faire le ménage régulièrement.

On fournit à l'utilisateur la possibilité d'opérer dans le tas. C'est le cas du c++ par exemple. Java le fait automatiquement.
Je ne vois pas l'intérêt de séparer en zones la pile pour créer cette vision à l'utilisateur s'il n'y a pas des instructions lui permettant d'opérer à ces endroits. Prenons un exemple, un utilisateur utilise un pointeur sur un objet qui se trouve dans le tas. Peut être qu'avec ce même pointeur on lui interdit de pointer sur la valeur d'une variable locale. Cela, constituerait une raison de séparer les zones pour ne pas laisser à l'utilisateur pointer n'importe quoi n'importe où. Je ne suis pas sûr de ce que j'avance, je ne fais que supposer d'où ce post.
Merci

[Melem]

Vision de la pile fournie à l'utilisateur : Elle est partagée entre deux zones d'adressage : Adresses hautes pour les variables locales et adresses basses pour le tas.

Mais la pile et le tas sont deux zones complètement différentes ! Déjà que la pile est une notion bien connue des processeurs alors que le tas n'est qu'une invention du système. Sous Windows on peu créer autant de tas qu'on veut.

On fournit à l'utilisateur la possibilité d'opérer dans le tas. C'est le cas du c++ par exemple. Java le fait automatiquement.
Je ne vois pas l'intérêt de séparer en zones la pile pour créer cette vision à l'utilisateur s'il n'y a pas des instructions lui permettant d'opérer à ces endroits.

Quelles zones ? La pile n'est pas divisée en zone.

Prenons un exemple, un utilisateur utilise un pointeur sur un objet qui se trouve dans le tas. Peut être qu'avec ce même pointeur on lui interdit de pointer sur la valeur d'une variable locale. Cela, constituerait une raison de séparer les zones pour ne pas laisser à l'utilisateur pointer n'importe quoi n'importe où.

En clair tu ne comprends par exemple pas pourquoi une fonction ne peut pas retourner l'adresse d'une variable locale ?

[wafiwafi]

Peut être que j'ai mal compris!
Mais, je pensais que la vision de la pile qu'on donne à l'utilisateur contient aussi bien les variables locales que le tas. C'est vrai qu'on peut demander autant de tas que l'on veut, cette opération n'est rien qu'une demande à l'os par le runtime pour rallonger le tas mais toujours au même endroit. Regarde ce qu'il explique dans cet article (http://www.larcher.com/eric/guides/javactivex/III.htm), et si tu peux me fournir ton avis, cela m'arrangerait.
Je ne suis pas à l'abri d'une erreur.

[Melem]

Mais, je pensais que la vision de la pile qu'on donne à l'utilisateur contient aussi bien les variables locales que le tas.

Ce qu'on stocke dans pile ce sont les variables locales (les paramètres des fonctions sont également des variables locales à la fonction), l'adresse à laquelle l'exécution doit continuer après le retour de la fonction et tout ce que ça impose. En tout cas, ce sont toujours des trucs temporaires.

Le tas je te dis n'a absolument rien à voir avec la pile (le processeur ne sait même pas ce que c'est). Facile de s'en convaincre : chaque thread possède sa propre pile alors que le tas, c'est quelque chose de commun au sein du processus. Comme je l'ai déjà dit tout à l'heure, il n'y en a qu'un au départ mais on peut ensuite en créer de nouveaux (et on peut aussi bien sûr les détruire), et chaque tas n'est lié à aucun thread. Un tas est une mémoire "globale".

Le lien que tu donnes ne contient même pas le mot "tas". En plus, c'est un cours de Java, pas d'architecture x86.