汇编程序可以在Linux发行版之间移植吗? [英] Is assembler portable between Linux distros?

问题描述

程序是否可以以汇编程序格式在Linux发行版之间移植(CPU架构差异较大)?

Is a program shipped in assembler format portable between Linux distributions (modulo CPU architecture differences)?

这是我提出问题的背景:我正在研究一种新的编程语言(称为Aklo)，其编程方式将是经典的编译为.s并将结果提供给GNU汇编器的方法.

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.

很显然，最终由自己编写实现会很好，但是我已经辞职了，用C ++维护它来解决鸡和蛋的问题:假设您是第一次下载编译器，它本身是用C编写的Aklo，您如何编译它?据我了解，不同的Linux发行版和其他类似UNIX的系统对二进制格式有不同的约定.

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.

但是这只是我想到的，一个解决方案可能是发送.s文件(嗯，每个CPU体系结构一个):可以假设您已经拥有或可以安装GNU汇编程序.当然，我仍然需要一个引导编译器，但这并不需要很快.我可以用Python编写.

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:

我仔细地看了一下LLVM，那里肯定有很多好东西，这会让我的生活更轻松-除非它会导致依赖于所安装的LLVM的正确版本.对开发机器的依赖并没有那么糟糕，但是在通常以程序作为源发布的世界中，使用Aklo编写的每个程序的每个用户都会产生相同的依赖，所以我认为也是如此付出高昂的代价.

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.

但是，如果将编译后的程序作为汇编程序交付的解决方案可以解决问题，那么我就可以使用LLVM，这将是一个巨大的胜利.

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.

结论:从此处和LLVM邮件列表中的答案中 http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-January/028991.html 看来，坏消息是无法解决的问题，但是好消息是，使用LLVM可以解决此问题更糟的是，我可以自由地这样做并获得所有好处.

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.

推荐答案

在非常高的层次上，ABI由{指令集，系统调用，二进制格式，库}组成.

At a very high level, the ABI consists of { instruction set, system calls, binary format, libraries }.

作为.s的发行版可能会使您脱离二进制格式.这仍然是毫无意义的，因为您已经固定到特定的ISA，并且仍然需要使用库和/或进行系统调用.库随发行版的不同而有所不同(尽管实际上并没有那么糟，尤其是如果您仅使用libc时)，并且系统调用因操作系统而异.

Distribution as .s may 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.

这篇关于汇编程序可以在Linux发行版之间移植吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！