編程語言的進化與底層架構

Question

假設我們有一種編程語言foo。 foo有一個編譯器System A，但不是System B。現在，System B開發人員可以編寫foo的編譯器或編寫System B的System A仿真器，並可以使用編寫爲System A的編譯器。該仿真器的一個明顯的優點是，它不限於運行編譯器並打開System B到其他System A特定程序。在大多數情況下，明顯的缺點是性能和複雜性取決於系統。

我感興趣的是找出哪種方法更容易維護。例如，假設php是有問題的語言，並假設phc是該語言唯一可用的編譯器。該編譯器僅適用於類Unix環境。所以問題是，爲Windows維護一個新的編譯器比較容易嗎（例如phc-win）？或維護一個適用於Windows的類Unix環境（例如Cygwin）？

Answer 1

對於System A指令集，仿真器更易於編寫和維護。但是你總是付出一定的性能損失，所以你通過讓更多的用戶降低生產力，爲少數人節省了工程成本。

但是，系統不僅僅是指令集。該應用程序在由它直接使用的System A機器指令組成的虛擬機上運行，​​並由System A OS調用它。要在系統B上運行系統A應用程序，您不僅可以模擬系統A指令，還可以模擬系統A操作系統調用。鑑於現代操作系統的複雜性，這可能是一項非常大的工作。

Linux WINE（WINdows模擬器）正是如此;這將在Linux下運行Windows二進制文件（以各種形式）。憑藉在x86系統上運行的Linux系統，WINE模擬Windows x86指令，這意味着它可以讓CPU執行指令模擬工作。然後它模擬了很多Windows操作系統調用。它是一個持續發展的大計劃（十多年來我認爲），並且必須不斷進行更改，才能跟上微軟所做Windows的變化。它仍然有一個願望/錯誤清單，它不擅長的事情。

儘管WINE功能不錯，但構建和維護它的工作量相當大。你沒有看到很多競爭，這表明這種努力是艱鉅的。

我會注意到，構建編譯器也不能解決操作系統仿真問題;應用程序的源代碼現在可以編譯爲本地系統B指令，但是操作系統調用它會導致....編譯器無法處理。作爲編譯器工程師，您通過推動應用程序所有者的操作系統仿真問題來解決代碼可移植性問題。這是一個更容易的問題：他們只模擬他們所依賴的System A調用的方面;他們不必效仿這些調用的每個方面。