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).