Ce que je voulais dire, c'est que si un processeur permet de redéfinir son propre jeu d'instruction en cours d'exécution, alors le compilateur est face à davantage de choix pour déterminer le jeu d'instruction optimal pour un segment de code donné.
La question de savoir sur quel segment de code on se base pour chercher un bon jeu d'instruction est d'ailleurs très intéressante. Juste un exemple : changer de jeu au beau milieu d'une triple boucle hyper utilisée, c'est par exemple pas très malin, mais comment le compilo peut-il le deviner ?
J'aimerais bien savoir ce qu'en pense notre expert ès-compilation national :
!call SebRmv
--- Call : SebRmv appelé(e) sur ce topic ...
Seb, tu as entendu parler autour de toi de ce genre de proc (reprogrammable) et des techniques d'optim' associées ? Il y a de la recherche là-dessus ? des benchs ?
Pour aller plus loin dans la discussion, il y a aussi des questions nouvelles qui se soulèvent : selon que le jeu d'instruction est X ou Y est actif, un même opcode (en cache par exemple) peut avoir deux significations différentes. Difficulté supplémentaire pour interpréter du code désassemblé ! Il faut savoir quel est le jeu d'instruction actif au moment où le code est exécuté. Ca rappelle les joies du code généré