Discussion :

[homeostasie]

Bonjour,

Je suis entrain d'étudier la stack frame standard du powerpc e500 et je constate qu'il y a des notions de padding et de bits d'alignements qui me font défaut.

Serait il possible d'avoir une signification globale de ce que cela représente avec l'intérêt ou peut être avez vous des liens à me faire parvenir?

Par exemple, que signifierait:

• The stack pointer shall maintain 16-byte alignment.
• Padding to 8-byte boundary

Pour moi, je dirais que le padding est un ajout d'octets initialisé à 0 pour peut être facilité la recherche de variable ou autres au sein de la pile. Est il possible dans ce cas que les stack frame associées à chaque function soit de la même taille quelque soit le nombre d'arguments et de variables locales à sauvegarder?

Merci d'avance.
Bonne soirée.

[Emmanuel Delahaye]

Je suis entrain d'étudier la stack frame standard du powerpc e500

Euh, ça sert à quelque chose ?

et je constate qu'il y a des notions de padding et de bits d'alignements qui me font défaut.

Serait il possible d'avoir une signification globale de ce que cela représente avec l'intérêt ou peut être avez vous des liens à me faire parvenir?

Par exemple, que signifierait:

• The stack pointer shall maintain 16-byte alignment.
• Padding to 8-byte boundary

byte, t'es sûr ? C'est pas plutôt bit ?

[pirus]

salut,

Par exemple, que signifierait:

* The stack pointer shall maintain 16-byte alignment.
* Padding to 8-byte boundary

"16-byte alignment" signifie que l'adresse en question doit etre un multiple de 16 bytes (16 octets), et "padding to 8-byte boundary" signifie que la structure memoire en question doit etre completee de facon a se terminer a la prochaine adresse multiple de 8, -1 octet.

(il s'agit bien de bytes et pas de bits)

l'alignement joue un role important au niveau du cache. les "lignes de cache" sont un ensemble de registres dont la taille depend du processeur (ex. une ligne de cache L2 sur P4 contient 128 bytes). la mise en cache d'un seul byte entraine la mise en cache de tous les bytes alentours necessaires pour constituer la ligne. l'optimisation de l'utilisation du cache consiste donc a faire en sorte de minimiser les "cache hits", en se debrouillant pour que les donnees accedees a un meme endroit du code soient toutes contenues dans la (les) meme(s) ligne(s) de cache. la aussi, au niveau du processeur, le mapping des adresses en memoire vers les lignes de cache se fait sur un nombre de bits restreint (c'est la "granularite" du cache, dont un des objectifs est d'empecher "l'overlapping" (le chevauchement) des zones de memoires representees par les lignes de cache).

au niveau du code, l'alignement des instructions a aussi un impact sur les performances et les optimisations possibles; il est meme parfois indispensable, comme sur MIPS ou chaque instruction doit etre alignee sur un word boundary (cette contrainte est due a la facon dont les adresses sont encodees au niveau des opcodes).

Edit: mon exemple (incorrect) de l'adressage des donnees sur ARM a ete remplace par un exemple (verifie) de l'adressage des instructions sur MIPS.

si tu travailles directement sur une carte PPC (une application embarquee peut-etre?), et que tu dois gerer par exemple des transferts DMA entre les composants peripheriques, il est fort probable que tu aies des contraintes dues a l'alignement des donnees.

tu trouveras plus de details ici: http://en.wikipedia.org/wiki/Data_structure_alignment

je ne saurai pas repondre a ta question concernant le stack frame.

-pirus

[homeostasie]

Merci pour cette réponse pirus.

Je travaille en effet sur une carte embarquée PQ3, sous l'OS vxworks. Devant réaliser un outil post mortem suite à un crash, je tâche de sauvegarder différents registres comme le PC, LR, SP, FP et la stack trace en mémoire non volatile.
Tout cela m'en a fait venir à chercher à comprendre comment est organisé la stack frame standard de ce processeur.

Au fait oui, ce n'était pas bits mais bytes!

Pour récapituler si j'ai bien cerné, 16 bytes alignment va signifier par la même occasion que le SP pointera sur des adresses multiples de 16 octets et le padding en question, représente le remplissage de zone mémoire afin de les complèter pour qu'elle respecte une taille multiple de 8 octets.

[IMG]H:\stack frame layout.JPG[/IMG]

[Emmanuel Delahaye]

[IMG]H:\stack frame layout.JPG[/IMG]

Heureusement, ton disque n'est pas visible sur le net !

[KiLVaiDeN]

Heureusement, ton disque n'est pas visible sur le net !

Attends, j'essaie de lire ses mails pour voir :
[IMG]c:\Mes Documents\homeosta\Outlook Express\{8987-662B-AB34-88FE}\default\mail1\inbox.ebx[/IMG]

Qui a dit que c'était compliqué de hacker qqn sur le net ??

[homeostasie]

Oui heureusement....Ouf! En fait, je me suis dit que peut être ca allé faire un copier de l'image mais non...

[Médinoc]

Regarde dans les "options supplémentaires" du post: Tu peux attacher une image.

[homeostasie]

Ah oui tiens, je n'avais pas fait attention.

Je fournis donc un exemple de stack frame et j'aurais voulu savoir les conclusions que l'on peut tirer de cela vis à vis des informations au dessus.



Notamment le back chain (16-byte aligned), les 2 words of padding (for stack frame) et je suppose que le padding (for second parameter) est un remplissage nécessaire mais pour respecter quoi? Le fait qu'un paramètre doit être enregistré sous 64 bits?

En remarque, il est dit cela dans la doc:

The stack pointer shall point to the first word of the lowest allocated stack frame, the back chain word.
The stack pointer shall be decremented and the back chain updated atomically using one of the store word with update instructions, so that the stack pointer always points to the beginning of a linked list of stack frames.

Ainsi donc le SP ne se déplace que de back chain à back chain?? Puis à partir de là, selon l'offset, telle ou telle valeur est récupérée...Car en fait, je pensais que le SP pouvait pointer sur n'importe quel case mémoire de la pile puis on effetué la recherche de donnée via l'offset par rapport au registre FP contenant le l'adresse du frame pointer en cours!! Je me doute aussi que cela dépend des microprocesseurs.

Merci de ces futurs renseignements.

Nicolas

[pirus]

honnetement je ne suis pas specialiste du PPC ni de vxworks.. si tu galeres vraiment on peut toujours prevoir du temps et regarder ensemble (par mail), car ton truc a l'air interessant, mais la meilleure chose pour toi serait sans doute qu'un pro du PPC se manifeste

-pirus.

[homeostasie]

Salut -pirus,

Bien les explications que tu m'as fourni, plus les quelques liens m'ont tout de même bien aidé. Merci.

Oui c'est vrai, je trouve cela aussi interessant. En fait la compréhension ne m'est pas indispensable mais envie de savoir, ca pourrait m'être utile!

Sinon, oui pas de soucis par mail si nécessaire. Je tâche encore de me débrouiller et si vraiment trop galère, je te ferais signe.

Bonne journée.

Nicolas