Considérés par beaucoup comme des boulets techniques, les systèmes 16 et 32 bits sont pourtant indispensables à Intel pour assurer la rétro compatibilité de ses puces. L’architecture Intel x86s n’étant que 64 bits, elle ne pourrait pas prendre en charge les anciens systèmes. Tout du moins matériellement.
L’idée pour le fondeur étant de se libérer des contraintes liées à ces vieilles architectures. La très très grande majorité des machines modernes n’utilisent plus le 16 ou le 32 bits mais fonctionnent sur des systèmes 64 bits. Pourtant ces éléments ralentissent les usages des machines au quotidien et prend de la place sur les précieux millimètres carrés des processeurs. Occuper de l’espace pour ces éléments qui ne servent souvent qu’au démarrage de la machine est donc problématique. L’idée est donc de les faire disparaitre matériellement pour les rendre… virtuels. Utiliser la puissance de l’architecture Intel x86s uniquement 64 bits pour émuler ces architectures. Ce qui permettrait de faire un peu de ménage dans les futures puces de la marque.
Sous Windows 11, le recours à un processeur 64 bits est obligatoire, si Windows 10 supportait encore les systèmes 32 bits ce ne sera plus le cas des nouvelles versions de l’OS de Microsoft. Le monde Linux serait, par contre, probablement plus impacté par cette décision, certaines distributions devant passer à la moulinette d’une virtualisation. Cela fait néanmoins un moment que le basculement vers les 64 bits existe. Sous Windows 7, de nombreuses applications et jeux ont commencé cette transition. Un mouvement rendu nécessaire par la gourmandise de nombreux outils logiciels. Les limitations en mémoire vive du 32 Bits étant drastiques. Impossible, par exemple, de prendre en charge 4 Go de RAM avec un système de ce type.
Ainsi les puces modernes seraient capables d’émuler les éléments 16 et 32 bits de manière transparente et efficace via la virtualisation tout en se libérant des boulets 16 et du 32 bits sur les architectures modernes.. Reste à savoir si cette technologie assurerait une compatibilité parfaite avec toutes les situations de terrain. J’ai par le passé eu pas mal de déboires avec ce type de transition se basant sur une émulation quelconque. Notamment les fameux ports série remplacés par des ports USB avec adaptateurs qui seraient « promis juré tout pareil » que les ports série classiques et qui ne l’on jamais été.
| 2,5€ par mois | 5€ par mois | 10€ par mois | Le montant de votre choix |
les distro grand public ont aussi abandonné le 32bits y a bien Debian qui release encore des iso sous cette architecture mais c’est voué à disparaitre aussi de ce coté
par contre va falloir que Valve se sorte les doigts parce que son client Steam est toujours 32bits :D
« Impossible par exemple de prendre en charge 4 Go de RAM avec un système de ce type. »
Ce n’est pas tout à fait exact, la plupart des processeurs 32 bits (toute arch) sortis depuis une quinzaine d’années au moins supportent un adressage type PAE qui permet de dépasser la limite globale des 4GB, qui ne reste en général vraie que côté applicatif.
Les procédés varient suivant les architectures, mais en général on ajoute des bits d’adressage de mémoire virtuels en utilisant le contenu de registres privilégiés gérés par l’OS (et/ou un hyperviseur): Typiquement le PID (Process ID) et un mode (superviseur/user).
Si on a par exemple une architecture 32 bits un peu ancienne/simple sans hyperviseur et qui permet juste un mode superviseur (codé sur 1 bit) et permet de gérer jusqu’à 2^8 processus (donc PID codé sur 8 bits, 256 processus simultanés max), on ajoute 9 bits aux 32 présents de base.
On monte sur ce cas minimal/simple à 41 bits, soit 2^41=2048GB (ou 2PB), ce qui reste large même à l’heure actuelle. Et c’est un minimum, typiquement de processeurs pour applications embarquées (automotive/telecoms…), bien des modes PAE permettant à 48 bits.
Enfin le passage au 64 bits date quand même du début des années 90. D’abord avec les processeurs RISC, puis Intel en 2000 et enfin il y a 10 ans pour ARM. Cela c’est pas fait du jour au lendemain comme pour d’autres technos. Et Linux était en 64 bits bien avant Windows. Donc à mon avis il n’y aura pas d’impact.
Vivement le 128 bits.
Et ON passe quand au 128bits ?
@Vieux chouf: En principe, les processeurs supportent déjà des instructions 128 bits via l’avx.
Le support des applications 32 bits sera toujours présent, mais elles ne pourront s’exécuter en ring0 (espace kernel). Donc concrètement, on ne pourra plus avoir d’OS en 32 bits seulement en 64 bits, mais on pourra toujours faire tourner des applications 32 bits dedans.
@Vieux chouf: Pour quoi faire ?
@millman: ça veut dire qu’il sera impossible de démarrer un vieil OS ou même FreeDOS sur un nouveau PC ?… ça va nous refaire le coup du Secure Boot qui nous avait déjà bien enquiquiné..
Zut, je vais être obligé d’upgarder mon Windows 3.11 for workgroup :)
@aka_mgr: comme le 32 bits reste possible en ring3, il est possible qu’un système 32 bits puisse booter dans une VM ou alors au travers d’un hyperviseur minimaliste qui serve juste à booter.
Dans tous les cas, oui, on ne pourra plus booter directement les vieux systèmes 16 et 32 bits.
Je me doute qu’il y aura des solutions de médiations :
– les open source feront des adaptations pour utiliser la réduction d’architecture
– les logiciels propriétaires devront utiliser des systèmes de boot intermédiaires pour s’exécuter, avec des risques de compatibilité (mais pas de performance, car un i5 de 2030 sera toujours plus performant qu’un vieux processeur).
– passer directement sur une couche d’émulation x86 ? (idem pour les perfs processeur)
Ca va dans le sens de l’histoire : à part pour booter, 99.99% des systèmes tournent maintenant en 64 bits (même si les applications peuvent rester en 32 bits, ce qui est important pour Steam !!)