Avec le x86S, Intel souhaitait alléger son jeu d’instruction — le langage compris par ses CPU, ou Instruction Set Assembly (ISA) en anglais — histoire de simplifier la vie des designers hardware et gagner en efficacité. Vu que le x86 est (toujours !) rétrocompatible avec les instructions initiales du 8086 (de 1978…), nous nous doutons qu’il y a matière à simplifier, par exemple du côté du x87, depuis supplanté par le SSE en ce qui concerne les calculs en nombre à virgule flottante. D’ailleurs, les bleus ne s’étaient pas gênés de retirer des CPU grand public le SGX (extension garantissant de manière matérielle l’intégrité de l’environnement d’exécution) quand bien même ces dernières étaient utilisées lors de la protection des Blu-Ray ; ou encore l’extension TSX gérant des mémoires transactionnelles — bien que toutes deux restent disponibles sur serveurs.
Or, ce x86S devait être bien plus qu’un retrait d’extensions inutilisées, mais un abandon complet de certaines fonctionnalités au niveau système, à savoir un passage au 64-bit uniquement, et zou : on oublie le mode 16-bit réel (pour le moment celui par défaut des CPU au démarrage !), on vire les vieilles tares des segments dont l’utilité était préadressage virtuel, les rings 1 et 2 (niveau de privilèges intermédiaires entre le mode noyau et le mode utilisateur, initialement pensés pour les pilotes, mais jamais exploités en pratique), et on nettoie de contrôleur d’interruption pour ne laisser que le mode X2APIC moderne. L’avantage de tout ce nettoyage de printemps est de limiter la complexité aussi bien logicielle que matérielle… au détriment de la rétrocompatibilité, puisque la case virtualisation serait alors obligatoire pour exécuter un OS x86-normal : voilà qui fait tout de même grincer des dents.
Si l’abandon du projet peut paraître surprenant tant l’intention initiale était louable, ce serait oublier deux choses. D’une part, l’écosystème Arm menace l’entrée de gamme des laptops et le segment de ultrabook à grande autonomie ; et, d’autre part, Intel s’est investi dans le x86 Ecosystem Advisory Group visant à faire du lobby pour l’ISA x86 : autant dire que ce x86S n’a plus vraiment de raison d’exister dans l’était actuel du marché PC. RIP ! (Source : Tom’s Hardware)
Peut-être qu'il y a un moyen "hybride" de toiletter tout ça, comme intégrer un vieux core P6/K7 pour booter et exécuter les applications 32 bit? Les cores principaux étant alors uniquement 64-bit, en virant tout les vieux trucs, même le x87?
Les archi P6(intel) et K7(amd) sont bien trop récent dans le contexte de la news.
Il est question de jeux d'instructions originelles en provenance du 8086.
Par exemple l'archi P6 reprend des concepts RISC alors que le x86 est catégorisé CISC.
(en fait plus aucun cpu est exclusivement RISC ou CISC, le "meilleur" des deux mondes est souvent intégré et amélioré)
=> Superscalaire.
Aussi le K7 emprunte un grand nombre de technologie à l'Alpha de DEC (merci Keller). C'est lui aussi un cpu qui utilise des briques RISC.
Enfin comme évoqué dans l'article, le but était de se séparer des vielles ruines 16bits. Les archi P6 et K7 doivent être considérées comme déjà polluées par l'historique 16bits du 8086.
C'est justement tout l'intérêt de P6 et K7 : elles contiennent tout l'historique du x86 (jusqu'à SSE) avant le 64-bit, et devraient être encore assez performantes pour exécuter les vieux trucs.
Je me suis mal fait comprendre ...
=> Ce serait un ajout de lourdeur et contre productif.
Pour le boot :
Il faudrait que l'instanciation de démarrage passe par le "core" P6/K7 selon la demande. Comment définir cette "demande" ?
Pour l'exécution à la volée :
Il faudrait que le binaire soit interprété/flagué pour être exécuté par le "core" P6/K7. Comment mettre en œuvre cette sélection sans ajouter de la lourdeur ?
Implémentation physique du "core" P6/K7 :
Il faudrait adapter l'ancien core à la méthode courante de gravure (finesse, intégration, interposer, ...). Un casse-tête pour ajouter de la complexité. Cela aura pour effet de "tordre" le core P6/K7 et l'archi porteuse et donc en rendre le comportement instable.
Bref, cela impliquerait une complexité de conception accrue la ou on veut la réduire, et une complexité de fonctionnement (logiciel). Tout cela serait éminemment contre productif.
L'idée d'Intel n'était pas mauvaise en soi ... en gros pouvoir faire ce que seuls les acteurs de l'intégration verticale sont capables de faire (Apple/IBM). Mais ils n'ont pas la maitrise du logiciel (l'OS utilisé sera certainement Windows), ils sont donc incapable d'imposer une refonte ou un gros ménage de printemps.
Pour info Windows 7 (je ne sais pas pour le 11) était encore compatible avec DOS sur le pilotage des lecteurs de disquettes (conséquence que chacun peut vivre, le système Windows 7 est inutilisable lorsqu'il écrit sur une disquette). Microsoft et Intel portent des poids similaires de l'histoire, l'impossibilité de se séparer de l'historique pour des raisons de rétrocompatibilité et surtout le fait d'être une partie d'un environnement (le PC) et non l'acteur en pleine charge de cet environnement (le Mac).
c'est dommage je trouvais que c'était une bonne idée
par contre de se que j'ai compris c'est qu'intel arrête vu qu'avec la nouvelle alliance qu'il a formé il ne peut plus faire ça seul mais ça peut être repris dans l'alliance