
En ingénierie informatique , les fenêtres de registres sont une fonctionnalité qui dédie des registres à une sous-routine en créant dynamiquement un alias d'un sous-ensemble de registres internes en registres fixes, visibles par le programmeur. Les fenêtres de registres sont implémentées pour améliorer les performances d'un processeur en réduisant le nombre d' opérations de pile requises pour les appels et les retours de fonctions. L'une des caractéristiques les plus influentes de la conception RISC de Berkeley , elles ont ensuite été implémentées dans des architectures de jeux d'instructions telles que AMD Am29000 , Intel i960 , Sun Microsystems SPARC et Intel Itanium .
Fonctionnement général
Plusieurs ensembles de registres sont fournis pour les différentes parties du programme. Les registres sont volontairement cachés au programmeur pour forcer plusieurs sous-routines à partager les ressources du processeur.
Le fait de rendre les registres invisibles peut être mis en œuvre de manière efficace ; le processeur reconnaît le mouvement d'une partie du programme à une autre lors d'un appel de procédure. Il est accompli par l'une des quelques instructions ( prologue ) et se termine par une instruction d'un ensemble tout aussi petit ( épilogue ) . Dans la conception de Berkeley, ces appels entraîneraient l'"échange" d'un nouvel ensemble de registres à ce stade, ou le marquage comme "mort" (ou "réutilisable") lorsque l'appel se termine.
Application dans les processeurs
Dans la conception RISC de Berkeley, seuls huit registres sur un total de 64 sont visibles par les programmes. L'ensemble complet des registres est appelé fichier de registres , et tout ensemble particulier de huit registres est appelé fenêtre . Le fichier permet à huit appels de procédure d'avoir leurs propres ensembles de registres. Tant que le programme n'appelle pas de chaînes de plus de huit appels de profondeur, les registres n'ont jamais besoin d'être déversés , c'est-à-dire sauvegardés dans la mémoire principale ou dans le cache, ce qui est un processus lent comparé à l'accès aux registres.
En comparaison, l' architecture SPARC de Sun Microsystems offre une visibilité simultanée sur quatre ensembles de huit registres chacun. Trois ensembles de huit registres chacun sont « fenêtrés ». Huit registres (i0 à i7) constituent les registres d'entrée du niveau de procédure actuel. Huit registres (L0 à L7) sont locaux au niveau de procédure actuel et huit registres (o0 à o7) sont les sorties du niveau de procédure actuel vers le niveau suivant appelé. Lorsqu'une procédure est appelée, la fenêtre de registres se décale de seize registres, masquant les anciens registres d'entrée et les anciens registres locaux et faisant des anciens registres de sortie les nouveaux registres d'entrée. Les registres communs (anciens registres de sortie et nouveaux registres d'entrée) sont utilisés pour le passage des paramètres. Enfin, huit registres (g0 à g7) sont globalement visibles à tous les niveaux de procédure.
L'AMD 29000 a amélioré la conception en permettant aux fenêtres d'être de taille variable, ce qui facilite l'utilisation dans le cas courant où moins de huit registres sont nécessaires pour un appel. Il a également séparé les registres en un ensemble global de 64 et 128 supplémentaires pour les fenêtres. De même, l'architecture IA-64 (Itanium) utilisait des fenêtres de taille variable, avec 32 registres globaux et 96 pour les fenêtres.
Dans l' architecture Infineon C166 , la plupart des registres sont simplement des emplacements dans la RAM interne qui ont la propriété supplémentaire d'être accessibles en tant que registres. Parmi ceux-ci, les adresses des 16 registres à usage général (R0-R15) ne sont pas fixes. Au lieu de cela, le registre R0 est situé à l'adresse pointée par le registre « Context Pointer » (CP), et les 15 registres restants suivent séquentiellement par la suite.
Les fenêtres de registres offrent également un moyen simple de mise à niveau. Comme les registres supplémentaires sont invisibles pour les programmes, des fenêtres supplémentaires peuvent être ajoutées à tout moment. Par exemple, l'utilisation de la programmation orientée objet entraîne souvent un plus grand nombre d'appels « plus petits », ce qui peut être pris en compte en augmentant les fenêtres de huit à seize par exemple. C'est l'approche utilisée dans SPARC, qui a inclus davantage de fenêtres de registres avec les nouvelles générations de l'architecture. Le résultat final est moins d'opérations lentes de débordement et de remplissage des fenêtres de registres , car les fenêtres de registre débordent moins souvent.
Critique
L'inconvénient des fenêtres de registres est que les changements de contexte nécessitent l'enregistrement d'un grand nombre de registres en mémoire. L'implémentation SPARC avance toujours la fenêtre de registres de seize registres, ce qui signifie que lorsque cela se produit, bon nombre de ces registres enregistrés ne contiendront même pas de données utiles. Certains ont critiqué les études originales qui ont conduit à l'implémentation des fenêtres de registres, car elles ne prenaient en compte que les programmes de manière isolée et ignoraient les charges de travail multitâches.
Les fenêtres de registres ne sont pas le seul moyen d'améliorer les performances des registres. Le groupe de l'Université de Stanford qui a conçu le MIPS a vu le travail de Berkeley et a décidé que le problème n'était pas un manque de registres, mais une mauvaise utilisation de ceux existants. Ils ont plutôt investi plus de temps dans l' allocation des registres de leur compilateur , en s'assurant qu'il utilisait judicieusement le plus grand ensemble disponible dans MIPS. Cela a permis de réduire la complexité de la puce, avec la moitié du nombre total de registres, tout en offrant des performances potentiellement plus élevées dans les cas où une seule procédure pourrait utiliser l'espace de registre visible plus grand. Au final, avec les compilateurs modernes, MIPS fait un meilleur usage de son espace de registre même pendant les appels de procédure.
- Frantzen, Mike ; Shuey, Mike (2001). « StackGhost : protection de pile facilitée par le matériel ». Actes du 10e symposium sur la sécurité Usenix . USENIX . p. 55–66 2010 .
- Magnusson, Peter (avril 1997). « Comprendre les piles et les registres dans l'architecture Sparc ». Archivé de l'original le 24 décembre 2012 2010 .
- Mueller, Frank. "setjmp/longjmp".Discussion de l'implémentation complexe de Sparc en raison du fenêtrage.