Les architectures Intel 64 démarrent dans un état associé au mode réel de l’Intel 8086, selon Intel. Cela ne signifie pas que le processeur émule intégralement le 8086 : c’est un héritage de l’architecture de démarrage, que le firmware quitte rapidement. Intel décrit cet état de reset dans sa présentation de X86S, et Adam Conway rapporte que la documentation AMD décrit elle aussi une entrée initiale en mode réel après le reset.
La distinction compte encore pour le démarrage des cœurs secondaires : le mécanisme traditionnel INIT/SIPI les fait passer par du code en mode réel, même sur une machine UEFI.
Ce que signifie le mode réel au démarrage
En mode réel, le calcul conventionnel d’une adresse combine un segment et un décalage : segment × 16 + décalage. Avec des valeurs sur 16 bits, ce modèle décrit une adresse sur 20 bits et un espace nominal de 1 Mio. Il ne décrit pas pour autant l’adresse de première lecture des processeurs x86 modernes.
Dans un article publié le 13 octobre 2026, Adam Conway, de XDA Developers, rapporte que les processeurs Intel et AMD démarrent à l’adresse FFFFFFF0h, avec un état particulier du segment de code. Cette adresse se situe près de la limite des 4 Gio et ne découle pas du modèle conventionnel du 8086. Son enquête sur le démarrage x86 distingue ainsi l’état de reset hérité des règles simples souvent associées au mode réel.
UEFI ne change pas ce contrat de démarrage du processeur. Il remplace l’organisation du firmware et du démarrage, mais le firmware doit toujours faire avancer le processeur depuis son état de reset. Sur une machine UEFI, le chargeur du système d’exploitation n’a pas nécessairement besoin de s’exécuter en mode réel.
Le mode réel n’est pas une émulation complète du 8086
Le mode réel est un raccourci utile pour décrire la compatibilité au démarrage, pas une émulation intégrale du processeur de 1978. Les registres de segment ont un sélecteur visible, mais aussi un état interne caché : leurs bases, limites et attributs ne se résument pas à la valeur affichée dans le registre. OS/2 Museum explique que le chargement d’un segment modifie certaines de ces informations sans nécessairement effacer les attributs hérités d’un descripteur antérieur. Son analyse du mode réel montre pourquoi les transitions entre modes sont plus subtiles qu’un simple changement de bit.
Cette mécanique compte lorsqu’un système tente de revenir du mode protégé au mode réel. Dans une discussion consacrée à un système expérimental sous QEMU, le participant nullplan explique qu’un saut lointain ne suffit pas à rétablir les attributs attendus : le code doit charger des descripteurs 16 bits appropriés alors qu’il se trouve encore en mode protégé. La réponse sur OSDev.org porte sur ce cas précis.
Pourquoi les cœurs secondaires utilisent encore du code 16 bits
Avec le mécanisme traditionnel, le processeur envoie d’abord une commande INIT, puis un SIPI — une interruption de démarrage — au cœur secondaire. Le vecteur SIPI indique une adresse de démarrage située sous 1 Mio, où le cœur commence en mode réel. Pour supprimer cette étape, il faudrait donc remplacer le mécanisme de démarrage des autres cœurs, pas seulement modifier le premier saut effectué par le processeur.
Les observations d’Adam Conway illustrent la différence entre le bref passage du firmware et le code conservé par les systèmes d’exploitation. Dans son test QEMU/OVMF du chemin de démarrage ordinaire, il a relevé 18 adresses d’instructions distinctes en mode réel avant le passage au mode protégé. La branche TDX testée suivait un parcours particulier et commençait déjà en mode protégé.
Dans un test QEMU distinct avec Linux 6.18, Adam Conway a compté 67 instructions 16 bits dans le trampoline de démarrage du second cœur. Il a également identifié, dans Windows 11 build 10.0.28000.3086, les routines HalpRMStub, HalpPMStub et HalpLMStub. Ces observations concernent les parcours et versions examinés, pas une séquence universelle pour tous les firmwares ou systèmes.
Ce que X86S aurait changé
En 2023, Intel a proposé X86S, une architecture x86 limitée aux modes 64 bits. Le projet prévoyait un reset directement en mode paginé 64 bits et un nouveau mécanisme pour démarrer les cœurs secondaires, à la place du modèle INIT/SIPI traditionnel. Intel expliquait que ce dernier aurait nécessité un remplacement 64 bits dans une architecture débarrassée des modes hérités.
| Conception | Mode au reset | Démarrage des autres cœurs |
| x86 documenté | État associé au mode réel du 8086 | Mécanisme traditionnel INIT/SIPI, avec un trampoline en mode réel |
| X86S proposé | Démarrage direct en mode paginé 64 bits | Nouveau mécanisme 64 bits destiné à remplacer SIPI |
La proposition aurait donc modifié plusieurs étapes du démarrage, dont celle des cœurs secondaires. En décembre 2024, XDA Developers a rapporté qu’Intel avait choisi de ne pas poursuivre X86S ; Intel confirme sur sa page officielle que le projet n’a pas été poursuivi. La même page rappelle l’engagement de longue date de l’entreprise envers la compatibilité logicielle.
