我们假设我们有一种编程语言foo。 foo有System A的编译器，但System B没有。System B。现在，foo开发人员可以为System A编写自己的编译器，也可以编写在System B上运行的System A仿真器，并可以使用为{{{{1}编写的编译器。 1}}。模拟器的一个明显优势是它不仅限于运行编译器并向其他System B特定程序打开System A。在大多数情况下，明显的缺点是性能和复杂性取决于系统。
我感兴趣的是找出哪种方法更容易维护。例如，让php成为有问题的语言，并假设phc是该语言唯一可用的编译器。此编译器仅适用于类Unix环境。所以问题是，维护Windows的新编译器（例如phc-win）是否更容易？或者维护一个适用于Windows的类Unix环境（例如Cygwin）？
答案 0 :(得分：3)
对于System A指令集，仿真器更易于编写和维护。但是你总是要付出性能损失，所以你通过减少大量用户的工作效率，为少数人节省了工程费用。
但是，系统不仅仅是指令集。应用程序在虚拟机上运行，该虚拟机由直接使用的System A机器指令和它所调用的System A OS调用。要在系统B上运行System A应用程序，您不仅要模拟系统A指令，还要模拟系统A操作系统调用。鉴于现代操作系统的复杂性，这可能是一项非常大的工作。
Linux WINE（WINdows Emulator）正是这样做的;这在Linux下运行Windows二进制文件（以各种形式）。 WINE通过仅在x86上运行Linux系统来模拟Windows x86指令，这意味着它可以让CPU执行指令仿真工作。然后它模拟了许多Windows操作系统调用。它是一个大型计划，在不断发展（我认为十多年），并且必须不断改变以跟上微软制造的Windows的变化。它仍然有一个愿望/错误列表，它没有做好。
虽然WINE做得很好，但构建和维护它的努力相当大。你没有看到很多竞争，这表明这种努力令人生畏。
我会注意到构建编译器也不能解决操作系统仿真问题;应用程序的源代码现在可以编译为本机系统B指令，但操作系统调用它使编译器无法处理。作为编译工程师，您可以通过在应用程序所有者上推送OS仿真问题来解决代码可移植性问题。这是一个更容易解决的问题：他们只模仿他们所依赖的System A OS调用的各个方面;他们不必模仿这些电话的每个方面。