1、2、3 和 5：这种表示法有些多余，但我发现在汇编开发时这是一件好事。冗余有助于阅读。关于“让汇编器弄清楚”的观点很容易变成“让阅读代码的程序员弄清楚”，而我不喜欢当我是一个阅读者时。编程不是只写任务；即使程序员本人也必须阅读自己的代码，语法冗余也有很大帮助。
另一点是“%”和“$”意味着可以在不破坏向后兼容性的情况下添加新寄存器：添加没有问题，例如，一个名为xmm4，因为它将被写成%xmm4，不能与名为的变量混淆xmm4写时不带“%”。
至于打字量：通常，在汇编编程时，瓶颈是大脑，而不是手。如果“$”和“%”让你放慢速度，那么要么你的思考速度比通常被认为是人类可行的速度快得多，要么更可能的是，你手头的任务太机械化，不应该在集会;它应该留给自动代码生成器，即俗称的“C 编译器”。
添加“l”后缀是为了处理汇编器“无法”弄清楚的某些情况。例如，这段代码：
mov [esp], 10
是不明确的，因为它不告诉你是要写入一个值为 10 的字节，还是一个具有相同数值的 32 位字。 Intel 语法要求：
mov byte ptr [esp], 10
当你想到这一点时，这是相当丑陋的。 AT&T 的人们想要做出更理性的事情，所以他们想出了：
movb $10, (%esp)
他们更喜欢系统化，并带有“b”（或“l”或“w”）后缀到处。请注意，后缀并不总是required。例如，你可以写：
mov %al, (%ebx)
让 GNU 汇编器“弄清楚”既然你正在谈论 '%al'，那么移动是针对单个字节的。真的行 ！然而，我仍然发现指定大小更好（这确实对读者有帮助，程序员本人是他自己代码的首要读者）。
对于“反转”来说：恰恰相反。 Intel 语法模仿 C 语言中的情况，其中值在右侧计算，然后写入左侧。因此，考虑到阅读是从左到右进行的，所以写入是从右到左，即“相反”方向。 AT&T 语法恢复为“正常”方向。至少他们是这么认为的；因为无论如何他们决定使用自己的语法，所以他们认为可以按照他们认为的“正确的顺序”使用操作数。这主要是一种惯例，但并非不合逻辑。 C 约定模仿数学符号，只不过数学是关于defining值（“让 x 为值 5”）而不是关于指派值（“我们写下值 5into一个名为“x”的槽”）。AT&T 的选择是有道理的。只有当您将 C 代码转换为汇编语言时才会感到困惑，而这项任务通常应该留给 C 编译器。
从历史的角度来看，问题 5 的最后一部分很有趣。 x86 的 GNU 工具遵循 AT&T 语法，因为当时他们试图在 Unix 世界占据一席之地（“GNU”的意思是“GNU is Not Unix”）并与 Unix 工具竞争； Unix 处于 AT&T 的控制之下。这是在 Linux 甚至 Windows 3.0 之前的时代； PC是16位系统。 Unix 使用 AT&T 语法，因此 GNU 使用 AT&T 语法。
那么好问题是：为什么 AT&T 发现发明自己的语法是明智之举？如上所述，他们有一些理由，但也不无道理。当然，使用自己的语法的代价是它限制了互操作性。在那些日子里，C 编译器或汇编器作为一个单独的工具并没有真正的意义：在 Unix 系统中，它们应该由操作系统供应商提供。此外，Intel 在 Unix 世界中并不是一个大玩家。大型系统大多使用VAX或Motorola 680x0衍生品。没有人想到二十年后 MS-Dos PC 会成为桌面和服务器领域的主导架构。
