可以為CPU增加一套寄存器堆來提高微內核操作系統的性能嗎？
上個學期學校OS的課程設計實現了一個簡陋的微內核操作系統，有點感觸。
微內核操作系統大部分服務都是用戶態進程提供的，但是這些服務的很多操作又需要內核態來實際實施，所以可能一次用戶態的服務就可能涉及了很多次的syscall（系統調用），但是每次陷入內核態都需要完整地保存寄存器堆上下文，返回用戶態的時候又需要恢復上下文，這些開銷不小。
能不能給CPU多一套寄存器，一套用戶態使用，一套內核態使用，再加一些內核態指令來修改用戶態寄存器堆，這樣在系統調用的時候就不用保存恢復上下文了（用戶進程之間切換的時候還是需要保存）。按照我淺薄的計算機組成知識貌似也不是很難實現。提高了上下文切換效率ipc效率似乎也能有所提高。
這樣的想法可行嗎？有什麼難點嗎？會帶來什麼後果嗎？現在/曾經有類似的嘗試嗎？還是說微內核的瓶頸在別處？
我記得 ARMv4 有 FIQ，可以一定程度獨立使用寄存器。RTOS 可能比較有用，非 RTOS 從內核態切換回去的時候可大概率已經不是切進來的那個線程了。
寄存器切換的開銷其實沒那麼誇張，golang 這種 stackful coroutine 還能在不進內核態的情況下切寄存器呢。上下文切換還有很多與線程綁定的別的開銷，比如更新內存頁之類的，我覺得相比寄存器的開銷而言更難削減。
同一時刻只有一半寄存器能被用上，這就很蠢。
內核態、用戶態的切換其實更多是軟體問題，軟體層面可以減少系統調用，盡量把工作留在用戶態，又何必麻煩硬體、ISA去做breaking change呢。
如果真要加，我覺得要麼是不劃分內核、用戶態，直接增加通用寄存器數量；要麼就是根據現有的ring去區分訪問的寄存器，只留下一些專用的寄存器被設計成共享。
前者顯然更實用，更多的寄存器能減少訪存，但指令裏就要花更長內容去描述操作數。對於定長指令集，4位元組-&>5位元組的轉變就很奇怪（不對齊），直接擴展到8位元組又很蠢，所以這項決定會很艱難。
（當然也可以通過三操作數、四操作數指令限制可訪問的寄存器範圍來緩解，intel的核顯就是這麼乾的）
後者就是前面說到的問題，你不能拋棄另一個狀態下的寄存器裏的內容，就會浪費一部分資源。
當然對於亂序執行+寄存器重命名的CPU，底下的微架構顯然是擁有著更多物理寄存器的，所以問題可能沒那麼大。
現在流行的架構或多或少都有些歷史包袱，改成這樣還是有點阻礙的。
更何況得做模擬才能知道到底有多少提升——syscall真的是現在的瓶頸嘛？保存現場時，內容寫到cache還是挺快的啊。
armv7分了好幾種模式，然後寄存器也是幾組，armv8裏沒這樣搞了。
sparc有寄存器窗口。
不過從實際來說也有不少問題。比如你要在內核態訪問用戶態寄存器，那麼寄存器定址就複雜了，比如對於一條add指令，通常的模式是
add 源寄存器1 源寄存器2 目的寄存器
但是現在多了內核態寄存器，就會多很多模式，例如
add 源寄存器1(內核) 源寄存器2(內核) 目的寄存器(用戶)
add 源寄存器1(用戶) 源寄存器2(內核) 目的寄存器(用戶)
排列組合下，你會發現有很多模式。給add指令來一大堆不同版本麼？肯定不行。
然後有人會想，我在寄存器編號上多加一位來區分內核態和用戶態寄存器，這樣意義不大。一是本身這個其實等價於通用寄存器數量翻倍，還不如不區分內核態和用戶態。另外考慮到指令編碼，這樣會多用三個位來表示寄存器(兩個源，一個目的)，會減少編碼空間。例如現在常見的32bit指令編碼，32個寄存器時，兩個源加目的寄存器，佔去15位，如果多加一位區分寄存器，就18位了，留給指令編碼用的位數就比較少了。
其實當時我搞rtos的時候，也有這樣的想法，但是，細想一下，保存現場這個工作是很難避免的。
因為除了用戶態會進行系統調用進入內核外，其他一些外部設備也有可能觸發中斷進入內核態。所以，一個中斷，可能打斷另一個正在運行的中斷（用戶態調用也是中斷）。這時候硬體上只有兩者選擇:
要麼，不支持中斷嵌套，這時候就不需要保存內核態寄存器狀態，但是會導致，大量的中斷延遲，甚至是丟失。
要麼，就支持中斷嵌套，那麼這時候，就需要在中段開始和結束的地方增加上下的文保存和恢復工作，支持嵌套的好處就是中斷響應實時性高。
對於大部分CPU來說，選擇第2種，顯然是一種更通用的策略。
還有用戶線程之間的切換，也是必須要保存上下文的。
如果按題主的思路，硬體就需要維護，不確定套數的寄存器才能避免所有的上下文保存，顯然是不現實的。
但如果僅僅是節省應用戶態進入內核態時上下文切換，又沒有多大意義，因為進入內核態之後，寄存器上下文的切換，時時刻刻都在發生。
以上是個人的一些淺薄理解，如果有大神請指正。
可以，但是需要你進行從兼容性，以及如何在已有的寄存器的基礎之上繼續提升性能的思路需要時間來進行思考，如果說兼容性沒問題的話，那麼就可以從性能提升方面研究了！
推薦閱讀：
