汇编程序可以在 Linux 发行版之间移植吗？
以汇编程序格式提供的程序是否可以在 Linux 发行版之间移植（模 CPU 架构差异）？
这是我的问题的背景：我正在开发一种新的编程语言（名为 Aklo），其操作方式将是经典的编译为 .s 并将结果提供给 GNU 汇编器。
显然最终最好能自己编写实现，但我已经放弃了用 C++ 维护它来解决先有鸡还是先有蛋的问题：假设您第一次下载编译器并且它本身是用 Aklo 编写的，如何你编译它吗？据我了解，不同的 Linux 发行版和其他类似 UNIX 的系统对于二进制格式有不同的约定。
但我突然想到，一种解决方案可能是发送 .s 文件（嗯，每个 CPU 架构一个）：可以公平地假设您拥有或可以安装 GNU 汇编器。当然，我仍然需要一个引导编译器，但这不需要太快；我可以用Python写它。
汇编程序的可移植性是否与二进制文件不同？还有其他我没有想到的绊脚石吗？
回应一个答案时添加的：
我满怀渴望地看着 LLVM，那里肯定有很多好东西，它会让我的生活更轻松——除了它会产生对所安装的 LLVM 正确版本的依赖。对开发机器的依赖并不是那么糟糕，但在一个将程序作为源代码发布的世界中，使用 Aklo 编写的每个程序的每个用户都会产生相同的依赖关系，我认为这也太糟糕了付出的代价很高。
但如果将编译后的程序作为汇编程序传送的解决方案有效……那么就解决了这个问题，而且我毕竟可以使用 LLVM，这将是一个巨大的胜利。
因此，关于汇编程序的可移植性的问题比我最初意识到的要重要得多。
结论：来自此处和 LLVM 邮件列表的答案 http:// /lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028991.html 似乎坏消息是问题无法解决，但好消息是这意味着使用 LLVM 不会让情况变得更糟，所以我可以自由地这样做并获得其中的所有优势。
Is a program shipped in assembler format portable between Linux distributions (modulo CPU architecture differences)?
Here's the background to my question: I'm working on a new programming language (named Aklo), whose modus operandi will be the classic compiling to .s and feeding the result to the GNU assembler.
Obviously it would be nice ultimately to have the implementation written in itself, but I had resigned myself to maintaining it in C++ to solve the chicken and egg problem: suppose you download the compiler for the first time and it is itself written in Aklo, how do you compile it? As I understand it, different Linux distributions and other UNIX like systems have different conventions for binary formats.
But it's just occurred to me, a solution might be to ship the .s file (well, one per CPU architecture): it's fair to assume you have or can install the GNU assembler. Of course I'd still need a bootstrap compiler, but that doesn't need to be fast; I can write it in Python.
Is assembler portable in the way that binaries are not? Are there any other stumbling blocks I haven't thought of?
Added in response to one answer:
I had looked wistfully at LLVM, there is certainly a lot of good stuff there and it would make my life easier -- except that it would incur a dependency on the correct version of LLVM being installed. It wouldn't be so bad having that dependency on development machines, but in a world where it's common to ship programs as source, the same dependency would be incurred for every user of every program ever written in Aklo, and I decided that was too high a price to pay.
But if the solution of shipping compiled programs as assembler works... then that solves that problem, and I can use LLVM after all, which would be a big win.
So the question about portability of assembler is even considerably more important than I had first realized.
Conclusion: from answers here and on the LLVM mailing list http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028991.html it seems the bad news is the problem is unsolvable, but the good news is that means using LLVM makes it no worse, so I'm free to do so and obtain all the advantages thereof.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在走这条特定路径之前，您可能需要先查看 LLVM。它可能会让您的生活变得更加轻松，因为它提供了一个低级虚拟机，可以使很多困难的东西都能发挥作用并且非常受欢迎。
You might want to check out LLVM before going down this particular path. It might make your life a lot easier, as it provides a low level virtual machine that makes a lot of hard stuff just work and has been very popular.
在非常高的层面上，ABI 由{指令集、系统调用、二进制格式、库}组成。
以
.s形式分发可以使您摆脱二进制格式的束缚。这仍然毫无意义，因为您被固定到特定的 ISA，并且仍然需要使用库和/或进行系统调用。库因发行版而异（尽管这并不是那么糟糕，特别是如果您只使用 libc），并且系统调用因操作系统而异。At a very high level, the ABI consists of { instruction set, system calls, binary format, libraries }.
Distribution as
.smay free you from the binary format. This is still rather pointless, because you are fixed to a particular ISA and still need to use libraries and/or make system calls. Libraries vary from distribution to distribution (although this isn't really that bad, especially if you just use libc) and syscalls vary from OS to OS.距离我上次引导 C 编译器已经过去 20 年了。在编译器级别，Linux 发行版之间的差异很小。
采用 LLVM 的更重要原因是跨平台；如果您不编写某种中间语言，您的编译器将很难针对不同的处理器重新定位。在我的笔记本电脑上，我有 x86、x86_64、两种 MIPS、PowerPC、ARM 和 AVR 的编译器……你明白我要说什么了吗？我也可以为大多数目标编译多种语言（仅适用于 AVR 的 C）。
It's basically 20 years since I last bootstrapped a C compiler. At the level of compilers, the differences between Linux distributions are minimal.
The much more important reason for going LLVM is cross-platform; if you're not writing some intermediate language, your compiler will be extremely difficult to retarget for different processors. And seeing as, on my laptop, I have compilers for x86, x86_64, two kinds of MIPS, PowerPC, ARM and AVR... you see where I'm going? I can compile multiple languages for most of those targets too (only C for AVR).