Skip to content

Quelle mauvaise prédiction de branche le tampon de cible de branche détecte-t-il ?

Vous n'avez plus à chercher partout sur internet puisque vous êtes au bon endroit, nous avons la réponse qu'il vous faut et sans vous compliquer la tâche.

Solution :

C'est une bonne question ! Je pense que la confusion qu'elle provoque est due aux schémas de dénomination étranges d'Intel qui surchargent souvent les termes standard dans le milieu universitaire. Je vais essayer à la fois de répondre à votre question et aussi de dissiper la confusion que je vois dans les commentaires.

Tout d'abord . Je suis d'accord pour dire que dans la terminologie informatique standard, un tampon de cible de branche n'est pas synonyme de prédicteur de branche. Cependant, dans la terminologie Intel, le tampon de cible de branchement (BTB)... [in capitals] est quelque chose de spécifique et contient à la fois un prédicteur et un Branch Target Buffer Cache (BTBC) qui est juste un tableau des instructions de branchement et de leurs cibles sur un résultat pris. Ce BTBC est ce que la plupart des gens comprennent comme un tampon de cible de branchement. [lower case]. Alors qu'est-ce que le calculateur d'adresse de branchement (BAC) et pourquoi en avons-nous besoin si nous avons un BTB ?

Donc, vous comprenez que les processeurs modernes sont divisés en pipelines avec plusieurs étapes. Qu'il s'agisse d'un simple processeur pipeliné ou d'un processeur supersclar désordonné, les premiers étages sont généralement... aller chercher puis décoder. Dans le récupère tout ce que nous avons est l'adresse de l'instruction courante contenue dans le compteur de programme (PC). Nous utilisons le PC pour charger des octets de la mémoire et les envoyer à l'étape fetch . décodage étape. Dans la plupart des cas, nous incrémentons le PC afin de charger la ou les instructions suivantes mais dans d'autres cas, nous traitons une instruction de flux de contrôle qui peut modifier complètement le contenu du PC.

Le but du BTB est de deviner si l'adresse dans le PC pointe vers une instruction de branchement, et si oui, quelle doit être l'adresse suivante dans le PC ? C'est très bien, nous pouvons utiliser un prédicteur pour les branches conditionnelles et le BTBC pour l'adresse suivante. Si la prédiction est juste, c'est génial ! Si la prédiction est fausse, que se passe-t-il alors ? Si le BTB est la seule unité dont nous disposons, alors nous devrions attendre que la branche atteigne l'adresse question/exécuter étape du pipeline. Nous devrions vider le pipeline et recommencer. Mais pas chaque doit être résolue aussi tard. C'est là qu'intervient le calculateur d'adresse de branche (BAC).

Le BAC est utilisé dans le fetch du pipeline, mais le BAC réside dans la section décodage étape. Une fois que l'instruction que nous avons extraite est décodée, nous avons en fait beaucoup plus d'informations qui peuvent être utiles. La première nouvelle information que nous connaissons est : "L'instruction que j'ai extraite est-elle est en fait une branche ?" Dans l'étape de fetch, nous n'en avons aucune idée et le BTB ne peut que deviner, mais dans l'étape de décodage, nous... savons que c'est sûr. Il est possible que le BTB prédise un branchement alors qu'en fait l'instruction n'en est pas un ; dans ce cas, le BAC arrêtera l'unité de fetch, corrigera le BTB et réinitialisera le fetch correctement.

Qu'en est-il des branchements comme unconditional relative et call? Celles-ci peuvent être validées à l'étape du décodage. Le BAC vérifiera le BTB, verra s'il y a des entrées dans le BTBC et réglera le prédicteur pour toujours prédire pris. Pour conditional le BAC ne peut pas confirmer si elles sont déjà prises/non prises, mais il peut au moins valider l'adresse prédite et corriger le BTB en cas de mauvaise prédiction d'adresse. Parfois, le BTB n'identifie pas/ne prédit pas du tout une branche. Le BAC doit corriger cela et donner au BTB de nouvelles informations sur cette instruction. Comme le BAC ne dispose pas de son propre prédicteur conditionnel, il utilise un mécanisme simple (branches arrière prises, branches avant non prises).

Quelqu'un devra confirmer ma compréhension de ces compteurs matériels, mais je crois qu'ils signifient ce qui suit :

  • BACLEAR.CLEAR est incrémenté lorsque le BTB en récupère fait un mauvais
    travail et que le BAC dans décode peut le réparer.
  • BPU_CLEARS.EARLY est
    incrémenté lorsque récupère décide (incorrectement) de charger l'instruction suivante
    instruction suivante avant que le BTB ne prédise qu'il devrait effectivement charger à partir de
    le chemin pris à la place. Ceci est dû au fait que le BTB nécessite plusieurs cycles et que fetch utilise ce temps pour charger spéculativement un bloc d'instructions consécutif. Cela peut être dû au fait qu'Intel utilise deux BTB, l'un rapide et l'autre plus lent mais plus précis. Il faut plus de cycles pour obtenir une meilleure prédiction.

Cela explique pourquoi la pénalité d'une détection d'une mauvaise prédiction dans le BTB est de 2/3 cycles alors que la détection d'une mauvaise prédiction dans le BAC est de 8 cycles.

Le fait BPU_CLEARS.EARLY description montre que cet événement se produit lorsque le BPU prédit, en corrigeant une hypothèse, implique qu'il y a 3 étapes dans le front-end. Supposer, prédire et calculer.

Il est également dit que cela se produit lorsque la BPU suppose qu'elle n'a pas été prise et prédit ensuite qu'elle est prise, et non l'inverse. Cela implique qu'il est toujours supposé ne pas être pris. Cela suggère probablement un échec dans un BTB L1.

enter image description here

Voici un pipeline P6. En utilisant ceci comme exemple, un clear précoce est dans le 3ème cycle (13), quand une prédiction est faite (et la cible et le type d'entrée sont lus, et donc les cibles de branchement inconditionnelles sont maintenant connues ainsi que les conditionnelles et leurs prédictions), la première cible de branchement prise prédite dans l'ensemble pour le bloc de 16 octets est utilisée. À ce stade, les deux étapes du pipe qui le précèdent ont déjà été remplies de fetches et de début de recherche des blocs de 16 octets suivants, ce qui signifie qu'elles doivent être vidées s'il y a une prédiction de prise (sinon, cela n'est pas nécessaire puisque le bloc de 16 octets suivant commence déjà à être recherché dans l'étape du pipe qui le précède), laissant un vide ou une bulle de 2 cycles. La recherche dans le cache se produit en même temps que la recherche dans la BTB, donc les deux pipestages parallèles de la BTB et du cache devront être vidés, alors que le troisième étage n'a pas besoin d'être vidé du cache ou de la BTB parce que l'IP est sur un chemin confirmé et est l'IP en cours de recherche pour le prochain. En fait, dans cette conception P6, il n'y a qu'une bulle d'un cycle pour ce clear précoce, car la nouvelle IP peut être envoyée au premier étage pour décoder à nouveau un set sur le front haut de l'horloge pendant que ces autres étages sont vidés.

Si cela est vrai, chaque branche prise provoquera un early clear. Cela semble être soutenu par https://gist.github.com/mattgodbolt/4e2cbb1c9aa97e0c5478 https://github.com/mattgodbolt/agner/blob/master/tests/branch.py, où le BaClrEly est 0 pour toutes les branches non prises et 900k instructions élicite 100k early clears, ce qui s'aligne avec 1 sur 9 instructions étant une branche prise.

Ce pipelining est plus bénéfique que d'attendre la prédiction avant de commencer un lookup sur l'IP suivante. Cela signifierait un lookup tous les deux cycles. Cela donnerait un débit de 16 octets de prédictions tous les 2 cycles, donc 8B/c. Dans le scénario pipeliné du P6, le débit est de 16 octets par cycle dans une hypothèse correcte et de 8B/c dans une hypothèse incorrecte. Évidemment plus rapide. Si nous supposons que 2/3 des hypothèses sont correctes pour 1 instruction sur 9 étant une branche prise pour 4 instructions par bloc, cela donne un débit de 16B par ((1*0,666)+2*0,333)) =1,332 cycles au lieu de 16B par 2 cycles.

L'effacement tardif (BPU_CLEARS.LATE) semble se produire à l'ILD. Dans le diagramme ci-dessus, la consultation du cache ne prend que 2 cycles. Dans les processeurs plus récents, il prend apparemment 4 cycles. Cela permet d'insérer un autre BTB L2 et d'effectuer une recherche dans celui-ci. Les termes "contournement MRU" et "conflits MRU" peuvent simplement signifier que le BTB MRU a été manqué ou que la prédiction dans la L2 est différente de celle de la L1 dans le cas où elle utilise un algorithme de prédiction et un fichier historique différents. Le BPU fournira un masque de bits pour toutes les prédictions pour les 16 octets actuels dans le tampon ILD, ainsi qu'un masque pour les prédictions effectuées, et la première cible de branchement prise dans ces octets, ce sont les bits de prédiction après le processus de consultation des BTB L1 et L2 en parallèle avec le pipeline de récupération. Ces bits de prédiction sont connus à l'étage situé à côté de l'ILD et sont placés à côté du tampon de l'ILD dès qu'ils sont connus, à côté des bitmasks générés par l'ILD pour les octets de début et de fin d'une instruction, ces bitmasks sont décalés dans l'ILD lorsqu'il est aligné sur la limite de l'instruction suivante). Tout conflit L2 BTB est connu après la fin de la recherche et avant que le BPU ne fournisse ces bits à l'ILD (les conflits ne sont pas découverts par une action de l'ILD lui-même). S'il y a un conflit (en particulier si une branche antérieure dans le bloc de 16 octets est maintenant prédite ou si la première branche du bloc n'est plus prédite), le pipeline est réorienté et cela ne crée qu'une bulle de 3 cycles (ce qui implique que la recherche L2 se termine dans le cycle suivant et est parallèle à la recherche L1 BTB). La bulle de 3 cycles provient du fait que l'ILD de l'étape 5 réoriente le pipeline au bord inférieur de l'étape 1 et vide les étapes 2, 3 et 4 (ce qui correspond aux latences L1i citées de 4 cycles, car la recherche L1i se fait sur les étapes 1 à 4 pour un hit+ITLB hit). Dès que la prédiction est faite, les BTB mettent à jour les bits BHR locaux spéculatifs des entrées avec la prédiction qui a été faite.

L'ensemble BTB contient 4 voies pour un maximum de 4 branches par 16 octets (où toutes les voies de l'ensemble sont étiquetées avec la même étiquette indiquant ce bloc particulier de 16 octets alignés). Chaque voie a un offset indiquant les 4 LSBs de l'adresse, donc la position de l'octet dans les 16 octets. Chaque entrée a également un bit spéculatif, un bit valide, des bits pLRU, un BHR local spéculatif, un BHR local réel, et chaque voie partage l'ensemble BPT (PHT) comme deuxième niveau de prédiction. Ceci peut être allié à une GHR / GHR spéculative.

Je ne suis pas sûr pourquoi Haswell et Ivy Bridge ont de telles valeurs pour les early et late clears mais ces événements (0xe8) disparaissent à partir de SnB, qui se trouve coïncider avec le moment où le BTB a été unifié en une seule structure... peut-être que ce sont des valeurs bidons ? Je ne suis pas non plus sûr de la raison pour laquelle Nehalem a une bulle de 2 cycles pour les early clears, car la conception du L1 Nehalem BTB ne semble pas changer beaucoup de celle du P6 BTB, tous deux 512 entrées avec 4 voies par set. C'est probablement parce qu'il a été décomposé en plus d'étapes en raison des vitesses d'horloge plus élevées et donc aussi de la latence plus longue du cache L1i.

BACLEAR est quand un bitmask dans l'IQ fourni au BAC indique que la BPU n'a pas pu faire une prédiction (cela ne s'applique pas à l'indirect), et la prédiction statique dans l'IQ rencontre un saut conditionnel dont l'octet correspondant est indiqué par un bitmask dans l'IQ qu'une prédiction n'a pas été faite (ce qui signifie pas pris par défaut) et se trouve à le prédire statiquement comme pris à la place et changer le préfixe, ce qui aura pour conséquence que le BAC détectera que le mauvais chemin a été récupéré (on dit que le QI force un BACLEAR car il y en aura maintenant un au BAC : BACLEAR_FORCE_IQ). Le BAC au niveau des décodeurs s'assure également que les branches relatives et les branches directes ont la prédiction de cible de branchement correcte après avoir calculé l'adresse absolue à partir de l'instruction elle-même et l'avoir comparée avec elle, si ce n'est pas le cas, un BACLEAR est émis. Pour les sauts relatifs, la prédiction statique dans le BAC utilise le bit de signe du déplacement de saut pour prédire statiquement la prise / non prise si une prédiction n'a pas été faite, mais remplace également toutes les prédictions de retour comme prises si le BTB ne supporte pas les types d'entrée de retour (il ne le fait pas sur P6 et ne fait aucune prédiction, Au lieu de cela, le BAC utilise le mécanisme RSB de la BPU et c'est le premier point du pipeline où une instruction de retour est acquittée) et remplace toutes les prédictions de branchement indirect de registre prises sur P6 (parce qu'il n'y a pas de BTB) car il utilise la statistique selon laquelle plus de branchements sont pris que non. Le BAC calcule et insère la cible absolue à partir de la cible relative dans l'uop et insère le delta IP dans l'uop et insère le fall through IP (NLIP) dans le BIT du BPU et marque l'uop avec l'entrée BIT et la prédiction de cible indirecte est insérée dans l'uop au lieu de la cible connue si la cible n'est pas connue. Ces champs dans l'uop sont utilisés par l'allocateur pour l'allocation dans le RS/ROB par la suite. Le BAC informe également la BTB de toute prédiction erronée (instructions sans branchement) dont les entrées doivent être désallouées de la BTB. Au niveau des décodeurs, les instructions de branchement sont détectées tôt dans la logique (lorsque les préfixes sont décodés et que l'instruction est examinée pour voir si elle peut être décodée par le décodeur) et le BAC est accédé en parallèle avec le reste. Le BAC qui insère la cible connue ou autrement prédite dans l'uop est connu comme convertissant un auop en duop. La prédiction est codée dans l'opcode uop.

Le BAC demande probablement à la BTB de mettre à jour de manière spéculative sa BTB pour l'IP de l'instruction de branchement détectée. Si la cible est maintenant connue et qu'aucune prédiction n'a été faite pour elle (ce qui signifie qu'elle n'était pas dans le cache) -- elle est encore spéculative car bien que la cible de la branche soit connue avec certitude, elle pourrait encore être sur un chemin spéculatif, elle est donc marquée d'un bit spéculatif -- cela fournira maintenant immédiatement des aiguillages précoces, en particulier pour les branches inconditionnelles qui entrent maintenant dans le pipeline mais aussi pour les conditionnelles, avec un historique vierge donc prédit non pris la prochaine fois, plutôt que d'avoir à attendre la retraite).

enter image description here

L'IQ ci-dessus contient un champ bitmask pour les directions de prédiction de branchement (BTBP) et les prédictions de branchement effectuées / aucune prédiction effectuée (BTBH) (pour distinguer lesquels des 0 ne sont pas pris par opposition à aucune prédiction effectuée) pour chacun des 8 octets d'instruction dans une ligne IQ ainsi que la cible d'une instruction de branchement, ce qui signifie qu'il ne peut y avoir qu'un seul branchement par ligne IQ et qu'il termine la ligne. Ces bits de prédiction et ces prédictions de cible sont insérés par le BPU au niveau de l'ILD. L'IQ est un bloc contigu d'octets d'instruction et l'ILD remplit 8 mais bitmasks qui identifient le premier octet d'opcode (OpM) et l'octet de fin d'instruction (EBM) de chaque macro-instruction à mesure qu'elle enroule des octets dans l'IQ. Les espaces entre ces marqueurs sont implicitement des octets de préfixe pour l'instruction suivante. Je pense que l'IQ est conçu de telle sorte que les uops qu'il émet dans l'IDQ/ROB dépasseront rarement l'IQ, de telle sorte que le pointeur de tête dans l'IQ commence à écraser les macroinstructions encore marquées dans l'IDQ en attente d'être allouées, et quand cela se produit, il y a un blocage, donc les balises IDQ renvoient à l'IQ, auquel l'allocateur accède. Je pense que le ROB utilise également ce tag uop. L'IQ sur SnB si 16 octets * 40 entrées contient 40 macroops dans le pire des cas, 320 dans le cas moyen, 640 dans le meilleur des cas. Le nombre d'uops qu'ils produisent sera beaucoup plus grand, donc il sera rarement dépassé, et quand il le fait, je suppose qu'il bloque le décodage jusqu'à ce que plus d'instructions se retirent. Le pointeur de queue contient l'étiquette récemment allouée par l'ILD, le pointeur de tête contient la prochaine instruction de macro-instruction en attente de retrait, et le pointeur de lecture est l'étiquette actuelle à consommer par les décodeurs (qui se déplace vers le pointeur de queue). Bien que cela devienne difficile maintenant que certaines, sinon la majorité, des uop dans le chemin proviennent du cache uop depuis SnB. Le QI peut être autorisé à dépasser le back-end dans le cas où les uops ne sont pas marqués avec les entrées du QI (et que les champs du QI sont plutôt insérés dans les uops directement), et cela sera détecté et le pipeline sera juste repositionné depuis le début.

Lorsque l'allocateur alloue une destination physique (Pdst) pour une micro-op de branche dans le ROB, l'allocateur fournit le numéro d'entrée Pdst à la BPU. Le BPU l'insère dans l'entrée BIT correcte attribuée par le BAC (qui est probablement étiquetée à l'uop). l'allocateur extrait également les champs ceux-ci de l'uop et alloue les données dans le RS sans BIT comme illustré ci-dessous.

enter image description here

Le RS contient un champ qui indique si une instruction est un uop MSROM ou un uop régulier, que l'allocateur remplit. L'allocateur insère également la cible absolue confirmée ou la cible absolue prédite dans les données immédiates et comme source, renomme le registre des drapeaux (ou juste un bit de drapeau) et dans le cas d'une branche indirecte, il y a aussi le registre renommé qui contient l'adresse comme autre source. Le Pdst dans le schéma PRF serait l'entrée ROB, qui en tant que Pdst serait le registre macro-RIP ou micro-IP de sortie. Le JEU écrit la cible ou le fallthrough dans ce registre (il peut ne pas en avoir besoin si la prédiction est correcte).

Lorsque la station de réservation dispatche une micro-opération de branchement à une unité d'exécution de saut située dans l'unité d'exécution d'entier, la station de réservation informe la BTB de l'entrée Pdst pour la micro-opération de branchement correspondante. En réponse, le BTB accède à l'entrée correspondante pour l'instruction de branchement dans le BIT et le fall through IP (NLIP) est lu, décrémenté par le delta IP dans le RS, et décodé pour pointer vers le jeu que l'entrée de branchement sera mise à jour/affectée.

Le résultat du registre de drapeau renommé source Pdst pour déterminer si la branche est prise / non prise est ensuite comparé à la prédiction dans l'opcode dans l'ordonnanceur, et en outre, si la branche est indirecte, la cible prédite dans le BIT est comparée à l'adresse dans la source Pdst (qui a été calculée et est devenue disponible dans le RS avant d'être ordonnancée et distribuée) et on sait maintenant si une prédiction correcte a été faite ou non et si la cible est correcte ou non.

La JEU propage un code d'exception à la ROB et vide le pipeline (JEClear -- qui vide tout le pipeline avant l'étape d'allocation, ainsi que bloque l'allocateur) et redirige la logique IP suivante au début du pipeline en utilisant le fallthrough (en BIT) / IP cible de manière appropriée (ainsi que le microséquenceur s'il s'agit d'une mauvaise prédiction de microbranche ; le RIP dirigé vers le début du pipeline sera le même tout au long de la procédure MSROM). Les entrées spéculatives sont désallouées et les BHR vrais sont copiés dans les BHR spéculatifs. Dans le cas où il y a un BOB dans le schéma PRF, le BOB prend des instantanés de l'état de la RAT pour chaque instruction de branchement et lorsqu'il y a une mauvaise prédiction. Le JEU ramène l'état du RAT à cet instantané et l'allocateur peut procéder immédiatement (ce qui est particulièrement utile pour les erreurs de prédiction de microbranche, car il est plus proche de l'allocateur et la bulle ne sera donc pas aussi bien cachée par le pipeline), plutôt que de bloquer l'allocateur et de devoir attendre jusqu'à la retraite pour connaître l'état du RAT de retraite et l'utiliser pour restaurer le RAT et ensuite effacer le ROB (ROClear, qui débloque l'allocateur). Avec un BOB, l'allocateur peut commencer à émettre de nouvelles instructions pendant que les uops périmés continuent à s'exécuter, et lorsque la branche est prête à être retirée, le ROClear efface seulement les uops entre la mauvaise prédiction retirée et les nouveaux uops. S'il s'agit d'une uop MSROM, parce qu'elle peut s'être terminée, le début du pipeline doit encore être redirigé vers l'uop MSROM à nouveau, mais cette fois il commencera à la micropuce redirigée (c'est le cas avec les instructions en ligne (et il peut être capable de la rejouer hors du QI). Si une erreur de prédiction se produit dans une exception MSROM, alors il n'a pas besoin de rejouer le pipeline, il le redirige directement, car il a pris en charge la question de l'IDQ jusqu'à la fin de la procédure -- la question peut avoir déjà pris fin pour les questions en ligne.

Le ROClear en réponse au vecteur d'exception de branchement dans le ROB se produit en fait sur la deuxième étape de retrait RET2 (qui est vraiment la 3e des 3 étapes du pipeline de retrait typique) lorsque les uops sont retirés. La macro-instruction ne se retire et les exceptions ne se déclenchent et le RIP de la macro-instruction ne se met à jour (avec une nouvelle cible ou une augmentation par delta IP dans le ROB) que lorsque le marqueur EOM uop (end of macroinstruction) se retire, même si une instruction non EOM l'écrit, il n'est pas écrit dans le RRF immédiatement contrairement aux autres registres -- de toute façon, l'uop de branchement sera probablement l'uop final dans la macro-instruction de branchement typique gérée par les décodeurs. S'il s'agit d'une microbranche dans une procédure MSROM, elle ne mettra pas à jour la BTB ; elle met à jour l'uIP lorsqu'elle se retire, et le RIP n'est pas mis à jour avant la fin de la procédure.

Si une exception générique non-mispredict se produit (c'est à dire une qui nécessite un gestionnaire) pendant l'exécution d'une macroop MSROM, une fois qu'elle a été traitée, le microprocesseur qui a causé l'exception est restauré par le gestionnaire dans le registre uIP (dans le cas où il est passé au gestionnaire lorsqu'il est appelé), ainsi que le RIP actuel de la macroinstruction qui a déclenché l'exception, et lorsque le traitement de l'exception se termine, l'extraction des instructions est reprise à ce RIP+uIP : la macroinstruction est réinitialisée et réessayée dans le MSROM, qui commence au uIP qui lui est signalé. L'écriture RRF (ou la mise à jour RAT de retraite sur le schéma PRF) pour les uop précédentes dans une macro-instruction complexe non-MSROM peut se produire sur le cycle avant que l'uop EOM ne se retire, ce qui signifie qu'un redémarrage peut se produire à une certaine uop dans une macro-instruction ainsi que dans une macro-instruction MSROM, où le MS ordonne au décodeur complexe / cache d'uop d'émettre ces dernières uop (l'uIP est une valeur comprise entre 0 et 3 que la ROB fixe à 0 à chaque EOM et incrémente pour chaque microop retirée, afin que les instructions complexes non-MSROM puissent être adressées -- pour les procédures en ligne MSROM, il émet un uop qui indique à l'ORB son propre uIP) (le registre RIP architectural, qui est mis à jour par le delta IP uniquement lorsque l'uop EOM se retire pointe toujours vers la macroop actuelle parce que l'uop EOM n'a pas réussi à se retirer), ce qui ne se produit que pour les exceptions mais pas pour les interruptions matérielles, qui ne peut pas interrompre les procédures MSROM ou les instructions complexes en milieu de retraite (les interruptions logicielles sont similaires et se déclenchent à l'EOM -- le gestionnaire de trap MSROM effectue un macrojump vers le RIP du gestionnaire de trap logiciel une fois qu'il a terminé).

La lecture BTB et la comparaison des balises se produisent dans RET1 pendant que l'unité de branchement réécrit les résultats, puis dans le cycle suivant, peut-être aussi pendant RET1 (ou peut-être que cela est fait dans RET2), les balises de l'ensemble sont comparées et ensuite, s'il y a un hit, un nouvel historique BHR est calculé.ed; s'il y a un échec, une entrée doit être allouée à cet IP avec cette cible. Ce n'est qu'une fois que l'unité se retire en ordre (dans RET2) que le résultat peut être placé dans l'historique réel et que l'algorithme de prédiction de branche est utilisé pour mettre à jour la table de motifs lorsqu'une mise à jour est nécessaire. Si la branche nécessite une allocation, la politique de remplacement est utilisée pour décider des moyens d'allocation de la branche. En cas de succès, l'objectif sera déjà correct pour toutes les branches directes et relatives, il n'est donc pas nécessaire de le comparer, en cas d'absence d'IBTB. Le bit spéculatif est maintenant retiré de l'entrée s'il est présent. Enfin, au cours du cycle suivant, la branche est écrite dans le cache BTB par la logique de contrôle d'écriture BTB. La première partie de la consultation de la BTB peut être en mesure d'aller de l'avant tout au long de RET1 et peut ensuite bloquer le pipeline d'écriture de la BTB jusqu'à RET2, lorsque l'étape en attente d'écriture à l'entrée ROB de la BTB se retire, sinon, la consultation pourrait être découplée et la première partie se termine et écrit les données, par exemple, le BIT, et à RET2, l'entrée correspondante à celle qui se retire est juste réécrite dans la BTB (ce qui signifierait décoder l'ensemble à nouveau, comparer les balises à nouveau et ensuite écrire l'entrée, donc peut-être pas).

Sur Sandy Bridge, un chunk aligné de 32B est scanné par le BPU au lieu de 16B (donc 2 ensembles adjacents sont scannés...).ed; tout semble indiquer que chaque ensemble de 4 voies couvre toujours un maximum de 16 octets contigus sur SnB). Dans le même cycle, il est envoyé dans le cache L1i et le cache uop. Si une branche prise est détectée, le pipeline est dirigé vers elle et le nouveau morceau de 32B est scanné depuis l'IP restorée jusqu'à la fin de la fenêtre de 32B dans laquelle il se trouve. S'il n'y a pas de branche prise, dans le cycle suivant, il scanne les 2 ensembles adjacents en commençant par la limite des 32B. Je pense qu'elle accompagne chaque fenêtre 32B précédente d'une fenêtre de prédiction une fois que la prédiction est entrée, de sorte que l'unité de fetch ne récupère pas de blocs de 16 octets redondants, mais aussi pour qu'elle récupère correctement aligné à la première macroinstruction lors d'un rester pipeline sur une branche prise mal prédite, ou dans le cas d'un of fetching dû à un uop cache hit.

Si le P6 avait un uop cache, le pipeline serait quelque chose comme :

  • 1H : sélection de l'IP
  • 1L : BTB set decode + cache set decode (index physique/virtuel) + ITLB lookup + uop cache set decode
  • 2H : lecture de cache + lecture BTB + lecture de cache uop
  • 2L : comparaison de tags de cache + comparaison de tags BTB + comparaison de tags de cache uope; si uop cache hit, stall jusqu'à ce que uop cache puisse sortir, puis clock gate legacy decode pipeline
  • 3H : predict, if taken, flush 3H,2L,2H,1L
  • 3L si pris, commencer un 1L avec une nouvelle IP pour décoder le nouvel ensemble et continuer avec le bloc actuel de 16 octets pour lequel l'instruction de branchement réside à 4L.

Je suppose que le cache uop redirige également le BPU vers la macrocible lorsqu'un uop de branchement pris est rencontré (ce qui sera en même temps qu'un late clear, et la prédiction de cible indirecte peut être utilisée ainsi que les cibles calculées dans les uops), mais jusqu'à ce moment, les étapes de recherche séquentielle sont emballées derrière lui dans le pipeline. La recherche régulière BTB/IBTB se poursuit à ce moment-là, et elle utilise ces prédictions, et n'a besoin que d'une prédiction de cible de l'IBTB, parce que toutes les cibles ont été correctement calculées. Il ignore probablement les prédictions sur les branches bidon et les prédictions non prises à toutes les non-prédictions, sinon les cibles indirectes et les prédictions T/NT sont insérées dans le TIB ou l'uop lui-même. J'imagine que le cache uop crée des entrées BIT et met à jour les prédictions dans les BTB, pour s'assurer que le cache uop et les uop MITE (décodage hérité) mettent à jour l'historique dans un ordre séquentiel correct.

Si vous avez des réserves et des dispositions pour améliorer notre tutoriel, vous pouvez ajouter une exégèse et nous la lirons avec plaisir.



Utilisez notre moteur de recherche

Ricerca
Generic filters

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.