ISA ne pardonne pas les erreurs

–X86 est un malentendu historique, - le maître et en 80 n'a pas perdu l'enthousiasme polémique.
"En fait, elle détient 95% du marché des serveurs", répondis-je lentement. Je ne voulais pas discuter sur un sujet cent fois galvaudé
- et je suis déjà confus dans ces préfixes, - l'académicien n'a pas cédé. - 15 octets par instruction, c'est impensable!
- Pas de glace, bien sûr. Mais qui est le meilleur?
- Oui, n'importe qui, au moins ARM-a.
"Je ne comprends toujours pas." Les ajouts avec multiplications devraient être?
- Devrait.
- Et des décalages avec des opérations logiques?
- Oui.
- Et les téléchargements avec sauvegardes aussi. Quelle est la différence dans la façon dont ils sont appelés et encodés?

Comme d'habitude, j'ai réalisé l'exactitude de l'enseignant beaucoup plus tard. Quand je me suis assis pour écrire un décodeur de commandes dans une morne soirée d'hiver afin de m'amuser en quelque sorte. J'ai réussi à représenter un simple décodeur pour ARM sur VHDL (et je le connais pas mal) en quelques jours. C'est vrai, je me repens, j'avais une feuille de triche. :)



Pour X86 ce n'était pas possible pendant une semaine, ni pour deux, ni pour un mois ... Même pour le set de base.

Ici, la différence n'est pas seulement dans RISC (Reduced Instruction Set Computing) pour ARM et CISC (Complex Instruction Set) pour X86. La différence est plutôt dans le chemin du développement historique. Il y a plus de 40 ans, et tout a commencé en 1978, le X86 ISA (Instruction Set Architecture) était un ensemble de commandes assez compact avec sa propre logique interne. Mais le temps a passé, la capacité des bus a augmenté, les registres ont augmenté (y compris SIMD), le nombre d'équipes n'a cessé d'augmenter. Puis un gars a fait une tentative intéressante pour simplement compter le nombre d'instructions dans X86. S'il était trop paresseux pour ouvrir le manuelet les compter, soit il connaissait l'existence d'opcodes «sans nom» (équipes qui n'ont même pas de nom), soit il croyait à l'omnipotence de la logique. Il est facile de comprendre que la logique s'est avérée impuissante. :) Au fait, j'ai essayé de trouver un graphique de la croissance du nombre d'instructions X86 par année (ou par génération). Je ne pourrais pas encore (peut-être que quelqu'un l'a?). Mais j'ai trouvé ici une telle photo .



Pour être honnête, je ne sais pas combien d'instructions il y a dans l'ISA X86. Mais je me souviens bien de tous ceux que j'ai investis dans le développement moi-même, sans réaliser que chaque nouveau bit dans ISA est étiqueté «garder pour toujours». Et il y avait plusieurs milliers de «créateurs» comme moi chez Intel. Et les morceaux pour encoder tous leurs fantasmes manquaient constamment. :) Tous les nouveaux préfixes ont été ajoutés au jeu de commandes existant: REX, VEX ... La dernière extension de quatre octets (EVEX) a été introduite pour l'AVX-512. Par ailleurs, l'ensemble des commandes ARM (même en tenant compte de SVE ) est supprimé dans ces mêmes 4 octets. ARM est initialement allé dans l'autre sens, construisant son système de commande sur les principes de base de simplicité, compacité et extensibilité.

La différence peut être comprise si nous passons du point de vue du programmeur au point de vue du concepteur de circuits. Et on sait que le transistor est une bonne chose, mais il commute lentement et dissipe l'énergie sans vergogne. Et toutes choses étant égales par ailleurs, il serait préférable qu'il y en ait moins. Maintenant, jetez un œil à l'algorithme de décodage des instructions x86 (le problème que j'essayais de résoudre).



Et comme on dit, ressentez la différence dans les chemins d'entrée (frontal) pour ARM et X86. Ici, on peut faire valoir que l'extrémité avant est une très petite partie du noyau, seulement environ 10%. Oui, mais n'oubliez pas que toute cette logique est multipliée par le nombre de cœurs sur la puce. Et c'est grave.

Une autre considération est que le frontal n'est que la partie responsable de la compatibilité descendante. Vous pouvez pelleter en toute sécurité ou même lancer l'arrière. Intel, soit dit en passant, en a profité au début des années 2000, remplaçant l'architecture NetBurst (P4) par Core-M (P3). Mais l'extrémité avant ne peut pas être considérablement réduite. Bien que parfois je le veuille vraiment, à cause de l'ISA X86 existant, environ 20% est maintenant utilisé. Les autres sont des vestiges du passé.

Un autre inconvénient de la longueur énorme des instructions est le manque relativement fréquent dans le cache d'instructions. Grosso modo, avec une taille égale de caches, le nombre de ratés sera d'autant plus important que la durée de l'instruction sera grande. Bien sûr, la taille des caches peut être augmentée. Mais là encore, ce sont des transistors qui n'auraient pas pu l'être si les instructions étaient plus courtes. Pour la même raison, je me méfie beaucoup des différents types d'architectures VLIW (Very Long Instruction World). Cependant, ils ont également l'inconvénient qu'il leur est très difficile de développer des compilateurs. Jusqu'à présent, j'ai délibérément évité le sujet des compilateurs, car je ne les ai jamais développés moi-même. Je voudrais écouter ce que les personnes compétentes diront sur les délices de développer des compilateurs pour RISC, CISC et VLIW.

Et pourtant, malgré l'énorme charge accumulée de l'héritage, et peut-être grâce à lui, les développeurs X86 étaient dans le principal. Le principe de la compatibilité descendante a été respecté en architecture depuis le tout début. Tous les logiciels existants fonctionnent sur le nouveau matériel prêt à l'emploi. C'est ce qui a permis de construire un écosystème aussi profond et développé autour de l'architecture. Et il ne reste plus qu'à décoller devant les ingénieurs Intel et AMD qui, malgré la conception ISA pas du tout parfaite, ont conservé leur leadership dans le segment des serveurs pendant de nombreuses années. Cependant, la charge héritée devient plus difficile.