Un système d'exploitation 32 bits peut-il fonctionner avec un processeur 64 bits ?

Votre question est spécifique à l'architecture. x64 est essentiellement une extension de l'architecture x86. Il prend en charge un espace d'adressage de 64 bits. Il fournit de nouvelles instructions et de nouveaux registres.

Vous pouvez exécuter des Windows x86 32 bits sur une machine x64. Notez que vous ne pouvez pas le faire sur les systèmes Itanium 64 bits.

La réponse actuellement acceptée est généralement correcte, mais pas spécifiquement. Il n'existe pas vraiment de “CPU 32 bits” ou de “CPU 64 bits” - c'est une description qui ne se réfère qu'à une petite partie de l'architecture du CPU. Elle fait notamment référence au nombre de lignes de sélection d'adresses entre le CPU et la mémoire, c'est-à-dire à ce qu'on appelle l’“espace d'adressage” disponible pour les opérations en mémoire.

À l'époque où le CPU était utilisé pour tisser (enrouler) les fils entre un processeur et la mémoire, il fallait utiliser soit 32 soit (théoriquement, car il n'existait pas à l'époque) 64 fils entre le CPU et le contrôleur de mémoire qui seraient utilisés pour spécifier l'adresse mémoire à laquelle vous vouliez accéder. Par exemple, disons que nous avons une architecture mémoire de 2 bits : l'envoi de 00 sélectionnerait l'adresse 0, 01 sélectionnerait l'adresse 1, 10 sélectionnerait l'adresse 2, et 11 sélectionnerait l'adresse 3. Ce 2 bits nous donne 2^2 octets de RAM (4 octets).

Si vous prenez un CPU 32 bits et que vous ajoutez 32 fils supplémentaires entre le CPU et le contrôleur de mémoire afin de pouvoir, comme par magie, supporter plus de mémoire, vous avez maintenant un “CPU 64 bits” qui peut exécuter du code 32 bits ou du code 64 bits. Qu'est-ce que cela signifie et comment cela se produit-il ? Eh bien, prenons notre CPU 2 bits de la partie précédente de cette réponse et ajoutons un autre fil, le transformant en CPU 3 bits, ce qui nous fait passer de 4 octets à 2^3 ou 8 octets de RAM.

Le code “2 octets” existant sera exécuté, en fixant les valeurs des 2 derniers fils comme indiqué ci-dessus (00-11). Par défaut, la connexion supplémentaire sera à zéro, donc en fait, lorsque le code à 2 octets est exécuté, lorsqu'il sélectionne 00, il sélectionne 000 et lorsqu'il sélectionne 11, il sélectionne 011. C'est facile.

Maintenant, un programmeur veut écrire un code “natif” de 3 octets et écrit son logiciel pour profiter de l'espace d'adresse supplémentaire. Elle dit à l'unité centrale qu'elle sait ce qu'elle fait et qu'elle prendra le contrôle manuel des nouveaux fils supplémentaires. Son logiciel connaît le ou les fils supplémentaires et envoie correctement 000-111, ce qui lui donne un accès complet à la gamme de mémoire prise en charge par cette nouvelle architecture de processeur.

Mais ce n'est pas comme ça que ça doit se passer. En fait, ce n'est normalement pas comme ça que les choses se passent. Lorsque les CPU 64 bits ont été introduits (et ils étaient nombreux), ils ont tous été dotés d'une architecture/design entièrement nouveau. Ils ne se sont pas contentés d'ajouter 32 fils et de dire “voilà, c'est un CPU 64 bits que vous pouvez utiliser en mode 32 ou 64 bits”, mais ils ont plutôt dit “C'est notre nouveau CPU et il ne prend que de la programmation dans ce tout nouveau langage machine, se comporte de cette manière entièrement nouvelle, résout un bazillion de problèmes différents de manière bien plus élégante que les anciens CPU 32 bits x86/i386 ne l'ont jamais fait, et c'est une architecture 64 bits native. Amusez-vous bien”.

C'était l'histoire de l'Intel Itanium, maintenant connu sous le nom de “Itanic” à cause de son énorme chute. Il était censé annoncer la nouvelle ère du 64 bits, et c'était quelque chose à voir. Instructions de longueur variable, énormes caches, espace d'adressage 64 bits, tonnes de registres, super excitant, super cool et super difficile à convaincre de recompiler ou de réécrire 20 ans de code hérités. C'était à l'époque où AMD et Intel étaient réellement en concurrence, et AMD a eu la brillante idée de dire “oublions tout ce business de ‘résoudre tous les problèmes du monde’ et ajoutons juste 32 fils supplémentaires au i386 et faisons un CPU 32 bits compatible 64 bits” et l'architecture CPU x86_64 était née.

En fait, si vous regardez les noms de noyaux et les sources des principaux systèmes d'exploitation (Linux, Windows, BSD, etc.), vous les trouverez jonchés de références aux processeurs AMD64 et à l'architecture AMD64. AMD a mis au point une stratégie gagnante pour que tout le monde passe au monde 64 bits tout en préservant la compatibilité avec les applications 32 bits, de telle sorte qu'un système d'exploitation 32 bits puisse fonctionner sur du matériel 64 bits ou même que des applications 32 bits puissent fonctionner sur un système d'exploitation 64 bits sur du matériel 64 bits. Intel a suivi la suite plus tôt que tard avec son architecture “Intel EM64T” (qui était fondamentalement identique à AMD64) et x86_64 l'a emporté tandis que l'Itanic et d'autres comme MIPS64 et ALPHA64 n'étaient plus présents sur le marché des ordinateurs de bureau/serveurs.

tl;dr amd64 alias x86_64 Les processeurs sont conçus pour être compatibles avec les noyaux et le code 32 et 64 bits, mais la plupart des processeurs 64 bits ne sont décidément pas rétrocompatibles de la même manière. Un processeur 32 bits peut accéder à 4 Go de mémoire au maximum, tandis qu'un processeur 64 bits peut accéder à 16 EiBs (16 × 1024^6 octets, soit 4 milliards de fois plus de mémoire que 4 Go).

Un OS 32 et 64 bits peuvent tous deux fonctionner sur un processeur 64 bits, mais l'OS 64 bits peut utiliser la pleine puissance du processeur 64 bits (registres plus grands, plus d'instructions) - en bref, il peut faire plus de travail en même temps. Un processeur 32 bits ne supporte que le système d'exploitation Windows 32 bits.