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).
L'idée était de toujours booter sur le core P6/K7. Mais je n'avais pas pensé à l'EFI 32 bits qui complique les choses pour booter un OS 64 bits.
Pas besoin de flagger le binaire pour l'exécution 32 bits. Soit on boote en 32 bits avec un OS 32 bits et tout s'exécute en IA-32, soit l'exécution sur un OS 64 bits se fait via émulation ou virtualisation. C'est déjà plus ou moins le cas sur Windows avec WOW64 qui à terme pourrait totalement émuler l'application 32 bits.
Mais en fait, une partie du problème pourrait se régler tout seul : Windows 11 est 64-bit uniquement, et fait de l'obsolescence "programmée" avec les vieux CPU. A un moment donné Intel et AMD pourront retirer une grosse partie de l'héritage du x86 sans gêner grand monde.
Ce serait un bazooka pour tuer une fournmi.
Rappel : les processeurs x86 dits 64 bits, ne le sont pas vraiment. Ou du moins pas totalement (c'est d'ailleurs le pourquoi du sujet de la news), ils disposent d'une extension de leur jeux d'instructions et des capacités d'adressage en 64bits. De plus il existe des jeux d'instructions vectorielles en 128bits sur x86 ... bref, il faut faire attention de ne pas tout mélanger et faire des raccourcis qui mènent à des raisonnements érronés.
"Windows 11 est 64-bit uniquement"
Oui et non, attention aux raccourcis. Il est x86-64 uniquement.
"A un moment donné Intel et AMD pourront retirer une grosse partie de l'héritage du x86 sans gêner grand monde."
Cela n'arrivera pas de si tôt.
Il est même x86_64 et arm64 👌. J'ai trouvé le blog post de Microsoft pas si clair que ça, il n'est question que d'interfaces système et pas de l'ISA en tant que telle. Je comprends moi qu'il reste les instructions 16 bits (ce qui est logique en fait, puisque parfois on veut vraiment bosser en 16 bit !), mais surtout que le ménage n'est pas vraiment fait dans les vieilles casseroles x86 (genre le x87 resterait ? et donc la compatibilité avec les binaires, ce n'aurait été que avec les OS qu'il y aurait eu problème ? je n'ai pas lu le draft, honte à moi !).
Ouaip ... après c'est assez vague et sous documenté (enfin de façon accessible pour les non avertis ou professionnels) !
Il faudrait faire le test de la disquette avec un Windows 11 pour rigoler et avoir un aperçu de ce soi-disant nettoyage du code par MS. (prédiction de ma part : nettoyage avec les pieds)
=>
Comme expliquer maintes fois, il faut bien garder à l'esprit que la clientèle de MS est le développeur tiers et non pas l'utilisateur final.
=> Couper certaines rétrocompatibilités génère un fort mécontentement de sa base clientèle, car cela impute leurs business. (cf. l'exemple du logiciel de chiffrement collaboratif qui exploite une faille/bug kernel pour fonctionner)
Un autre rappel : la version ARM est, il parait, bien plus légère et édulcoré car elle est censée ne pas avoir besoin de ce bagage de failles/bugs utilisés par les clients. Néanmoins l'histoire de Windows sur une autre archi que le x86 (exemple : DEC Alpha et autres) expose l'incapacité de MS à produire un OS compétitif (performances et comportements médiocres) hors de l'archi x86.
Bon courage Nicolas pour vous approprier tous ces concepts !
En rapport avec votre message ( docs MS / compatibilité 16bits selon l'OS et l'archi ....), bref un beau dawa !
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