Et si....

[Papy.G]

C'est ce à quoi je pensais en parlant des autres voies d'optimisation aussi, plus de registres, des DPTR secondaires, des piles spéciales interruptions, des banques de registres contextualisables…
Certains proc. de l'époque ont certains de ces raffinements, le 8051 a des banques de registres indexés, par exemple.

Mais aussi, quand on a un processeur qui a besoin de 12 impulsions au moins pour exécuter une instruction, et qu'il tourne à 12MHz, il faut de la mémoire très rapide par rapport à la puissance du processeur de seulement 1MIPs maximum, les optimisations de l'ALU permettent souvent de baisser le ratio de moitié ou un tiers, pour les optimisations au-delà, obligé de faire du prefetch.

Le fait de pouvoir ou non faire appel à de la mémoire cache est spécifique à chaque architecture, le G3 (PPC750) a été critiqué à son époque à cause de sa gestion "prédictive", où il chargeait l'instruction suivante pendant l'exécution de la courante, ce qui lui faisait perdre du temps sur les instructions de branchement, en cas de "pari" sur la mauvaise branche. Je n'ai pas étudié ce processeur, mais c'est une info qui était reprise partout, vraie ou pas.

[__sam__]

La prédiction de cache est toujours d'actualité dans les processeurs modernes.

Pour en avoir discuté avec le concepteur du coeur apollo (cf ma vampire), ce qu'il se passe --si j'ai bien tout compris-- est le fait que dans le cache instruction il y a pour chaque instruction du type "branchement conditionnel" la dernière valeur vrai ou faux du test et la dernière instruction exécutée en conséquence. Quant le branchement conditionnel revient --sans avoir quitté le cache-- le processeur présume que le test vaudra la valeur précédente ce qui est souvent le cas (penser aux boucles) et rajoute dans le pipeline immédiatement l'instruction suivante exécutée la dernière fois sans encore connaitre la valeur du test (qui ne sera dispo qu'en fin de pipeline). Ainsi l'instruction suivante la plus probable se voit décodée dans les divers étages du pipeline sans être certain qu'elle doit bien l'être. C'est un pari qui est fait basé sur ce que ce test a fait la dernière fois.

Plus tard dans le pipeline quand l'instruction de branchement récupère les flags et est en mesure de calculer la valeur du test, elle vérifie s'il est identique à la valeur précédemment évaluée. Si c'est le cas alors on est bon le pipeline est déjà en train de décoder l'instruction. Le pari était gagnant. Sinon ben on a mal parié et ca devient plus ou moins couteux suivant la sophistication du processeur.

Les moins sophistiqués doivent vider tous le cache pour le re-remplir à nouveau avec la bonne instruction. C'est le cas du PPC, et c'est super coûteux, surtout si le pipeline a plein d'étage. Mais certains processeur sont plus malins et ont pu mettre dans le pipeline les 2 instructions devant être possiblement exécutées suivant que le test soit vrai ou faux[*] et signale à la mauvaise instruction qu'elle ne doit pas mettre à jour le résultat dans la dernière étape du pipeline. En gros le processeur prends les deux options et signale à la mauvaise qu'elle doit mettre son calcul à la poubelle. On fait un calcul en trop pour rien, mais c'est moins grave que de vider le pipeline complet. En plus faire des calculs en trop n'est pas si coûteux quand il y a pleins d'unités de calculs à disposition qui tournent en parallèle (processeur multi/super/hyper-threadés).
___
[*] avec quelques restrictions sur les instructions cependant comme par exemple que la destination du calcul est forcément un registre processeur et pas celui d'un coproc ou de la mémoire externe.

Avec les bonnes stratégies, le test arrive à être à coût nul même s'il était mal prédit.