Que faut-il pour exécuter un logiciel utilisateur 64 bits sur un noyau 32 bits?

Sous Linux et Windows, je suis habitué à la situation où j'ai besoin d'un noyau 64 bits pour avoir un système avec multiarch / WoW où je peux exécuter les logiciels 32 bits et 64 bits côte à côte.

Et puis, il y a des années, cela m'a époustouflé quand quelqu'un m'a montré que MacOS 10.6 Snow Leopard pouvait exécuter des applications 64 bits avec le noyau en mode 32 bits. Cela peut être largement oublié maintenant, car il s'agissait d'une transition technologique unique. Avec le matériel en avance sur la courbe dans l'espace mobile, pour autant que je sache, cela n'a jamais été nécessaire dans le passage au 64 bits pour iOS et Android.

Ma question: que faudrait-il pour obtenir la même capacité dans un noyau Linux 32 bits (i386 ou armhf)?

Je comprends que ce n'est probablement pas anodin. Si tel était le cas, Microsoft aurait pu intégrer la fonctionnalité dans Windows XP 32 bits. Quelles sont cependant les exigences générales? Y a-t-il déjà eu un correctif ou une preuve de concept proposé?

Dans le monde intégré, je pense que cela serait particulièrement utile, car la prise en charge 64 bits peut être longtemps à la traîne dans les pilotes de périphérique.

L'exécution d'applications 64 bits nécessite une certaine prise en charge par le noyau: le noyau doit au moins configurer des tables de pages, des tables d'interruption, etc. selon les besoins pour prendre en charge l'exécution de code 64 bits sur le CPU, et il doit enregistrer l'intégralité du 64 bits contexte lors du basculement entre les applications (et des applications vers le noyau et inversement). Ainsi, un noyau purement 32 bits ne peut pas prendre en charge l'espace utilisateur 64 bits.

Cependant, un noyau peut exécuter du code 32 bits dans l'espace noyau, tout en prenant en charge le code 64 bits dans l'espace utilisateur. Cela implique une gestion similaire à la prise en charge requise pour exécuter des applications 32 bits avec un noyau 64 bits: fondamentalement, le noyau doit prendre en charge les interfaces 64 bits attendues par les applications. Par exemple, il doit fournir un mécanisme permettant au code 64 bits d'appeler dans le noyau et conserver la signification des paramètres (dans les deux sens).

La question est alors de savoir si cela en vaut la peine. Sur le Mac et certains autres systèmes, un cas peut être fait car la prise en charge du code du noyau 32 bits signifie que les pilotes n'ont pas tous à faire le changement simultanément. Sous Linux, le modèle de développement est différent: tout ce qui se trouve dans le noyau est migré si nécessaire lorsque des modifications importantes sont apportées, et tout ce qui se trouve en dehors du noyau n'est pas vraiment pris en charge par les développeurs du noyau. La prise en charge de l'espace utilisateur 32 bits avec un noyau 64 bits est certainement utile et en vaut la peine (du moins, c'était lorsque le support x86-64 a été ajouté), je ne suis pas sûr qu'il y ait un argument en faveur de 64 bits sur 32 -bit...

Snow leopard a pu exécuter des binaires 64 bits dans un processeur Intel 64 bits.

Il était également capable de démarrer avec un noyau 64 bits lorsque votre efi était déjà en 64 bits (mon lot de production du Macbook "transition-model" pro était déjà une telle machine).

Aucune émulation n'était impliquée, vous venez de payer un coût de performance plus faible lors du démarrage en mode 32 bits.

Dans les processeurs 32 bits purs, vous ne pourrez pas le faire, car ils ne savent pas comment interpréter le code 64 bits. À moins que vous n'émuliez avec un logiciel, ce serait trop lent pour ce type de machines embarquées traditionnellement sous-alimentées.