Pourquoi X86 doit mourir

Comme beaucoup d’entre vous le savent, l’architecture x86 existe depuis un certain temps. Il trouve ses racines dans le premier processeur Intel 8086, le premier de la famille. En effet, même le 8086 d'origine hérite d'une petite partie de la structure architecturale des prédécesseurs 8 bits d'Intel, remontant au 8008. Mais le 8086 a évolué pour devenir les 186, 286, 386, 486, puis ils ont reçu des noms : Pentium. aurait été le 586.

En cours de route, de nouvelles instructions ont été ajoutées, mais le cœur du jeu d'instructions x86 a été conservé. Et beaucoup d'efforts ont été consacrés à rendre les mêmes instructions de plus en plus rapides. Cela est devenu si extrême que, même si le 8086 et les processeurs Xeon modernes peuvent tous deux exécuter un sous-ensemble de code commun, les deux processeurs semblent architecturalement aussi éloignés que possible.

Nous voilà donc aujourd'hui, avec même les processeurs x86 les plus haut de gamme prenant toujours en charge le mode réel archaïque 8086, dans lequel le processeur peut adresser directement la mémoire, sans aucune redirection. Avoir ce niveau de rétrocompatibilité peut poser des problèmes, notamment en ce qui concerne le multitâche et la protection de la mémoire, mais c'était une fonctionnalité des puces précédentes, c'est donc une fonctionnalité des conceptions x86 actuelles. Et il y a plus !

Je pense qu'il est temps de mettre fin à une grande partie de l'héritage du 8086 et de laisser les processeurs modernes fonctionner librement.

Quelques termes clés

Pour comprendre mes prochains arguments, vous devez comprendre les bases de quelques concepts. Le x86 moderne est, pour utiliser la terminologie appropriée, une architecture Von Neumann CISC, superscalaire et désordonnée avec une exécution spéculative. Qu’est-ce que tout cela signifie ?

Les architectures Von Neumann sont des processeurs dans lesquels le programme et les données existent dans le même espace d'adressage. Il s'agit de la capacité de base d'exécuter des programmes à partir de la même mémoire dans laquelle les données régulières sont stockées ; il n'y a pas de distinction logique entre la mémoire de programme et la mémoire de données.

Les cœurs de processeur superscalaires sont capables d’exécuter plus d’une instruction par cycle d’horloge. Cela signifie qu'un processeur x86 fonctionnant à 3 GHz fonctionne réellement plus plus de 3 milliards d'instructions par seconde en moyenne. Cela va de pair avec la nature hors service du x86 moderne ; le processeur peut simplement exécuter les instructions dans un ordre différent de celui dans lequel elles sont présentées si cela est plus rapide.

Enfin, il y a le mot-clé spéculatif qui cause tous ces problèmes. L'exécution spéculative consiste à exécuter des instructions dans un chemin de branchement, même s'il n'est pas clair si lesdites instructions doivent être exécutées en premier lieu. Considérez cela comme l'exécution du code dans un if déclaration avant de savoir si la condition de ladite if la déclaration est vraie et inverser l’état du monde si la condition s’avère fausse. Il s’agit d’un territoire intrinsèquement risqué en raison des attaques par canal secondaire.

Mais qu'est-ce que x86 Rvraiment ?

Schéma fonctionnel 8086 par Harkonnen2
Schéma fonctionnel de l'architecture Zen 4 d'AMD

Ici, vous pouvez voir des schémas fonctionnels des microarchitectures de deux processeurs apparemment totalement indépendants. Ne vous laissez pas tromper par les apparences ; le processeur Zen 4 toujours prend en charge le « mode réel » ; il peut toujours exécuter 8086 programmes.

Le 8086 est un processeur beaucoup plus simple. Il faut plusieurs cycles d'horloge pour exécuter des instructionsa : entre 2 et plus de 80. Un cycle est requis par octet d'instruction et un ou plusieurs cycles pour les calculs. Il n’y a pas non plus de concept de superscalaire ou de désordre ici ; tout prend un temps prédéterminé et se déroule strictement dans l'ordre.

En revanche, Zen 4 est un monstre : non seulement il possède quatre ALU, mais également trois AGU. Certains d’entre vous ont peut-être déjà entendu parler de l’unité arithmétique et logique, mais l’unité de génération d’adresses est moins connue. Tout cela signifie que Zen 4 peut, dans des conditions parfaites, effectuer quatre opérations ALU et trois opérations de chargement/stockage par cycle d'horloge. Cela rend le Zen 4 deux à dix plus rapide que le 8086 à la même vitesse d'horloge. Si vous prenez également en compte la vitesse d’horloge, elle se rapproche d’environ cinq à sept ordres de grandeur. Malgré cela, les processeurs Zen 4 prennent toujours en charge les instructions 8086 d'origine.

Où réside le problème

Le jeu d’instructions 8086 n’est pas le seul jeu d’instructions pris en charge par le x86 moderne. Il existe des dizaines de jeux d'instructions, depuis les célèbres extensions à virgule flottante, SSE, AVX et autres extensions vectorielles jusqu'à l'obscur PAE (pour que x86 32 bits ait des adresses plus larges) et vGIF (pour les interruptions dans la virtualisation). Selon [Stefan Heule], il peut y avoir jusqu'à 3 600 instructions. Cela représente plus de vingt fois plus d'instructions que RISC-V, même si vous comptez tous des extensions RISC-V les plus courantes.

Ces instructions ont un coût. Prenez, par exemple, l'une des instructions bizarres de x86 : mpsadbw. Cette instruction fait six à sept octets et compare les différences entre une séquence de quatre octets dans plusieurs positions d'une séquence de onze octets. Cela nécessite au moins 19 ajouts, mais le processeur l'exécute en seulement deux cycles d'horloge. Le premier problème est la longueur. La combinaison de la longueur des instructions de six à sept octets et de l’absence d’exigences d’alignement rend la récupération des instructions beaucoup plus coûteuse. Cette instruction existe également dans une variante accédant à la mémoire, ce qui complique le décodage de l'instruction. Enfin, cette instruction est toujours supportée par les processeurs modernes, même s’il est rare de la voir utilisée. Tout cela occupe un espace précieux dans les processeurs x86 de pointe.

Dans les architectures RISC comme MIPS, ARM ou RISC-V, l'implémentation des instructions est entièrement matérielle ; il existe des portes logiques dédiées pour exécuter certaines instructions. Le 8086 a également commencé de cette façon, ce qui serait une plaisanterie coûteuse si c'était toujours le cas. C'est là qu'intervient le microcode. Vous voyez, les processeurs x86 modernes ne sont pas ce qu'ils semblent être ; ce sont en fait des processeurs RISC se faisant passer pour des processeurs CISC, implémentant les instructions x86 en les traduisant à l'aide d'un mélange de matériel et de microcode. Cela donne à x86 la possibilité de mettre à jour son microcode, mais uniquement pour modifier le fonctionnement des instructions existantes, ce qui a atténué des problèmes tels que Spectre et Meltdown.

Heureusement, cela peut empirer

Revenons à ces mots-clés embêtants : spéculatif et hors service. Le x86 moderne exécute des instructions dans le désordre pour, par exemple, faire des calculs en attendant un accès à la mémoire. Supposons un instant que c'est tout ce qu'il y a à faire. Face à une division qui utilise la valeur de rax suivi d'une multiplication qui écrase rax, la multiplication doit logiquement être exécutée après la division, même si le résultat de la multiplication ne dépend pas de celui de la division. C'est là qu'intervient le renommage des registres. Avec le renommage des registres, les deux peuvent s'exécuter simultanément car le rax que voit la division est un registre physique différent de celui rax dans lequel la multiplication écrit.

Cette accélération nous pose deux problèmes : déterminer quelles instructions dépendent de quelles autres, et les planifier de manière optimale pour exécuter le code le plus rapidement possible. Ces problèmes dépendent des instructions particulières exécutées et leur logique de solution se complique à mesure qu’il existe d’instructions. Le format de codage des instructions x86 est si complexe qu'une page wiki entière est nécessaire pour servir de TL;DR. Pendant ce temps, RISC-V n'a besoin que de deux tableaux (1) (2) pour décrire le codage de toutes les instructions standard. Inutile de dire que cela désavantage x86 en termes de complexité logique de décodage.

Le changement arrive

Au fil du temps, d'autres jeux d'instructions comme ARM ont grignoté la part de marché du x86. ARM domine totalement les smartphones et les ordinateurs monocarte, se développe sur le marché des serveurs et est même devenu la principale architecture CPU des appareils Apple depuis 2020. RISC-V devient également progressivement plus populaire, devenant le plus largement adopté. instruction libre de droits définie à ce jour. RISC-V est actuellement principalement utilisé dans les microcontrôleurs, mais se développe lentement vers des plates-formes plus puissantes telles que les ordinateurs monocarte et même les ordinateurs de bureau. RISC-V, aussi gratuit soit-il, devient également l'architecture de choix pour les cours d'informatique d'aujourd'hui, ce qui ne fera que le rendre plus populaire au fil du temps. Pourquoi? En raison de sa simplicité.

Conclusion

L’architecture x86 existe depuis longtemps : 46 ans. À cette époque, l’informatique est passée des simples jours des premiers microprocesseurs au monolithe informatique incroyablement complexe que nous avons aujourd’hui.

Cette évolution a cependant eu des conséquences néfastes, en limitant l'une des plus grandes plates-formes de processeur aux racines d'un jeu d'instructions relativement ancien, qui ne bénéficie même pas d'une petite taille de code comme il y a 46 ans. Les complexités de l'exécution superscalaire, spéculative et dans le désordre pèsent lourdement sur un jeu d'instructions qui est déjà très complexe par définition et les faucheuses en forme de RISC nommées ARM et RISC-V rattrapent lentement leur retard.

Ne vous méprenez pas : je ne déteste pas le x86 et je ne dis pas qu'il doit mourir aujourd'hui. Mais une chose est claire : les jours du x86 sont comptés.

François Zipponi
Je suis François Zipponi, éditorialiste pour le site 10-raisons.fr. J'ai commencé ma carrière de journaliste en 2004, et j'ai travaillé pour plusieurs médias français, dont le Monde et Libération. En 2016, j'ai rejoint 10-raisons.fr, un site innovant proposant des articles sous la forme « 10 raisons de... ». En tant qu'éditorialiste, je me suis engagé à fournir un contenu original et pertinent, abordant des sujets variés tels que la politique, l'économie, les sciences, l'histoire, etc. Je m'efforce de toujours traiter les sujets de façon objective et impartiale. Mes articles sont régulièrement partagés sur les réseaux sociaux et j'interviens dans des conférences et des tables rondes autour des thèmes abordés sur 10-raisons.fr.