assembly - 关于 AT&T x86 语法设计的问题

Question

谁能向我解释为什么 AT&T 语法中的每个常量前面都有一个“$”？

为什么所有寄存器都有一个“%”？

这只是让我做很多蹩脚打字的另一种尝试吗？

另外，我是不是唯一一个发现:16(%esp)与 [esp+16] 相比确实违反直觉?

我知道它编译成同样的东西，但为什么有人想要输入很多 '$' 和 '%' 而不需要？ - 为什么 GNU 选择这种语法作为默认语法？

另一件事，为什么 at&t 语法中的每条指令都以:l 开头？ - 我知道它的操作数大小，但是为什么不让汇编程序弄清楚呢？
(我是否想对不是那个大小的操作数执行 movl 操作？)

最后一件事:为什么 mov 参数颠倒了？

是不是更合乎逻辑:

eax = 5
mov eax, 5

其中 at&t 是:

mov 5, eax
5 = a (? wait what ?)

笔记:
我不是要拖钓。我只是不明白他们所做的设计选择，我想知道他们为什么要这样做。

Answer 1

1、2、3和5:符号有点多余，但我发现在汇编中开发时这是一件好事。冗余有助于阅读。 “让汇编程序自己算出来”这一点很容易变成“让读代码的程序员自己算出来”，我不喜欢自己读代码。编程不是只写任务；即使是程序员自己也必须阅读自己的代码，语法冗余也有很大帮助。

另一点是 '%' 和 '$' 意味着可以在不破坏向后兼容性的情况下添加新寄存器:添加没有问题，例如名为 xmm4 的寄存器。 ，因为它会写成 %xmm4 ，不能与名为 xmm4 的变量混淆这将在没有“％”的情况下写入。

至于打字量:通常情况下，在汇编编程时，瓶颈是大脑，而不是手。如果 '$' 和 '%' 减慢了你的速度，那么要么你思考的速度比通常认为对人类可行的速度快得多，要么更有可能是你手头的任务过于机械，不应该在集会;它应该留给自动代码生成器，通俗地称为“C 编译器”。

添加了“l”后缀以处理某些汇编程序“无法”解决的情况。例如，这段代码:

mov  [esp], 10

是模棱两可的，因为它不会告诉您是要写入值为 10 的字节，还是要写入具有相同数值的 32 位字。然后英特尔语法要求:

mov  byte ptr [esp], 10

当你想到它时，这很丑陋。 AT&T 的人想要做一些更理性的事情，所以他们想出了:

movb   $10, (%esp)

他们更喜欢系统化，并且到处都有“b”(或“l”或“w”)后缀。请注意，并不总是需要后缀。例如，您可以编写:

mov   %al, (%ebx)

并让 GNU 汇编程序“弄清楚”既然您在谈论 '%al'，那么移动是针对单个字节的。真的行 !然而，我仍然发现指定大小更好(它确实对读者有帮助，而程序员本人是他自己代码的第一个也是最重要的读者)。

对于“反转”:相反。 Intel 语法模仿 C 中发生的事情，其中​​值在右侧计算，然后写入左侧的内容。因此，考虑到阅读是从左到右，写作从右到左，在“相反”的方向上。 AT&T 语法恢复到“正常”方向。至少他们是这么认为的；由于他们决定无论如何都使用自己的语法，因此他们认为可以按照他们认为的“正确顺序”使用操作数。这主要是一种约定，但不是不合逻辑的约定。 C 约定模仿数学符号，除了数学是关于定义值(“让 x 成为值 5”)而不是分配值(“我们将值 5 写入一个名为‘x’的槽中”)。 AT&T 的选择是有道理的。仅当您将 C 代码转换为汇编代码时才会令人困惑，该任务通常应留给 C 编译器。

从历史的角度来看，问题 5 的最后一部分很有趣。 x86 的 GNU 工具遵循 AT&T 语法，因为当时他们试图在 Unix 世界中占据一席之地(“GNU”意味着“GNU 不是 Unix”)并与 Unix 工具竞争； Unix 由 AT&T 控制。这是在 Linux 甚至 Windows 3.0 之前的时代； PC 是 16 位系统。 Unix 使用 AT&T 语法，因此 GNU 使用 AT&T 语法。

那么好问题是:为什么 AT&T 认为发明自己的语法很聪明？如上所述，他们有一些理由，但并非没有道理。当然，使用您自己的语法的代价是它限制了互操作性。在那个年代，C 编译器或汇编器作为单独的工具并没有什么实际意义:在 Unix 系统中，它们应该由操作系统供应商提供。此外，英特尔在 Unix 世界中并不是一个大玩家。大型系统大多使用 VAX 或摩托罗拉 680x0 衍生产品。没有人想到 MS-Dos PC 会在 20 年后成为台式机和服务器领域的主导架构。