Was braucht es, um 64-Bit-Userland-Software auf einem 32-Bit-Kernel auszuführen?

Unter Linux und Windows bin ich an die Situation gewöhnt, dass ich einen 64-Bit-Kernel benötige, um ein System mit Multiarch / WoW zu haben, auf dem ich 32-Bit- und 64-Bit-Software nebeneinander ausführen kann.

Und dann, vor Jahren, hat es mich umgehauen, als mir jemand zeigte, dass MacOS 10.6 Snow Leopard 64-Bit-Anwendungen mit dem Kernel im 32-Bit-Modus ausführen kann. Dies kann jetzt weitgehend vergessen werden, da es sich um einen einmaligen Technologiewandel handelte. Mit der Hardware im mobilen Bereich war dies meines Wissens bei der Umstellung auf 64-Bit für iOS und Android nie erforderlich.

Meine Frage: Was würde es brauchen, um die gleiche Fähigkeit in einem 32-Bit-Linux-Kernel (i386 oder armhf) zu erhalten?

Ich verstehe, dass dies wahrscheinlich nicht trivial ist. Wenn dies der Fall wäre, hätte Microsoft die Funktion in Windows XP 32-Bit integrieren können. Was sind die allgemeinen Anforderungen? Wurde jemals ein Patch oder Proof-of-Concept vorgeschlagen?

In der eingebetteten Welt wäre dies meiner Meinung nach besonders hilfreich, da die 64-Bit-Unterstützung bei Gerätetreibern lange zurückbleiben kann.

Das Ausführen von 64-Bit-Anwendungen erfordert eine gewisse Unterstützung durch den Kernel: Der Kernel muss nach Bedarf mindestens Seitentabellen, Interrupt-Tabellen usw. einrichten, um das Ausführen von 64-Bit-Code auf der CPU zu unterstützen, und er muss das vollständige 64-Bit-Code speichern Kontext beim Wechseln zwischen Anwendungen (und von Anwendungen zum Kernel und zurück). Daher kann ein reiner 32-Bit-Kernel keinen 64-Bit-Benutzerbereich unterstützen.

Ein Kernel kann jedoch 32-Bit-Code im Kernelbereich ausführen, während 64-Bit-Code im Benutzerbereich unterstützt wird. Dies beinhaltet eine ähnliche Behandlung wie die Unterstützung, die zum Ausführen von 32-Bit-Anwendungen mit einem 64-Bit-Kernel erforderlich ist: Grundsätzlich muss der Kernel die von den Anwendungen erwarteten 64-Bit-Schnittstellen unterstützen. Beispielsweise muss ein Mechanismus bereitgestellt werden, mit dem 64-Bit-Code in den Kernel aufgerufen werden kann, und die Bedeutung der Parameter (in beide Richtungen) beibehalten werden.

Die Frage ist dann, ob es sich lohnt. Auf dem Mac und einigen anderen Systemen kann ein Fall gemacht werden, da die Unterstützung von 32-Bit-Kernel-Code bedeutet, dass nicht alle Treiber gleichzeitig wechseln müssen. Unter Linux ist das Entwicklungsmodell anders: Alles im Kernel wird nach Bedarf migriert, wenn große Änderungen vorgenommen werden, und alles außerhalb des Kernels wird von den Kernel-Entwicklern nicht wirklich unterstützt. Die Unterstützung von 32-Bit-Userland mit einem 64-Bit-Kernel ist sicherlich nützlich und die Mühe wert (zumindest als die x86-64-Unterstützung hinzugefügt wurde). Ich bin mir nicht sicher, ob es einen Fall für 64-Bit auf 32 gibt -bisschen...

Snow Leopard konnte 64-Bit-Binärdateien in einer Intel 64-Bit-CPU ausführen.

Es war auch in der Lage, mit einem 64-Bit-Kernel zu booten, wenn Ihr Efi bereits 64 Bit war (mein Produktionsstapel des Macbook "Transition-Model" Pro war bereits eine solche Maschine).

Es war keine Emulation beteiligt, Sie haben nur geringere Leistungskosten bezahlt, wenn Sie im 32-Bit-Modus gestartet haben.

In reinen 32-Bit-CPUs ist dies nicht möglich, da sie keine Ahnung haben, wie 64-Bit-Code zu interpretieren ist. Es sei denn, Sie emulieren mit Software, was für diese traditionell unterversorgte eingebettete Maschinenklasse zu langsam wäre.