在 32 位核心上執行 64 位使用者態軟體需要什麼？
在 Linux 和 Windows 上，我已經習慣了需要 64 位核心才能擁有一個具有多架構/WoW 的系統的情況，我可以在其中並行執行 32 位和 64 位軟體。
然後，幾年前，當有人向我展示 MacOS 10.6 Snow Leopard 可以使用 32 位模式的核心執行 64 位應用程序時，這讓我大吃一驚。這現在可能在很大程度上被遺忘了，因為它是一次性的技術轉型。據我所知，由於硬體在移動領域處於領先地位，因此在 iOS 和 Android 向 64 位遷移過程中從來不需要這樣做。
我的問題：在 32 位 Linux 核心（i386 或 armhf）中獲得相同的功能需要什麼？
我知道這可能不是微不足道的。如果是這樣，Microsoft 可以將該功能放入 Windows XP 32 位。但一般要求是什麼？是否曾經提出過更新檔或概念驗證？
在嵌入式世界中，我認為這將特別有用，因為 64 位支持在設備驅動程序中可能會落後很長時間。
執行 64 位應用程序需要核心的一些支持：核心至少需要根據需要設置頁表、中斷表等，以支持在 CPU 上執行 64 位程式碼，並且需要保存完整的 64 位在應用程序之間切換（以及從應用程序到核心並返回）時的上下文。因此，純 32 位核心無法支持 64 位使用者空間。
然而，核心可以在核心空間執行 32 位程式碼，同時在使用者空間支持 64 位程式碼。這涉及到與使用 64 位核心執行 32 位應用程序所需的支持類似的處理：基本上，核心必須支持應用程序期望的 64 位介面。例如，它必須為 64 位程式碼呼叫核心提供某種機制，並保留參數的含義（雙向）。
那麼問題來了，是否值得。在 Mac 和其他一些系統上，可以做一個案例，因為支持 32 位核心程式碼意味著驅動程序不必同時進行切換。在 Linux 上，開發模型不同：當進行大的更改時，核心中的任何內容都會根據需要進行遷移，而核心開發人員並不真正支持核心之外的任何內容。使用 64 位核心支持 32 位使用者空間肯定是有用的並且值得付出努力（至少，在添加 x86-64 支持時），我不確定是否有必要在 32 上支持 64 位-少量…