En lisant cet article, je me suis posé plusieurs questions.
La première :
Le passage au Full 64 bits n'empêcherait pas l'utilisation d'application 32 ou 16 bits, mais juste cela serait fait d'une façon différente, via la virtualisation par exemple, qui aujourd'hui est une technologie mature.
Cette phrase me fait tiquer : j'ai l'impression que l'auteur de l'article ne comprend pas la virtualisation (ou alors c'est moi). J'ai l'impression qu'il confond virtualisation et émulation : en effet, de mon point de vue, la virtualisation n'est qu'une façon d'ordonnancer et de gérer des ressources. Si une ressource ou un jeu d'instruction n'est pas implémenté au niveau hardware, la virtualisation ne peut rien faire. Celà dit, je sais qu'on peut émuler des périphériques réseau par exemple. Mais est-ce que c'est envisageable pour des ressources CPU ? On en arriverait à ce stade à un système hibride émulation/virtualisation. Ca existe ça ? Est-ce envisageable ? J'avoue que ça fait un bon moment que je ne suis plus le près la virtualisation, et je serais intéressé par vos avis.
Seconde question : si le support du mode 16/32 bits disparait, ça risque de poser problème pour le rétrogaming (comme le fait remarquer cet article), qui nécessitera de passer par de l'émulation. Je ne m'inquiète pas trop sur l'aspect technique (ça existe, je pense par exemple à l'émulation x86 pour ARM, : Microsoft le fait, et côté libre il y a ça en cours de développement, et peut-être d'autres projets). Celà dit j'ai pensé à une autre solution : serait-il possible de mettre en place sur un PC "standard" une technologie telle que la technologie SunPCI (pour ceux qui ne connaissent pas, il s'agit d'une carte PC contenant un CPU x86, de la RAM et un processeur graphique permettant de faire tourner un Windows sur une station SPARC), ou est-ce que ça nécessiterait de modifier l'architecture actuelle ? On pourrait envisager par exempel des cartes PCI Rétrogaming contenant un CPU compatible x86 16/32 bits … Après se pose la question du coût de développement de la techno par rapport aux bénéfices (les CPU sont suffisamment rapides aujourd'hui pour émuler d'anciennes machines), mais je suis curieux, d'un point de vue théorique de savoir si ce serait envisageable.
# Tout est possible, c'est le jeu de la vie
Posté par Renault (site web personnel) . Évalué à 10.
La virtualisation est une notion assez vague et vaste. Selon moi émuler une autre architecture matérielle peut être une forme de virtualisation, car en fait à la fin tu fais abstraction du système hôte pour le système invité pour qui tout ou presque est transparent. Le reste ce sont des détails d'implémentations si la solution retenue permet ou pas de simuler une autre architecture matérielle que celle de la machine qui exécute. Typiquement les logiciels de virtualisations peuvent reposer sur QEMU qui permet d'exécuter des systèmes prévus pour ARM sur x86 ou du x86 sur x86 (non pas de typo) par exemple.
Du coup je ne vois aucune objection à ce que la solution de contournement passe par là. De la même façon que Windows avait un mode spécial pour émuler sa compatibilité 16 bits qui a été abandonné, avec Windows 10 je crois.
Pour les vieux jeux PC il faudra peut être de l'émulation plus poussée. Pour les consoles non x86 (ce qui est le cas de quasiment toutes les vieilles consoles).
De toute façon les vieux jeux PC un peu élaborés ont souvent des problèmes ce qui peut rendre l'émulation nécessaire sans même ce changement. En effet, pas mal de jeux utilisaient des astuces possible à l'époque pour améliorer les perfs (ou parce que c'était tout simplement autorisé). J'ai croisé quelques jeux qui ne fonctionnaient pas bien sur des Windows 10 ou 11 comme AoE II d'origine (pas les nouvelles éditions qui corrigent le tir) ou les Sims 2 rendant l'émulation nécessaire.
Je pense qu'étant donnée la diffusion du x86_64 depuis le temps, le mode 16 bits est en pratique peu nécessaire. Les vieux logiciels d'entreprise seraient peut être les cas les plus chiants. Mais bon s'il y en a encore dans la nature qui tournent ainsi, il faut se poser la question de la maintenance de longue durée.
[^] # Re: Tout est possible, c'est le jeu de la vie
Posté par totof2000 . Évalué à 6.
Bof … l'un ou l'autre ont quand même des conséquences sur les perfs. La virtualisation ne fait que "passer" les instruction au cpu sans "traduction" tandis que l'émulation doit "traduire" les instructions. On peut considérer que "virtualisation" est un terme trop générique et qu'il peut englober l'émulation, mais en pratique c'est plus qu'un détail d'implémentation. C'est pour ça que je préfère être précis (sinon on va tomber dans la même confusion que "hacker/pirate par exemple). Mais sur le fond je suis d'accord avec toi, le résultat reste grosso modo le même pour l'utilisateur - sous réserve que le CPU soit capable d'émuler sans trop de ralentissements en cas d'émulation.
J'ai effectivement rencontré quelques jeux comme ça. Sans qemu en mode émulation (et non en mode virtualisation), impossible de les faire tourner.
[^] # Re: Tout est possible, c'est le jeu de la vie
Posté par Renault (site web personnel) . Évalué à 7.
Pour moi c'est un détail d'implémentation quand même dans ce cas précis.
Dans les deux cas, tu as un système invité qui tourne comme s'il tournait sur du matériel dédié. La méthode diffère un peu, ce qui a en effet un impact sur les performances, mais dans les deux cas le système invité n'y voit que du feu. C'est transparent pour lui, l'un comme l'autre sont bien interchangeables.
Après l'impact réel sera peut être pour l'utilisateur pour qui la perte en perf serait trop grande (et encore). Mais du point du vue système invité il n'a aucun moyen de voir la différence.
Note d'ailleurs dans les deux cas il y a traduction même si l'un est plus léger qu'un autre. D'ailleurs tous les processeurs x86 n'ont pas le même jeu d'instruction, même sous l'ère x86_64. Mais la virtualisation simple comme tu dis peut avoir une implémentation générique matérielle pertinente pour améliorer les performances. Par contre Intel et AMD ne vont pas investir pour mettre sur silicium des accélérateurs de traductions des instructions pour une console NES sur x86, ça ne serait pas rentable. D'ailleurs tu le vois la perte en perf quand tu utilises la virtualisation sur des processeurs dépourvus de cette fonctionnalité matérielle.
La limite est plus mince que tu ne le penses à mon avis.
[^] # Re: Tout est possible, c'est le jeu de la vie
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 24 mai 2023 à 14:10.
Bof, les instruction 16 bits ont disparût depuis si longtemps que les soft développés qu'en 16 bits sont conçu pour des processeur moins puissant que ceux des grille-pains modernes… Ca ne devrait pas poser trop de problèmes de perfs même pour un PC de plus de 10 ans d'âges. C'est moins vrai pour le 32 bits mais quand même. Honnêtement, l'émulation à aussi fait tellement de progrès que je doute que l'on ressente un quelconque lag. Je pense que cela ramait plus à l'époque de leur sortie qu'aujourd'hui en émulation.
Si on abandonne l'implémentation matériel, c'est pour gagner de l'espace/coût donc de la performance du processeur en 64 bits… Pour le parallèle : on peut garder le démarreur à manivelle sur une voiture moderne mais c'est complexifier la voiture et l'alourdir pour un usage que personne n'a besoin.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Tout est possible, c'est le jeu de la vie
Posté par Renault (site web personnel) . Évalué à 7.
Je doute que l'espace et le coût physique soient la cause derrière cette considération. Franchement ça doit concerner une portion très réduite du design des puces en transistor, donc coût direct assez faible.
L'avantage réside plutôt dans la réduction fonctionnelle, ça simplifie les tests et les logiciels au dessus et au niveau sécurité aussi car tu limites les sources de problèmes potentiels.
[^] # Re: Tout est possible, c'est le jeu de la vie
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 23 mai 2023 à 07:30.
Certainement, mais dans notre cas… on s'en cogne je pense. Les dernières applications qui vont tourner de cette manière ne seront pas les plus gourmandes en CPU, et on parle d'une prochaine génération de CPU qui apportera encore ses qques pourcentage de performance supplémentaire.
En gros, les applications 16/32 bits tourneront sur ces CPUs via emulation/virtualisation aussi bien qu'elles le font aujourd'hui en natif.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# À priori, ce n'est pas un abandon total de 32 bits
Posté par raphj . Évalué à 9. Dernière modification le 22 mai 2023 à 17:08.
J'ai vu passer cette information la semaine dernière. Cet article en parle :
https://www.tomshardware.com/news/intel-ponders-transition-to-64-bit-only-x86s-architecture
Les changements listés :
Si je comprends bien, rien ne change en espace utilisateur quand on utilise déjà un système 64 bits. Le 16 bits disparait, mais on ne pouvait déjà pas l'utiliser en 64 bits. Ce qui change dans ces conditions, c'est un boot simplifié. La prise en charge des applications 32 bits est explicitement citée compatible.
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
Oui c’est ce que j’en comprend aussi : que c’est la fin du 32-bit pour la séquence de boot, et donc la fin du 32-bit pour les systèmes d’exploitation, mais pas pour les applications qui tournent dans ces systèmes d’exploitation.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 22 mai 2023 à 23:50.
Il y a un sacré mélange dans les annonces répétées par les "gens qui savent mais en fait non", car on a l'impression que les apps 32 bits y passeraient aussi.
Je comprend l'envie de virer tout le bousin pour OS 32 bits.
Mais je ne voyais pas trop comme délirant de virer aussi tout le 32 bits, c'est bon le 64 bits on connaît de nos jours et un émulateur devrait faire tourner des apps d'il y a 10 ans sans trop de problèmes de perfs, du coup je me demande pourquoi ils n'y sont pas allé comme Apple à faire table rase? IA-64 n'a pas eu la période de transition ni les perfs attendues, mais la il y a eu la transition. Ça n'apporterai pas tant que de gain de simplification que ça? (en fait, j'imagine que pas mal de code 32-bit se mappe facilement sur du 64-bit, certes)
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Intel avait tenté de faire table rase avec sa gamme Itanium.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par groumly . Évalué à 5.
la table a été rasée, ca, c'est sur. Ils se sont juste gouré de table a raser.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par raphj . Évalué à 4. Dernière modification le 23 mai 2023 à 00:31.
Il doit y avoir encore un paquet de logiciels proprios en 32 bits plus maintenus mais encore pas mal utilisés (jeux vidéos, applications métiers…), dont probablement pas mal de trucs qui ne marchent pas si bien que ça avec un émulateur style Rosetta.
J'imagine que Microsoft est beaucoup plus attentif à la rétrocompatibilité qu'Apple, et en tout cas probablement plus connu pour ça et je les imagine bien s'arranger avec Intel pour que la compatibilité soit gardée. Je crois qu'on s'attend moins à ce que les choses perdent leur compatibilité sur Windows que sur macOS. Et puis aussi, chez Apple ils sont carrément passés de x86 à ARM, garder la compatibilité au niveau du CPU n'était probablement pas une option du tout.
Peut-être que se débarrasser de la compatibilité 32 bits ne vaut pas le coup. Sur les processeurs ARM 64 bits, il est également possible de faire tourner des binaires ARM 32 bits donc ça ne serait pas les seuls à faire ça. Mais je n'y connais pas grand chose en matière d'architecture matériel. Ce serait intéressant de savoir la quantité de choses que ça permettrait de virer.
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 23 mai 2023 à 01:44.
En tout cas je suis peu convaincu que cela changerait grand chose en consommation énergétique ou en puissance. Ces aspects là consomment probablement assez peu de transistors au regard de la mémoire cache ou du GPU ce qui sur un socket Intel prend l'essentiel de la place physique (et une bonne partie de l'énergie).
Je pense que le gain éventuel est surtout dans la maintenance. Plus besoin de se trainer des vieilleries à maintenir qu'il ne faut pas oublier de fournir et de tester que ce soit au niveau matériel comme logiciel.
Le passage complet à l'UEFI sans compatibilité avec le BIOS classique est sans doute un gros morceau aussi en ce sens.
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par barmic 🦦 . Évalué à 2.
Ça devrait aussi bien simplifier les parties logiciels. Ça va créer des cas en moins pour les installers, ce qui va améliorer les tests de support matériel. Ça va pousser à avoir une UEFI propre sans s'appuyer sur le mode legacy.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par Renault (site web personnel) . Évalué à 3.
Oui oui, je parlais bien du logiciel aussi. :)
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par antistress (site web personnel) . Évalué à 4.
Je ne sais pas si c'est pertinent dans le monde x86, mais côté RISC ça semble encore avoir du sens des proco 32 bits :
https://linuxfr.org/news/premiers-pas-avec-la-carte-visionfive-2
[^] # Re: À priori, ce n'est pas un abandon total de 32 bits
Posté par totof2000 . Évalué à 2.
j'ai l'impression que ce sont deux concepts différents : d'un côté , on a le x86 qui a un coeur (ou plusieurs) qui peuvent exécuter tout type d'instructions avec des modes d'adressages spécifiques (mode "réel avec adressage segment/offset "8bits" pour le x86), et de l'autre deux "coeurs" distincts. Je suis curieux de voir comment c'est implémenté et comment ça fonctionne.
Finalement cette annonce d'Intel est intéressante de mon point de vue : elle me permet de m'intéresser à un sujet que j'ai (trop) longtemps laissé de côté.
# Pour ceux que ça intéresse, la spécification (je ne lai pas encore lue en postant)
Posté par totof2000 . Évalué à 5.
https://cdrdv2.intel.com/v1/dl/getContent/776648
# .
Posté par Pierre Tramal (site web personnel) . Évalué à 4. Dernière modification le 22 mai 2023 à 20:31.
Un hyperviseur peut intercepter les exceptions générées par un éventuel OS qui voudrait passer le processeur en mode réel ou protégé, et éventuellement émuler logiciellement les parties "supprimées", tout en laissant les autres instructions s'exécuter "matériellement".
# Pas possible de booter des OS "legacy" en x86s
Posté par paulez (site web personnel) . Évalué à 3. Dernière modification le 23 mai 2023 à 09:03.
Je pense que tout est assez clair dans l'annonce d'Intel: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
Les apps 32 bits sont toujours supportées d'après le tableau "Supported and unsupported modes in X86S". Les apps 16 bits ne le sont pas.
Le seul moment où ça parle de virtualisation c'est pour booter les OS "legacy" 64 bits. Logique, vu que la proposition modifie comment booter un CPU, les OSs qui utilisent l'ancienne séquence ne fonctionnent plus.
Là ce qui m'étonne c'est que personne n'a l'air de comprendre la même chose que moi, mais je pense que ça signifie que tous les OS actuels en l'état ne fonctionneront plus sur x86s.
Que ça soit Windows 11 (sans mise à jour), Debian 11, Windows XP, etc. ne booteront pas sur X86s, les démarrer nécessitera de la virtualisation (uniquement dans une VM donc).
C'est quand même un sacré cassage de compatibilité, vu qu'un PC moderne est censé pouvoir booter n'importe quel OS x86 (s'il supporte le mode BIOS).
[^] # Re: Pas possible de booter des OS "legacy" en x86s
Posté par raphj . Évalué à 3. Dernière modification le 23 mai 2023 à 09:35.
Les exécutables EFI ne sont-il pas déjà en 64 bits et exécutés quand le CPU est déjà démarré dans le bon mode, et c'est le firmware de la carte mère qui s'occupe de la partie impactée ?
Si je comprends bien, l'OS peut changer le processeur de mode, mais n'est pas obligé de le faire et le processeur est déjà dans le bon mode quand l'exécutable EFI est démarré. Par contre je suppose qu'on perd le boot MBR, mais les systèmes modernes sont déjà en EFI 64-bit en général.
Mais sinon ça ne m'inquièterait pas trop. Les OS maintenus auraient le temps d'adapter leur boot pour prendre en charge cette nouvelle architecture. J'imagine que le travail nécessaire pour y arriver est plutôt léger. Des shims apparaitront peut-être pour les autres, à base de virtualisation probablement en effet. Ça parait tricky sans, si l'OS se met à essayer de changer le mode du processeur alors que ça n'est pas pris en charge ça risque de mal se passer, mais encore une fois je n'y connais pas grand chose.
La virtualisation, ce n'est pas nécessairement très coûteux et c'est plutôt rare de devoir booter un ancien OS plus qu'occasionnellement pour une situation spécifique.
[^] # Re: Pas possible de booter des OS "legacy" en x86s
Posté par paulez (site web personnel) . Évalué à 1.
En effet il semble que ça soit l'UEFI qui s'occupe de faire les transitions mode réel, protégé et long (64 bits).
Donc ça n'impacterait que les OS qui peuvent démarrer seulement en mode BIOS (pour Windows antérieur à Windows Vista SP1).
[^] # Re: Pas possible de booter des OS "legacy" en x86s
Posté par barmic 🦦 . Évalué à 2.
Ton lien indique :
Donc effectivement Windows XP sorti 11 ans avant UEFI et dont le support par Microsoft n'existe pour ainsi dire plus (il n'y a plus de mise à jour de la version bureau depuis 4 ans et c'est plus que les versions embedded qui sont supportées donc probablement pas sur les nouveaux CPU intel). Mais pour le reste ils savent démarrer sur UEFI donc les versions 64bits n'auront pas de problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# L'avis de Linus
Posté par patrick_g (site web personnel) . Évalué à 10.
https://www.realworldtech.com/forum/?threadid=211814&curpostid=211884
# SunPCI
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Sur la question d'une carte de type SunPCI: je ne vois pas vraiment de problème supplémentaires sur les machines actuelles par rapport à celles de Sun. Mais le résultat sera tout aussi boiteux qu'à l'époque.
La carte n'est pas 100% compatible avec un PC normal, il y a besoin de plein de patchs dans Windows ou DOS pour la faire fonctionner, et le système pour intégrer l'image du système PC sur la station SPARC fonctionne mal, il vaut mieux passer par le port VGA dédié de la carte SunPCI avec un deuxième écran ou un boîtier commutateur pour switcher entre les deux.
Donc, oui, c'est faisable, mais l'intégration avec le système hôte pose pas mal problème. Peut être que ça marcherait mieux pour un OS moderne (pas Windows 3.11), où les applications font moins d'accès direct au matériel et on a peut-être une chance de tout intercepter au niveau des drivers.
Mais est-ce que ça vaut vraiment la peine de faire tout ça?
[^] # Re: SunPCI
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Moi ça m'intéresserait d'avoir ce genre de carte pour faire tourner des logiciels privateurs (par exemple des jeux) sans devoir recourir à une couche d'émulation / conteneurisation / virtualisation :-)
Après c'est comme l'andouillette, il faut que ce soit bien fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.