Pourquoi Intel cache-t-il le kernel RISC interne dans ses processeurs?

À partir de Pentium Pro (microarchitecture P6), Intel a repensé ses microprocesseurs et utilisé le kernel interne RISC sous les anciennes instructions CISC. Depuis Pentium Pro, toutes les instructions CISC sont divisées en parties plus petites (uops), puis exécutées par le cœur RISC.

Au début, il était clair pour moi qu’Intel avait décidé de cacher une nouvelle architecture interne et de forcer les programmeurs à utiliser le “shell CISC”. Grâce à cette décision, Intel a pu repenser l’architecture des microprocesseurs sans compromettre la compatibilité, c’est raisonnable.

Cependant, je ne comprends pas une chose: pourquoi Intel conserve-t-il toujours un ensemble d’instructions RISC internes pendant tant d’années? Pourquoi ne laisseraient-ils pas les programmeurs utiliser les instructions RISC comme l’utilisation des anciennes instructions du CISC x86?

Si Intel maintient la rétrocompatibilité pendant si longtemps (nous avons toujours le mode 8086 virtuel près du mode 64 bits), pourquoi ne nous permettent-ils pas de comstackr des programmes pour contourner les instructions CISC et utiliser directement le kernel RISC? Cela ouvrira un moyen naturel d’abandonner lentement le jeu d’instructions x86, qui est aujourd’hui obsolète (c’est la raison principale pour laquelle Intel a décidé d’utiliser le kernel RISC, n’est-ce pas?).

En regardant la nouvelle série Intel ‘Core i’, je vois qu’ils ne font qu’étendre le jeu d’instructions CISC en ajoutant AVX, SSE4 et autres.

Non, le jeu d’instructions x86 n’est certainement pas obsolète. Il est aussi populaire que jamais. La raison pour laquelle Intel utilise un ensemble de micro-instructions de type RISC en interne est qu’elles peuvent être traitées plus efficacement.

Un processeur x86 fonctionne donc avec un décodeur assez puissant dans l’interface, qui accepte les instructions x86 et les convertit en un format interne optimisé, que le serveur peut traiter.

Quant à exposer ce format à des programmes “externes”, il y a deux points:

  • ce n’est pas un format stable. Intel peut le changer entre les modèles de CPU afin de l’adapter au mieux à l’architecture spécifique. Cela leur permet d’optimiser leur efficacité et cet avantage serait perdu s’ils devaient se contenter d’un format d’instruction fixe et stable pour un usage interne et externe.
  • il n’y a rien à gagner en le faisant. Avec les processeurs énormes et complexes actuels, le décodeur est une partie relativement petite du processeur. Le fait de devoir décoder les instructions x86 rend cela plus complexe, mais le rest du processeur n’est pas affecté, donc, globalement, il y a très peu à gagner, surtout parce que l’interface x86 devrait toujours être là pour exécuter du code “hérité” . Donc, vous ne pouvez même pas enregistrer les transistors actuellement utilisés sur l’interface x86.

Ce n’est pas tout à fait un arrangement parfait, mais le coût est assez petit, et c’est un choix bien meilleur que la conception du processeur pour supporter deux jeux d’instructions complètement différents. (Dans ce cas, ils finiraient probablement par inventer un troisième ensemble de micro-opérations pour un usage interne, simplement parce que celles-ci peuvent être modifiées librement pour s’adapter au mieux à l’architecture interne du processeur)

Si Intel maintient la rétrocompatibilité pendant si longtemps (nous avons toujours le mode 8086 virtuel près du mode 64 bits), pourquoi ne nous permettent-ils pas de comstackr des programmes pour contourner les instructions CISC et utiliser directement le kernel RISC? Cela ouvrira un moyen naturel d’abandonner lentement le jeu d’instructions x86, qui est aujourd’hui obsolète (c’est la raison principale pour laquelle Intel a décidé d’utiliser le kernel RISC, n’est-ce pas?).

Vous avez besoin de regarder l’angle de l’entreprise de cela. Intel a en fait essayé de s’éloigner de x86, mais c’est la poule aux œufs dorés pour l’entreprise. XScale et Itanium n’ont jamais été aussi proches du succès de leur activité x86.

Ce que vous demandez essentiellement à Intel, c’est de lui trancher les poignets en échange de fuzzies chauds de la part des développeurs. Inonder x86 n’est pas dans leur intérêt. Tout ce qui empêche les développeurs de choisir de cibler x86 nuit à x86. Cela, à leur tour, les affaiblit.

La vraie réponse est simple.

Le principal facteur de mise en œuvre des processeurs RISC était de réduire la complexité et de gagner en rapidité. L’inconvénient de RISC est la densité réduite des instructions, ce qui signifie que le même code exprimé dans un format similaire à RISC nécessite plus d’instructions que le code CISC équivalent.

Cet effet secondaire ne signifie pas beaucoup si votre processeur fonctionne à la même vitesse que la mémoire, ou du moins si les deux s’exécutent à des vitesses raisonnablement similaires.

Actuellement, la vitesse de la mémoire par rapport à la vitesse du processeur montre une grande différence dans les horloges. Les processeurs actuels sont parfois cinq fois plus rapides que la mémoire principale.

Cet état de la technologie favorise un code plus dense, ce que la CISC fournit.

Vous pouvez soutenir que les caches pourraient accélérer les processeurs RISC. Mais on peut dire la même chose à propos du cpus de la CISC.

Vous obtenez une plus grande rapidité en utilisant CISC et les caches que RISC et les caches, car le cache de même taille a plus d’effet sur le code haute densité fourni par CISC.

Un autre effet secondaire est que RISC est plus difficile sur la mise en œuvre du compilateur. Il est plus facile d’optimiser les compilateurs pour les cpus de l’ICCA. etc.

Intel sait ce qu’ils font.

C’est tellement vrai que ARM a un mode de densité de code plus élevé appelé Thumb.

La réponse est simple. Intel ne développe pas de CPU pour les développeurs ! Ils les développent pour les personnes qui prennent les décisions d’ achat , ce que BTW, c’est ce que fait chaque entreprise dans le monde!

Il y a longtemps qu’Intel s’était engagé à ce que, dans la mesure du possible, leurs processeurs restnt compatibles avec les versions antérieures. Les gens veulent savoir que, lorsqu’ils achètent un nouvel ordinateur Intel, tous leurs logiciels actuels fonctionneront exactement comme sur leur ancien ordinateur. (Bien que, espérons-le, plus vite!)

En outre, Intel sait exactement à quel point cet engagement est important, car il a déjà essayé de changer les choses. Combien de personnes connaissez- vous exactement avec un processeur Itanium?!?

Vous ne l’aimez peut-être pas, mais cette décision, de restr avec le x86, est ce qui a fait d’Intel l’un des noms commerciaux les plus reconnaissables au monde!

La réponse de jalf couvre la plupart des raisons, mais il y a un détail intéressant qu’il ne mentionne pas: le kernel interne de type RISC n’est pas conçu pour exécuter un jeu d’instructions comme ARM / PPC / MIPS. La taxe x86 n’est pas seulement payée dans les décodeurs gourmands en énergie, mais dans une certaine mesure dans le kernel. c’est-à-dire que ce n’est pas juste l’encodage des instructions x86; c’est chaque instruction avec une sémantique étrange.

Imaginons qu’Intel ait créé un mode de fonctionnement où le stream d’instructions était différent de x86, avec des instructions plus directement mappées sur uops. Supposons également que chaque modèle de processeur possède son propre ISA pour ce mode, ils sont donc toujours libres de changer les composants internes quand ils le souhaitent, et de les exposer avec un minimum de transistors pour le décodage des instructions de ce format alternatif.

Vraisemblablement, vous auriez toujours le même nombre de registres, mappés sur l’état de l’architecture x86, afin que les systèmes d’exploitation x86 puissent les sauvegarder / restaurer sur les commutateurs de contexte sans utiliser le jeu d’instructions spécifique à la CPU. Ce n’est probablement pas trop difficile, car le matériel de renommage de registre existe déjà. (Les uops internes font en réalité référence au fichier de registre physique, mais notre hypothétique RISC ISA n’aurait pas à le faire).


Si nous n’avons que des décodeurs alternatifs sans modification des étapes ultérieures du pipeline (unités d’exécution), cet ISA aurait encore de nombreuses excensortingcités x86. Ce ne serait pas une très belle architecture RISC. Aucune instruction unique ne serait très complexe, mais une partie de la folie de x86 serait toujours présente.

Par exemple: les décalages gauche / droite laissent l’indicateur de débordement indéfini, à moins que le nombre de décalages ne soit un, auquel cas OF = la détection habituelle de dépassement signé. Folie similaire pour les rotations. Cependant, les instructions RISC exposées peuvent fournir des décalages sans indicateur, etc. (permettant d’utiliser seulement un ou deux des multiples uops qui entrent généralement dans certaines instructions x86 complexes). Donc, cela ne résiste pas vraiment au contre-argument principal.

Si vous envisagez de créer un tout nouveau décodeur pour une ISA RISC, vous pouvez le sélectionner et choisir des parties d’instructions x86 à exposer en tant qu’instructions RISC. Cela atténue quelque peu la spécialisation x86 du kernel.


Le codage des instructions ne serait probablement pas de taille fixe, car les commandes uniques peuvent contenir beaucoup de données. Beaucoup plus de données que de sens si tous les insns ont la même taille. Un seul micro-fusible peut append un 32bit immédiat et un opérande de mémoire utilisant un mode d’adressage avec 2 registres et un déplacement de 32 bits. (Dans SnB et les versions ultérieures, seuls les modes d’adressage à registre unique peuvent fusionner avec les opérations ALU).

Les instructions sont très volumineuses et peu similaires aux instructions ARM à largeur fixe. Un jeu d’instructions 32 bits à largeur fixe ne peut charger que les données immédiates à 16 bits à la fois. Le chargement d’une adresse à 32 bits nécessite donc une paire à faible débit / à charge immédiate immédiate. x86 n’a pas à faire cela, ce qui aide à ne pas être terrible avec seulement 15 registres GP limitant la possibilité de garder des constantes dans les registres. (15 est une grande aide sur 7 registres, mais doubler encore à 31 aide beaucoup moins, je pense que certaines simulations ont été trouvées. RSP n’est généralement pas un outil général, donc il ressemble plus à 15 registres GP et un stack.)


TL; résumé DR:

Quoi qu’il en soit, cette réponse se résume à “le jeu d’instructions x86 est probablement le meilleur moyen de programmer un processeur qui doit être capable d’exécuter rapidement des instructions x86”, mais jette un peu de lumière sur ces raisons.

Pourquoi ne nous permettent-ils pas de comstackr des programmes pour contourner les instructions du CISC et utiliser directement le kernel RISC?

Outre les réponses précédentes, une autre raison est la segmentation du marché. Certaines instructions sont supposées être implémentées dans un microcode plutôt que dans du matériel, donc permettre à quiconque d’exécuter des micro-opérations arbitraires peut compromettre la vente de nouveaux processeurs avec de “nouvelles” instructions CISC plus performantes.