我已经看到很多关于bootstrapping的链接，我想知道使用C编程而不是使用汇编语言来引导X语言编译器的主要缺点是什么？我想知道使用C是否会限制我对汇编语言创建的'C'的限制（即C编译器如何做到这一点）。
例如，我在Python中编写的内容最终将由CPython处理，最终在硬件中以类似C的方式进行 - 这可能不是最佳的？
当然，C语言可能非常好，但对于其他一般语言，可能不是这样。引导最终是否会产生一些瓶颈，特定于我用于制作引导编译器的语言的限制？就像机器代码生成一样，C就像C生成代码而不是一些随机的方式。
使用C的主要原因是它能很好地将我们的代码映射到机器语言，但它不如装配正确吗？所以C有一些性能问题，现在我用C来创建另一种语言的编译器，所以我必须传递那些性能问题吗？毕竟C没有做到1-1映射到汇编 - 希望你得到我的问题。
答案 0 :(得分：5)
我们之前有一个非常相似的问题，要求Python interpreter in assembly language。所有这些都适用于编译器：这是一个令人难以置信的努力（非常不可能完成任何这样大小的任何事情），它会使维护成本爆炸，如果它有所帮助，它会非常少地购买 - 在< em>至少 2/3的所有情况，它将是积极有害的，因为我们都不能击败现代C编译器。
然后你的推理还有另外一个问题：虽然我们做希望我们的编译器能够快速完成，以使写 - 编译 - 调试周期的中间部分不那么烦人和浪费时间，编译器的性能不会影响已编译程序的性能 - 后者（具体而言，实际上最佳的运行时性能）通常更为重要。为此，您需要许多非常复杂的算法来进行非常聪明的优化。如前所述，大型解释器在汇编语言中已经非常难以实现。做所有这些优化更加困难。
哦，虽然我们正在努力：Bootstrapping实际上可以带来更好的性能。 PyPy项目在Python的（子集）中实现Python。你说，一定是神经过慢吗？ 错误！它可以比CPython更快地运行几乎所有程序，CPy用C语言编写（尽可能映射到程序集），并且在很多年里由非常聪明的人进行优化。通常，它只需要一小部分时间。当然，他们通过使用Just In Time编译器获胜，这种编译器本质上非常适合优化动态语言。但即使非JIT版本（常规解释器）通常也比CPython慢不到2倍。请参阅PyPy speed center。
答案 1 :(得分：0)
是。在某些情况下，将您的语言功能映射到C的类似功能会花费您的成本。两个例子：
如果你将 YourLang 函数调用实现为C函数调用---也就是说，你天真地使用C / native堆栈---你就失去了支持深度递归的能力，适当的尾递归，延续和可能的堆栈检查。 （或者至少，你必须更加努力地思考它们。）
如果将单个 YourLang 线程映射到单个POSIX / Windows /任何线程，您将无法支持像Erlang这样的大规模并发。
但这并不意味着你不能在C语言中编写解释器或编译器和运行时。