更难构建：模拟器还是编译器？

Question

鉴于一位熟练的开发人员拥有10至20年的经验，从未构建过编译器或模拟器，这将更具挑战性吗？

你能否比较两个路障的问题。

感谢。

Answer 1

仿真和编译是完全不同的，但由于被认为是“低级别”，因此往往会被混为一谈。

对于工作的CPU块，对6502或Z80这样的简单架构的仿真将相当简单，但是由于需要为每条指令设置一个函数，因此需要编写相当多的代码。您需要以某种方式自动执行此操作，从具有所有时序的指令集规范等，因为输入这一切将非常繁琐:)旧的CPU指令集规格很容易找到，所以这有助于很多在构建模拟器时。

除此之外，您还需要实现某种级别的硬件仿真，这通常涉及处理和生成中断（例如，如果仿真器用于显示设备的垂直空白中断）一个游戏机，说）。这又需要一定程度的规范和代码生成，但你可能不得不手工编写大部分内容，因为它不会像指令集代码那么重复（因此可自动化）。

编译将涉及您要为其实现编译器的任何语言的某种语言规范，以及您将要为其输出代码的目标。输出可以是直接二进制，也可以是汇编，或者甚至可以是另一种语言（这实际上只是一个翻译器，但当目标被认为是“足够”低级别时，它会被视为编译）。由于您将在某种硬件或VM平台上运行，因此您不太可能担心中断处理等等。

两者的绊脚石 复杂性和正确性 - 对于模拟器，您需要使其非常准确地工作，除非您选择非常简单的事情要模仿。您还需要为模拟器创建某种集成的调试器，否则当它总是这样时几乎不可能分辨出什么是错误的。对于编译器来说，翻译玩具语言或更复杂语言的一小部分应该是相当直接的，并在你进行的过程中进行构建。

请记住，对于这两个项目，您需要能够生成输入来测试它们，如果您不能生成简单的输入，那么您将发现从一开始就很难进行调试。 仅此一点使得编译器工作变得更容易进入，imho （那就是你想要的东西可以模拟一个完整的控制台或其他东西：）

Answer 2

我已经写过并且会说其他条件相同（语言或指令集的复杂性），方式更容易编写模拟器，特别​​是如果你想写一个有趣的模拟器或编译器。

原因在于，使用模拟器，您正在尝试使用另一个类似的低级别事物来模拟低级别的事物。这不是太糟糕。使用编译器，您可能正在尝试使用非常低级别的工具（机器字和机器指令）实现非常高级的想法（例如，对象，一流函数，托管内存，字符串扫描）。这项任务要困难得多。

当然，对于有趣的团伙，您可以编写一个通过动态二进制翻译工作的模拟器，这是将模拟体系结构的机器代码编译到本机体系结构的机器代码中。通过这种方式，您可以获得两者的所有乐趣 - 并且您可以生成真正快速的模拟器，如QEMU或已故的感叹数字FX！32。

Answer 3

我写过这两篇文章并且会说模拟器通常更容易。当然，这在很大程度上取决于你试图模仿的东西（在iPhone上模拟IBM大型机可能有点挑战）以及你想要编译的东西（一个小的C编译器很简单，一个完整的C ++编译器几乎难以置信。

Answer 4

这在很大程度上取决于你在模仿什么，以及你在编写什么。

• 在非常强大的系统（例如现代PC）上模拟非常简单的系统（例如4功能计算器）的仿真器将很容易编写。
• 编译一个非常简单的单个目标语言的编译器（例如几乎直接映射到输出程序集的东西）很容易编写。
• 在非常简单的系统（例如PDA）上模拟非常复杂的系统（例如大型专有计算系统）的仿真器将很难编写
• 为许多目标编译高级语言（例如完整的C ++）的编译器将很难编写

Answer 5

在我看来，复杂的编译器比复杂的仿真器更难编写，原因很简单，编译器涉及更多的理论。

在设计语言XX时，需要考虑很多因素，更不用说优化编译器生成的代码的输出，这本身就是一种黑色艺术。使用模拟器，您可以拥有一个已经定义良好的环境，并且您希望实现一种定义良好的语言。

无论如何，我建议任何人编写和编写编译器，因为它可以使您更深入地了解编程，就像医生需要了解身体解剖结构一样，即使他在日常工作中可能不需要它。

编辑：我认为这两种技能都非常有用，实际上可以将它们结合起来 - 它们不是异或。

我想补充一点，我上面提到的是创建一个非平凡的编程语言，包括运行时库与驱动程序，数据库等交互，并且可以与未来版本一起发展，但仍然保持向后兼容是一个更具挑战性的CS的地区。

我也同意，如果平台是未知的，即你正在进行逆向工程，那么做一个模拟器要困难得多，但OTOH不是OP的问题，是吗？

Answer 6

软件的仿真非常简单，相对容易，但可能很乏味。

编写编译器可能非常困难，但是通过具有良好的工作知识或者使用编写编译器的语言的一组良好的规范（例如Backus-Naur Form表示法），可以使编写器变得更加简单。

如果您的目标是让仿真器在许多不同的平台上工作，那么硬件的仿真可能会非常困难（例如，运行仿真软盘驱动器的时序可能会在MSDOS下使用正确的软糖常量工作，但仿真失败在Vista或Linux等多任务平台上。当关于其操作模式如何由软件控制的知识不足时，硬件仿真也非常困难。这可以在取得进展之前强制进行冗长而烦人的逆向工程。

总而言之，我认为仿效更难。

Answer 7

为已知的仿真平台编写仿真器并不难（您还可以使用预先制作的CPU仿真器并获得一些开发时间）。

为未知的模拟硬件编写模拟器更难，并将难度转移到与代码开发不同的字段：数学，加密分析，安全协议等。作为开发人员，您必须耐心对此过程中涉及的反复试验。

例如，只需考虑需要多长时间CPS2仿真（CPS2 ROM加密）。

Answer 8

脱离背景，可能没有明确的答案：这一切都取决于你想要达到的目标，以及你竞争的对象。

如果它只是一个“概念证明”，那么在这两种情况下，它都相当简单。

但是，如果您试图模拟复杂的硬件或高精度，或者如果您想要实现AAA编译质量，那么事情很快就会变得难看。 复杂性不仅出现在“主要”代码的算法/理论中，还出现在您必须构建的所有支持工具（调试器，反汇编器，分析器等）中，以便您可以进入下一步。

那就是说，要考虑的另一个方面是为几乎任何编程语言编写一个有效的编译器是合理的复杂性。另一方面，如果那里的硬件很容易模拟，那么还有一些硬件，即使是基本的仿真器也可能非常复杂。

因此，使用广泛的画笔绘画，我会说编写编译器更容易，因为无论目标硬件或语言如何，您都可以保证成功获得工作版本。模拟器没有这样的保证。

Answer 9

编写编译器要困难得多，因为你处理的是更低级别的东西（链接，特定于你的架构的程序集等）。

仿真器只需要执行每条指令的逻辑（我知道我正在简化它，但我假设你有指令集的规范），现在，编写FAST仿真器要困难得多。