爲什麼CLR和JVM使用基於堆棧的體系結構？

Question

我一直很好奇爲什麼JVM和CLR有一個基於堆棧的架構？ 他們爲什麼不使用基於寄存器的方法？ 它對基於寄存器的方法有什麼好處？

Answer 1

通常不適合鏈接到一篇文章，但這次我會例外：這個article by Eric Lippert只是回答這個問題。

Answer 2

我曾經思考寄存器和堆棧機器之間的差異和比較指令序列，並運行基準測試...

然後我花了幾年實現這兩種類型的機器，而在鸚鵡VM，該工作是一臺註冊機器。我們天真地開始使用一個固定的寄存器組，結合數據和寄存器堆棧，但最終得出的結論是這是一個人爲的限制，所以我們改爲無限寄存器組和分配器。在某些時候，Parrot快速核心（GCC計算goto）勝過Mono和JVM解釋器核心（非JIT），但差異歸結爲JIT。鸚鵡的JIT從未匹配其他人的品質。製造最終機器的JITter的質量，通常是人們關心的。如果所有虛擬機都按照相同的規則運行（即它們有一個約束條件，以解釋模式運行而沒有JIT），那麼我的證據表明一臺註冊機器在等效堆棧機器上具有性能優勢。更大的指令，但更少的指令==更高的吞吐量（IPC）和更好的緩存局部性參考。 Dalvik JVM實際上支持我的研究結果，Dalvik幾年沒有JIT，並與其口譯核心競爭。

很少有主流虛擬機運行在解釋模式（AFAIK）中，它們是JIT編譯的，這就是我們測試的基準。解釋器核心的重點是在平臺上建立存在，進行字節碼驗證，並在沒有JIT的情況下提供故障安全執行內核。當然這不是一個規則;有數十億設備運行ARM加速JVM而沒有JIT，但是在沒有內存或CPU限制的情況下，這適用。

我曾在調整核心，測試和調整方面工作過，但最終發現我們真的想要一個快速的JIT。我得出的結論是，如果你最終將JIT，是否實施堆棧或註冊機器啓動並不重要，做你喜歡的事情;但是你會在堆疊機上更快地「上市」。虛擬機核心對字節碼解釋進行大量的僞寄存器機器虛擬優化是部分浪費，因爲它不是真正的本地優化。軟核不像真實處理器那樣進行分支預測，寄存器重命名，指令重新排序，並行執行或預取。我的感覺是，一旦我們擁有高質量的JIT到本地二進制文件，我們就會到達相同的目的地。

基於這些原因，我在技術上傾向於一個基於堆棧機：

1. 簡單 - 更少的代碼維護=更少的錯誤
2. 實施時間

但視覺和情感我喜歡註冊機：

1. 視覺概念模型更貼近mac hine和我的 大腦
2. 靈活性 - 編譯器可以使用SSA以不同順序評估它們的表達樹 。

注意我沒有說編譯器可以更「輕鬆」地生成代碼。這似乎是那些主要使用堆棧機器來爭辯的人。我不相信，也沒有發現這是真的。我在Parrot和CLR上都看到很多短時間編寫的業餘編譯器，但我承認CLR中的編譯器質量更高，但主要是可用工具的生態系統和質量之一。我自己在兩個平臺上編寫了編譯器，並發現存在折衷，但不足以讓失眠過度。

這是一個有教養的猜測，因爲我的真實世界的經驗不包括寫一個完整的JITTER，所以我沒有比較各種形式的操作碼的優點和缺點的第一手經驗，但我的觀點是，如果您打算包含JIT，那麼創建一個非常複雜的虛擬機操作碼核心就意味着過早優化。你的時間在別處度過的更好。