自举的缺点？
我看过很多关于引导的链接，我想知道使用 C 编程而不是使用汇编语言引导 X 语言的编译器的主要缺点是什么？我想知道使用 C 是否会限制我对“C”（如汇编语言创建）所做的任何事情（即 C 的编译器如何执行它）。
例如，我用 Python 编写的任何内容最终都会由 CPython 处理，最终在硬件中以类似 C 的方式进行处理——这可能不是最佳的？
当然，C 可能是非常好的语言，但对于其他一些通用语言可能并非如此。引导最终是否会遇到一些瓶颈，以及我用于制作引导编译器的特定语言的限制？就像机器代码生成就像 C 生成代码的方式一样，而不是某种随机方式。
使用 C 的主要原因是它可以很好地将我们的代码映射到机器语言，但它不如汇编好，对吗？所以C有一些性能问题，现在我使用C为另一种语言创建编译器，所以我必须传递这些性能问题，对吧？毕竟 C 不会对汇编进行 1-1 映射 - 希望您能明白我的问题。
I have seen many links on bootstrapping, I was wondering what are the main drawbacks of bootstrapping a compiler for a language say X using C programming instead of using assembly language? I was wondering if using C would restrict whatever I do to a 'C' like assembly language creation (i.e how C's compiler does it).
For example whatever I write in Python will eventually be taken care by CPython, making it eventually in a C like manner in the hardware - which might not be optimum?
Of course C is probably very good language, but for some other general language it might not be so. Wouldn't bootstrapping eventually have some bottlenecks, restrictions specific to the language I use for making a bootstrapping compiler? Like machine code generation would be like how C generates the code and not some random manner.
Main reason for using C is that it does a good job of mapping our code to machine language but it not be as good as assembly right? So C has some performance problems, now I use C to create a compiler for another language, so I have to pass on those performance issues right? After all C doesn't do a 1-1 mapping to assembly - hope you get my question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们之前遇到过一个非常类似的问题，要求使用汇编语言的Python解释器。所有这些也适用于编译器：这是一项令人难以置信的努力（以至于几乎不可能完成如此规模的任何事情），它使维护成本爆炸，如果它有帮助的话，它给你带来的好处非常少 - 在 < em>至少在所有情况下 2/3，它将是非常有害的，因为我们没有人能够击败现代 C 编译器。
然后，您的推理还有另一个问题：虽然我们确实希望我们的编译器能够快速完成，以使写入-编译-调试周期的中间部分不那么烦人和浪费时间，编译器的性能不会影响已编译程序的性能 - 而后者（具体来说，实际上可能的最佳运行时性能）通常更重要。为此，您需要大量非常复杂的算法来进行非常聪明的优化。如前所述，在汇编语言中，大型解释器已经非常非常困难甚至不可能。进行所有这些优化更加困难。
哦，当我们这样做时：引导实际上可以带来更好性能。 PyPy 项目在 Python（的子集）中实现 Python。你说一定是慢得要命吗？ 错！它几乎可以比 CPython 更快地运行所有程序，CPython 是用 C 编写的（它尽可能地映射到汇编），并且经过许多年的聪明人的优化。通常，它只需要所需时间的一小部分。诚然，他们通过使用即时编译器获胜，该编译器本质上非常适合优化动态语言。但即使是非 JIT 版本（常规解释器）也通常比 CPython 慢不到 2 倍。请参阅PyPy 速度中心。
We've had a very similar question before, asking for a Python interpreter in assembly language. All of these apply to compilers as well: It's an incredible effort (so much that it's pretty much impossible to get anything of this size done), it makes maintaince cost explode, it buys you very very little if it helps at all - in at least 2/3 of all cases, it will be actively harmful because none of us can beat a modern C compiler.
And then there's another problem with your reasoning: While we do want our compilers to be done fast to make the middle part of the write-compile-debug cycle less annoying and time-wasting, the performance of the compiler doesn't affect the performance of the compiled program - and the latter (specifically, the best runtime performance practically possible) is usually more important. And for that, you need lots of very complex algorithms doing very clever optimizations. As said before, a large interpreter is already very very hard to impossible in assembly language. Doing all these optimizations is even harder.
Oh, and while we're at it: Bootstrapping can actually lead to better performance. The PyPy project implements Python in (a subset of) Python. Must be godawful slow, you say? Wrong! It can run nearly all programs faster than CPython, which is written in C (which maps about as well to assembly as possible) and was optimized by very clever people over the course of many many years. Often, it needs only a fraction of the time needed. Granted, they win by using a Just In Time compiler, which is by its nature well-suited to optimizing the heck out of dynamic languages. But even the non-JIT version, a regular interpreter, is often less than 2 times slower than CPython. See the PyPy speed center.
是的。在某些情况下，将您的语言的某个功能映射到 C 的类似功能会导致您付出代价。两个例子：
如果您将 YourLang 函数调用实现为 C 函数调用——也就是说，您天真地使用 C/本机堆栈——您将失去支持深度递归的能力，适当的尾递归、延续以及可能的堆栈检查。 （或者至少，你必须更仔细地考虑它们。）
如果你将单个 YourLang 线程映射到单个 POSIX/Windows/任何线程，你将无法像 Erlang 那样支持大规模并发。
但这并不意味着您不能用 C 语言编写解释器或编译器和运行时。
Yes. There are some cases where mapping a feature of your language onto a similar feature of C will cost you. Two examples:
If you implement a YourLang function call as a C function call---that is, you're naively using the C/native stack---you lose the ability to support deep recursion, proper tail recursion, continuations, and possibly stack inspection. (Or at least, you have to think harder about them.)
If you map a single YourLang thread to a single POSIX/Windows/whatever thread, you won't be able to support massive concurrency like Erlang.
That doesn't mean you can't write your interpreter or compiler and runtime in C, though.