Discussion :

[homeostasie]

Bonjour,

Voici plusieurs heures que j'effectue des recherches sur ces deux types de pointeur contenus dans des registres spécifiques.

J'ai l'impression que la stack pointer n'est quelque chose de pas clair car j'ai deux significations. Soit il pointe sur le sommet de de pile, soit sur le prochain emplacement mémoire libre de la pile (c'est à dire, souvent vers les adresses basses selon les µP).

Le frame pointer, disponible selon les microprocesseurs, pointe sur une fenêtre, d'une certaine taille dans la pile, correspondant à différentes données et informations pour un appel de fonction.

En fait, j'aurais voulu savoir si vous auriez des informations complémentaires à m'apporter, ou clarifier un peu plus la chose.

Je bosse sur un mpc8560, e500 core, le gpr1 (General purpose register1) représente le stack frame pointer...C'est quoi en fait? stack pointer? frame pointer? ou le sp pointant sur une adresse dans la frame en cours?

Puis impossible de trouver une data sheet complète sur le net afin d'expliquer et nommer le rôle des différents registres pour ce mpc8560. Je compte accéder notamment au fp et sp à l'aide d'un code assembleur dans mon c comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
TaskInfoBuf[indexBuf].taskId = taskNameToId(oldTcbPtr->name);//taskIdSelf();
   if (taskRegsGet (TaskInfoBuf[indexBuf].taskId, &regSet) != ERROR){
   	TaskInfoBuf[indexBuf].registers = regSet;
   	TaskInfoBuf[indexBuf].TaskFP = (int)GetFP();
   	TaskInfoBuf[indexBuf].TaskSP = (int)GetSP();
   	asm( "mr %0,1 " :"=r" (TaskInfoBuf[indexBuf].TaskSP2)); //GPR1
   	}

En fait, si je prends le sp disponible dans la structure regset, apparemment j'ai le sommet de la pile de la tâche spécifiée, la fonction GetSP() disponible sous vxworks, fourni une aute valeur plus basse dans les adresses, le fonction GetFP ne donne pas le même résulat de frame pointer que le GPR1. Alors que choisir?! De plus, pour chaque tâche différente, je trouve bizarre que la différence entre le SP et FP fourni par les fontions Get donne le même écart d'octet (0x138).

Si vous avez suggestions, idées etc... elles seront les bienvenues.

Merci ;o)

Nicolas

[Médinoc]

Soit il pointe sur le sommet de de pile, soit sur le prochain emplacement mémoire libre de la pile (c'est à dire, souvent vers les adresses basses selon les µP).

À une case près, c'est la même chose. Et c'est souvent le "sommet" (La dernière variable empilée et la première qui sera dépilée) : sur x86 ça l'est, sur Motorola 68000 aussi...

Le frame pointer (ou stack frame pointer, ce qui répond à ta question suivante) pointe sur un espace de la pile, souvent (en C) situé entre les paramètres et les variables locales.
Sur x86, il s'agit du registre EBP. Sur Motorola 68000, c'est un des 7 registres d'adresse non-utilisés (souvent A6, sachant que A7 est toujours le Stack Pointer)

Voilà ce qui se passe généralement lors d'un appel de fonction en C:
(passage d'arguments sur la pile, retour par registre)

• Empilage des paramètres, du dernier au premier.
• --- Appel de la fonction : Empilage de l'adresse de retour
• Empilage des registres, sauf celui de retour (cas A)
• *Empilage du Frame Pointer
• *Copie du pointeur de pile dans le frame pointer
• *Réservation de place sur la pile pour les variables locales (on empile un gros vide, quoi)
• Empilage des registres, sauf celui de retour (cas B)

* : Tout cela peut parfois être le fait d'une seule instruction, comme LINK sur Motorola 68000.
A/B : Généralement, je crois bien que c'est le cas A: On sauvegarde les registres d'abord, on réserve la mémoire ensuite. Mais j'ai déjà vu l'inverse sur un compilateur pour 68000.

Et quand la fonction se termine:

• Dépilage des registres, sauf celui de retour (cas B)
• *Libération de l'espace des variables locales: Copie du Frame Pointer dans le Stack Pointer
• *Dépilage du Frame Pointer
• Dépilage des registres, sauf celui de retour (cas A)
• --- Retour de la fonction : Dépilage de l'adresse de retour
• Dépilage (sans lecture) des paramètres.

* : Tout cela peut parfois être le fait d'une seule instruction, comme UNLK sur Motorola 68000 ou LEAVE sur x86.

[homeostasie]

Medinoc,

D'après ce que j'ai vu, ce ne joue pas à un mot près...

Voir ce lien par exemple:
http://www.univ-paris12.fr/lacl/laco...ml/node19.html

Mais parfois dans mes lectures, je vois aussi que c'est défini le top de la pile! Pourtant n'est ce pas le sp auquel on ajoute un offset pour se situer à tel endroit dans la pile?! Sinon je confonds un truc, le sommet de la pile ne représentre pas la base de la pile mais la fin...;o)

Merci pour les edits à venir.

Nicolas

[Médinoc]

Tu confonds en effet: Le sommet est TOUJOURS le dernier élément empilé, celui à partir duquel on peut calculer des offsets pour accéder à l'avant-dernier, etc.

Le principe de la pile, c'est qu'on se moque pertinament du premier élément empilé : Inutile donc de savoir où il se trouve...

De plus: "frame" est juste une ellipse pour "stack frame" dans ce contexte.

[homeostasie]

Déjà bien merci pour cette explication détaillée du processus d'empilage.

J'en conclue donc que stack pointer n'est pas une variable fixe. Car c'est un débat entre un collègue qui pense que le SP représente la base de la pile pour la tâche définie. Le SP pointe bien sur l'adresse ou le prochain élément sera empilé.

Une autre question, dans le FP, je ne comprends pas qu'elle valeur exactement de SP on y met? En fait j'aurias pensé que cela aurait pu être l'adresse du frame précédent...Ce qui permettrait de revenir à l'appel de la précédente fonction.

[rigobert]

Une autre question, dans le FP, je ne comprends pas qu'elle valeur exactement de SP on y met? En fait j'aurias pensé que cela aurait pu être l'adresse du frame précédent...Ce qui permettrait de revenir à l'appel de la précédente fonction.

Ce n'est pas nécessaire: le compilateur (ou le programmeur en assembleur) sait ce qu'il a empilé (ce n'est pas une donnée "runtime" mais statique) et est donc capable de dépiler ce qui est nécessaire en sortie de fonction (l'offset étant en quelque sorte constant).

[Médinoc]

Lors de l'initialisation du FP, sur 68000 (et aussi dans du code généré pour x86 par GCC), la précédente valeur du FP est empilée et le SP est immédiatement copié vers le FP : Sachant que le SP pointe toujours (sur x86 et 68k, en tout cas) vers le dernier élément empilé (et non la prochaine place libre), Le FP pointe donc sur l'endroit où se trouve sa précédente valeur.

Les variables locales sont donc accessibles à des adresses en FP-x, tandis que les paramètres sont accessibles à des adresses en FP+x

[homeostasie]

Hum hum...

Tout à fait d'accord pour le FP-x et FP+x.

J'ai un petit hic mais voilà ce que je comprends.
1) SP pointe sur le dernier élément empilé donc ca pourrait être la dernière variable locale sauvegardée

2)A l'appel d'une fonction, le SP pointe sur l'empilage des paramères jusqu'à arriver à l'empilage de FP qui contiendra la précédente valeur de FP. Ce que tu me dis, c'est que suite à cela, on met le contenu du registre SP dans le registre FP( c.a.d l'adresse de l'emplacement de FP dont l'empilage est en cours, ou effectué??) , puis SP est à nouveau incrémenté pour pointer sur la première variable locale à sauvegarder.

En conclusion, on pourrait dire que FP sert de référence pour rechercher plus rapidement des données dans une frame destinée à une sous fonction et SP a pour but de pointer au fur à mesure de l'empilage ou dépilage, sur le sommet de la pile.

[Médinoc]

2°) SP pointe sur l'emplacement du FP qu'il vient d'empiler. Cette adresse est ensuite copiée dans FP (donc, les deux pointent sur le même emplacement) avant que SP ne soit encore modifié dans le sens de l'empilement pour la place des variables locales.
Note: Sur les systèmes x86 et 68000, la pile croit vers les adresses basses. Ainsi, lorsqu'on empile, on pré-décrémente SP puis on y met la valeur, et lorsqu'on dépile, on lit la valeur puis on post-incrémente SP.
Donc, sur un tel système, "allouer la place pour les variables locales" consiste à faire une grosse soustraction au pointeur de pile (SP = SP - taille_totale_des_variables).

En fait, sur un système de base, on n'a pas forcément besoin de FP : Un compilateur (ou un humain, mais bonjour la prise de tête) pourrait générer du code entièrement relatif à SP. Mais sur un système connaissant la fonction alloca() qui alloue de la mémoire sur la pile (une quantité NON-connue à la compilation), le FP est indispensable car lui seul ne dépend pas de la quantité demandée (la mémoire allouée par alloca() est empilée après les variables locales)

Généralement, toute fonction possède au moins une frame. Mais si tu déclares des variables dans des sous-blocs de ta fonction, ça peut dépendre du compilo et/ou de la présence ou non d'un appel à alloca() dans la fonction : Si l'environnement est "sûr", on peut tout mettre dès le début dans la même frame, ou réserver au fur et à mesure de l'espace pour les variables d'un bloc sans sauvegarder la frame (donc, on modifie la frame courante).
Si on utilise alloca(), c'est la prudence qui prime : On utilise une frame par bloc.

[homeostasie]

MERCI Medinoc de m'avoir expliqué avec soin ce principe.

Par contre je pense que tu as voulu dire SP et non FP dans la phrase suivante:

avant que FP ne soit encore modifié dans le sens de l'empilement pour la place des variables locales.

Car d'après ce que j'ai compris, le registre FP contient l'adresse du dernier FP empilé. Puis le SP est ensuite pré-décrémenté pour y mettre la future valeur de variable locale.

Bonne journée.

Nicolas

[Médinoc]

FP ? Où ça ?

(y'a pas de smiley "ange" sur ce forum...)

[homeostasie]

Oui tiens quel FP?!

En tout cas, d'ici 40 min, qui est en we, c'est moi! Et ce ne me demandera pas d'effort de mettre tout ces registres de côté pour profiter pleinement du soleil dans mon Sud Ouest!

Bon we!