AT&T汇编中操作符宽度与寄存器宽度不匹配时的行为是怎样的？

首先纠正一个常见误解：AT&T语法中无后缀的指令并非默认对应16位操作。当指令操作数包含明确宽度的寄存器时，汇编器可自动推断操作宽度，此时后缀可以省略。比如mov %eax, %ebx没有显式后缀，汇编器会自动识别为32位的movl操作。

关于你关心的核心问题：如果AT&T汇编代码中出现助记符后缀指定的操作宽度和寄存器实际宽度不一致的情况，主流的GNU汇编器（GAS）会直接抛出操作数尺寸不匹配的错误，终止汇编流程，不会生成目标文件，也不存在“哪一方优先级更高”的兼容处理逻辑。

举两个典型的错误示例：

• 写movl %ax, %cx：l后缀指定32位操作，但%ax、%cx都是16位寄存器，汇编器会返回类似Error: operand size mismatch for 'movl'的错误提示
• 反过来写movw %eax, %ecx：w后缀指定16位操作，但%eax、%ecx是32位寄存器，同样会触发尺寸不匹配报错

附AT&T汇编常用操作后缀对应的宽度：

• b：8位（byte），匹配al/bl这类8位寄存器
• w：16位（word），匹配ax/bx这类16位寄存器
• l：32位（longword），匹配eax/ebx这类32位寄存器
• q：64位（quadword），匹配rax/rbx这类64位寄存器

内容的提问来源于stack exchange，提问作者user2138149