Wafer Chips

Pour des raisons de compatibilité, il est bien pratique de rassembler des CPU sous une même famille. Pourtant, parfois, tout ne se passe pas comme prévu...

Seules deux grandes familles de CPU ont réussi à se frayer un chemin jusqu’aux oreilles du grand public en cette décennie 2020 : x86 (ou amd64 pour les puristes) et Arm. Or, derrière ces noms barbares se cachent en fait un jeu d’instructions (ou ISA pour l’acronyme anglophone) à savoir une spécification très précise de la manière de communiquer avec un processeur. Et, comme tout est toujours bien plus compliqué qu’au premier abord, une même famille cache en réalité une histoire, voire des fonctionnalités bien différentes. Pour le x86, son patronyme a beau provenir de l’Intel 8086 de 1978, le jeu d’instruction a bien évolué, si bien que la version moderne n’utilise plus grand-chose des instructions originelles… et c’est tant mieux !

Un monde sépare ce 8086 des récents Meteor Lake... et pourtant, le dernier est théoriquement compatible avec le langage du premier !

Pire, outre les ajouts et ajustements d’instructions permettant de passer du 16-bit adressage réel originel au 64-bit adressage virtuel standard de nos jours, des fonctionnalités complètement nouvelles ont été ajoutées : il est alors question d’extension du jeu d’instruction. Puisque l’intégration de ces dernières est (généralement) croissante avec le temps — des fonctionnalités sont souvent ajoutées, mais rarement retirées —, des nommages alternatifs ont vu le jour, particulièrement dans la communauté Linux ou des applications plus ou moins optimisées peuvent être téléchargés selon le niveau de compatibilité du CPU.

La segmentation a été effectuée par Red Hat, SUSE, Intel, et AMD, autant dire que ça n’a pas du rigoler pour mettre tout le monde d’accord ! Du coup, le x86-64 répond strictement à la spécification de base du langage x86 adapté en 64-bit tel que proposé par AMD (d’où le nom d’amd64 que l’on retrouve ici et là), le x86-64-v2 lui rajoute les extensions SSE4.2, SSSE3 et POPCNT présentes dès les premiers Core i7 et les FX Bulldozer d’AMD. S’en suit la x86-64-v3 avec l’AVX2, une extension des instructions vectorielles SSE passant de 128 bits par registre à 256. Pour le x84-64-v4, c’est au tour de l’AVX-512 d’être prérequis, une extension qui, là aussi, double la taille des registres vectoriel pour passer à 512 bits et donc pouvoir calculer toujours plus rapidement, ce qui est pratique pour (au hasard…) les tâches liées aux réseaux de neurones.

Présentation de l'AVX10 selon Intel : le support des calculs en 512-bit est bel et bien optionnel

Sauf que pour le x86-64-v5, l’équation se complique grandement. Si la prochaine révision des extensions vectorielles, l’AVX10, semble naturellement être candidate au rang des prérequis, cela n’est pas si simple en pratique. La raison en est simple : l’AVX-512 s’est perdu dans un miasme de sous-fonctionnalités telles qu’il existe une vingtaine de bits spécifiant individuellement si telle ou telle capacité est supportée par votre machine : un cauchemar. Le but de l’AVX10 est alors de faire le ménage en proposant une interface simplifiée… tellement simplifiée qu’un processeur AVX10 pourra tout aussi bien ne supporter que les instructions 256-bit comme supporter également celles en 512-bit. Autant dire que la simplification a été légèrement trop brutale, si bien que les développeurs n’ont pas encore convergé sur le statut du x86-64-v5 ; et sont même à la recherche de suggestions. Des idées ? (Source : Phoronix)

Double Doc


  • il a morflé le 8086 de votre photo, c'est pas bien d'attaquer à la ponceuse un proco qui devrait être dans un musée.

    • Pour l'instant c'est qu'à l'état de concept et honnêtement j'espère qu'il n'arrivera jamais car coupé la compatibilité avec les applis 32bits, ça signifierait laisser le champ libre à arm vu la masse de logiciels 32bits encore utilisés et important surtout si on utilise des vieux jeux et logiciels. Or, il n'existe pas d'outil comme pour les applis 16bits à l'heure actuelle pour compenser cette perte surtout pour les jeux.

      • Intel parle de virtualiser pour les anciennes applications

        Si ça peut simplifier les architectures et laisser de la place pour autre chose je suis pour

        • Virtualiser oui mais faudra que ça soit efficace car à l'heure actuelle, les outils de virtualisation pour les jeux par exemple, c'est très médiocre. Toutes les VMs ne sont pas adaptées aux jeux mais si le x86s sort, c'est pas avant longtemps

          De toute façon Intel a dit que c'était un brouillon hypothétique, pas un probable futur.

          • En fait, les instructions flottantes x87 sont virtualisées depuis un bail sur les CPU mais cela reste au niveau matériel. À voir sur le x87S s'il s'agit d'émulation logicielle ou matérielle...

      • Ca ne concerne pas les applis 32 bits, le long mode a un sous-mode pour assurer la compatibilité avec le mode protégé 32 bits, et c'est ce qui est utilisé par tous les Windows 64 bits pour exécuter les vieilles applis 32 bits.

        Ca concerne uniquement le mode réel 16 bits et le "vrai" mode protégé 32 bits (et le sous mode Virtual 86), donc c'est surtout un problème pour les applis Win16 que peuvent faire tourner Windows 3.x, et les applis MS-DOS, qui il faut l'avouer ont un support branlant dans les Windows 32 bit depuis XP/2k (et absent des Windows 64 bit). Donc non c'est pas vraiment un problème.

        À savoir, un PC encore relativement moderne, disposant d'un UEFI qui émule le BIOS (module CSM), peut booter et faire tourner MS-DOS et ses jeux, mais sans son (absence de compatibilité Sound Blaster ISA). Il y a différents projets pour contourner cette limitation (SBEMU, dISAppointment, ...), mais en plus du son, le support des modes vidéo legacy (CGA, EGA, VESA) est de plus en plus pété sur nos cartes graphiques.

        Mais justement depuis quelques générations chez Intel il n'y a plus d'émulation du BIOS, donc le retrait du mode réel et protégé 32 bits n'est que la suite logique et pas impactant, le mal a déjà été fait.

7 commentaires

Laissez votre commentaire

En réponse à Some User