104 votes

Quel est le but du pointeur de cadre?

Je suis un débutant en langage d'assemblage et ont remarqué que le x86 code émis par les compilateurs tient habituellement le pointeur de cadre autour de même dans la version/mode optimisé, quand il pourrait utiliser le registre EBP pour quelque chose d'autre. Je comprends pourquoi le pointeur de l'image peut rendre le code plus facile à déboguer, et peut être nécessaire en cas alloca() est appelée à l'intérieur d'une fonction. Cependant, x86 a très peu de registres, et à l'aide de deux d'entre eux de tenir l'emplacement de la trame de pile lorsque l'on suffirait n'a tout simplement pas de sens pour moi. Pourquoi est omettant le pointeur de l'image considérée comme une mauvaise idée, même dans optimisé/release?

107voto

ssg Points 20321

Cadre pointeur est un pointeur de référence permettant un débogueur pour savoir où une variable locale ou un argument est à avec une seule constante de décalage. Bien que le ESP est la valeur change au cours de l'exécution, EBP reste le même, ce qui permet de rendre la même variable au même décalage (comme premier paramètre sera toujours à EBP-4 alors que l'ESP décalages peuvent changer de façon significative, puisque vous serez en poussant/popping choses)

Pourquoi ne pas les compilateurs jeter pointeur de l'image? Parce qu'il fait du compilateur faciliter la tâche, il n'a pas à suivre le changement d'ESP lors de la génération de variable locale/argument code d'accès.

Avec le pointeur de l'image, le débogueur peut comprendre d'où les variables locales et les arguments sont à l'aide de la table des symboles car ils sont garantis pour être à un décalage constant de EBP. Sinon, il n'y a pas un moyen simple de voir où une variable locale est à tout point dans le code.

Comme Greg a mentionné, il aide également le déroulement de pile pour un débogueur depuis EBP fournit une inversion de liste liée de la pile d'images et laisser le débogueur pour déterminer la taille de la trame de pile (variables locales + arguments) de la fonction.

La plupart des compilateurs offrent une option pour omettre le cadre des pointeurs bien qu'il rend le débogage vraiment dur. Cette option ne doit jamais être utilisé dans le monde entier, même dans la version du code. Vous ne savez pas quand vous aurez besoin de déboguer un utilisateur du crash.

33voto

Mike Dunlavey Points 25419

Juste ajouter mon grain de sel à déjà de bonnes réponses.

Il fait partie d'une bonne langue de l'architecture d'une chaîne de pile d'images. Le PB de points de l'image actuelle, où la sous-routine-les variables locales sont stockées. (Les gens du coin sont à des décalages négatifs, et les arguments sont positives décalages.)

L'idée qu'il empêche une bonne parfaitement s'inscrire dans l'optimisation pose la question: quand et où est l'optimisation effectivement en vaut la peine?

L'optimisation n'est utile que dans des boucles serrées qui 1) ne pas appeler des fonctions, 2) lorsque le compteur de programme, consacre une part significative de son temps, et 3) dans le code que le compilateur fait verra jamais (c'est à dire non-fonctions de la bibliothèque). C'est généralement une très petite fraction de l'ensemble du code, en particulier dans les grands systèmes.

D'autre code peut être tordu et pressé de se débarrasser de cycles, et il n'est tout simplement pas d'importance, parce que le compteur de programme est pratiquement jamais là.

Je sais que vous ne demandez pas cela, mais dans mon expérience, 99% des problèmes de performance n'ont rien à voir avec optimisation du compilateur. Elles ont tout à voir avec la conception du projet.

11voto

Greg Hewgill Points 356191

Il dépend du compilateur, certainement. J’ai vu un code optimisé émis par x86 compilateurs qui utilise librement l’EBP s’inscrire dans un registre d’usage général. (Je ne me souviens pas quel compilateur, j’ai remarqué qu’avec, cependant).

Les compilateurs peuvent aussi choisir de maintenir l’EBP s’inscrire pour aider avec la pile se détendre au cours de la gestion des exceptions, mais encore une fois cela dépend de l’implémentation du compilateur précis.

4voto

MSN Points 30386

Cependant, x86 a très peu de registres

Cela est vrai seulement dans le sens que les opérateurs ne s'adresse qu'à 8 registres. Le processeur lui-même ont en fait beaucoup plus de registres que cela et utilise le registre de renommage, le pipelining, spéculative de l'exécution, et d'autres processeur de mots à la mode pour contourner cette limite. Wikipédia a un bon paragraphe d'introduction à ce qu'est un processeur x86 pouvez faire pour surmonter le registre limite: http://en.wikipedia.org/wiki/X86#Current_implementations.

1voto

dwc Points 12676

À l’aide de frames de pile a obtenu incroyablement bon marché dans n’importe quel matériel moderne même à distance. Si vous avez des frames de pile pas cher puis en enregistrant quelques registres n’est pas aussi important. Je ne sais pas des frames de pile rapide vs registres plus était un compromis technique et les frames de pile rapide a remporté.

Combien êtes vous épargne va pur s’inscrire ? Est-ce utile ?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X