简介这是一份针对8086机器语言解码的浓缩型学习笔记主题聚焦于为汇编器编写者梳理指令编码规则适合对x86底层机制、机器码生成或汇编工具实现感兴趣的开发者参考。笔记系统覆盖8086指令格式、16位寄存器、五种寻址模式、操作码与立即数概念并细致整理了字节/字/双字的数据宽度、固定编码指令及双操作数指令编码原则同时以MOV指令为例给出大量可对照的机器码示例。资源为1个docx文档压缩包大小1.94MB便于本地查阅或打印。作者结合NASM实操验证标注了部分汇编器版本差异并附有寄存器编号、段寄存器编码、最长指令等细节说明能够帮助读者将抽象编码规则落到具体二进制序列减少逆向或汇编开发中的试错成本。已有127人浏览学习适合作为8086机器语言入门与查表速查的补充资料。1. 8086机器语言解码写给汇编器编写者的字节级译码手记给8086写汇编器或反汇编器的人迟早会卡在同一道坎上看得懂mov ax, bx的语义却说不清8bh, 11_000_001b这两个字节是怎么拼出来的。这份笔记的价值很直接——它把指令格式、寻址模式、寄存器编号和操作码的关系全部落到具体字节上用db伪指令反推编码过程相当于把8086的机器语言解码规则摊开摆在桌面上。无论你是准备实现一个汇编器、调试器里的反汇编模块还是在为某个复古CPU模拟器写指令译码表这份示例笔记都能帮你少走弯路。它不适合只想调用API的人适合需要亲自操作字节流的人。2. 机器语言的结构操作码、寻址模式与操作数的三层拆解2.1 指令编码的基本单位字节、字、双字与操作码8086机器语言里指令是变长的最短1个字节最长8个字节。理解编码的第一步是明确三个基本单位字节B是8位字W是16位双字D是32位。操作码opcode指定操作类型寻址模式addressing mode指明操作数在哪儿操作数operand则是指令要处理的最终对象。这三层的排列顺序在8086中基本是固定的前缀可选、操作码、MODREGR/M组合字节、位移量disp可选、立即数imm可选。比如这条指令F0 3E 81 80 CD AB 34 12翻译过来是lock add word [ds:bxsi-0x5433], 0x1234。其中F0是总线锁定前缀3E是段超越前缀覆盖为DS段81是ADD指令的立即数形式操作码80是MODREGR/M组合字节CD AB是16位位移量-0x543334 12是16位立即数。这个例子几乎展示了8086机器码的全部组成单元。2.2 双操作数指令的d位和w位方向与宽度的核心开关双操作数指令的编码核心在于操作码后面那个“寻址模式字节”也叫MODREGR/M字节。它的三个字段含义如下表所示字段位数作用MOD2位决定R/M字段是寄存器还是内存以及disp是8位还是16位REG3位指定一个通用寄存器或段寄存器R/M3位指定另一个操作数可能附带disp关键在操作码本身还带两个开关d位和w位。d1时REG字段表示目的寄存器源由MOD和R/M决定d0时MOD和R/M表示目的REG表示源。w1表示字操作w0表示字节操作。以mov ax, cx为例它的机器码是8b h, 11_000_001b。第一个字节8bh二进制是10001011其中最后一位1就是d1REG即目的是AX。第二个字节11_000_001b二进制拆开是MOD11寄存器模式、REG000AX、R/M001CX。也就是说d1表示AX是目的R/M字段的001指向源CX。这就是为什么8bh, 11_000_001b恰好对应mov ax, cx。如果方向反过来mov cx, ax编码就是8bh, 11_000_000b——d1REG变为001CXR/M变为000AX。d位一旦弄反译码结果就会出现目的和源颠倒的问题这是最典型的解码错误之一。2.3 16位与8位寄存器的编号表解码的查表基础寄存器编号是解码时的基础查询表。16位通用寄存器的编号顺序固定为AX000、CX001、DX010、BX011、SP100、BP101、SI110、DI111。8位寄存器同样对应AL000、CL001、DL010、BL011、AH100、CH101、DH110、BH111。段寄存器编号为ES00、CS01、SS10、DS11。这个编号不是随意定的它直接对应MODREGR/M字节里的REG三段位。比如mov es, ax的编码是10001110b, 11_0_00_000bREG字段是000AXR/M字段是000AX而操作码10001110b专门表示“寄存器到段寄存器”。反过来说mov ax, es用10001100b, 11_0_00_000b这个操作码的差异容易忽略——段寄存器和通用寄存器互传时有两个不同的操作码。3. 用NASM反推验证从汇编指令到字节串的完整流程3.1 实验环境与NASM版本清坑笔记里反复提到一个容易踩的版本坑NASM 2.10.04能用但NASM 0.98会翻车。原因在于0.98版本不识别分组的二进制常量比如11_000_000b这种下划线分组的写法。0.98会把下划线当成非法字符或解析错误导致无法编译。这个问题在写测试用例时尤其致命因为你可能手写了一大串二进制常量换台机器编译直接报错。我当时在某个老系统上做模拟器译码模块用的正好是NASM 0.98结果所有带分组的db语句全部编译失败。验证环境版本是排查的第一步nasm -v输出NASM version 2.10.04 compiled on Jun 7 2021就没问题。确认版本后下一步是写测试汇编文件用db直接生成机器码再手动解码来验证。3.2 三个关键汇编样本的编译验证笔记核心的验证手段是用db伪指令手工指定字节配合标准汇编指令对比输出。下面是一段完整的测试源码; test_decode.asm —— 用 db 手工拼机器码与标准汇编指令对照 [cpu 8086] [BITS 16] ; 测试1内存立即数 mov word [bxsi0x1BCD], 0x1234 db 0c7h, 80h, 0cdh, 1bh, 34h, 12h ; 测试2寄存器立即数长格式 mov word ax, 0x1234 db 0c7h, 11_000_000b, 34h, 12h ; 测试3寄存器立即数短格式 mov al, 0x34 db 0b0h, 34h ; 测试4用二进制分组常量写 MOD/REG/R/M db 0c6h, 11_000_000b, 34h ; 等价于 mov al, 0x34 的另一编码形式用以下命令生成二进制并查看字节nasm -f bin test_decode.asm -o test_decode.bin xxd test_decode.bin如果你的反汇编模块或译码表逻辑正确输出文件的字节序列应该与汇编指令完全一致。db和真实指令产生相同字节这本身就是对译码表的强验证——它同时覆盖了正向编码和反向解码两条路径。3.3 手动计算与机器码对照的关键参数手动解码时建议按以下顺序分析字节流第一步读第一个字节或前缀后的第一个字节判断是单字节固定编码指令还是需要后续MOD/REG/R/M字节的变长指令。比如0xB0是mov al, imm8的短格式0xC7是mov r/m16, imm16的长格式。第二步找到MOD字节拆出MOD/REG/R/M三个字段。MOD11时R/M是寄存器MOD00时无dispMOD01时disp为8位MOD10时disp为16位。第三步根据操作码的w位确定操作数宽度。w1时寄存器或内存是16位w0时是8位这直接影响后续立即数字节的长度。第四步检查是否存在段超越前缀和总线锁定前缀。前缀位于指令最前面如F0lock和3EDS段超越。这四个步骤的顺序不能乱。我以前图省事直接跳过前缀检查结果遇到带lock前缀的指令时整个译码路径全部错位调试了大半天才发现是前缀没处理。4. 指令族编码对照传送、栈操作与算术指令的差异4.1 MOV族的9种编码形态MOV指令是8086解码笔记里最详细的章节因为它几乎覆盖了所有寻址组合。按笔记整理MOV一共有9种形态每种形态的操作码都不同形态操作码示例机器码寄存器到寄存器16位8Bhd1mov ax, cx8bh, 11_000_001b寄存器到寄存器8位8Ahd1mov al, cl8ah, 11_000_001b内存与寄存器互传MOV r/m, r89h/8Bhmov [bxsi0x1234], ax89h, 10_000_000b, 34h, 12h内存与寄存器互传MOV r, r/m8Bhmov ax, [bxsi0x1234]8bh, 10_000_000b, 34h, 12h立即数到寄存器长格式C7hmov ax, 0x12340c7h, 11_000_000b, 34h, 12h立即数到内存C7hMOD≠11mov word [bxsi0x1BCD], 0x12340c7h, 80h, 0cdh, 1bh, 34h, 12h立即数到寄存器短格式B0h~BFhmov bl, 0x340b3h, 34h特定地址内存到AX/ALA0h/A1hmov ax, [1234h]0a1h, 34h, 12hAX/AL到特定地址内存A2h/A3hmov [1234h], al0a2h, 34h, 12h这里有个容易懵的地方同一条mov al, 0x34既可以用0B0h, 34h短格式也可以用0C6h, 11_000_000b, 34h长格式。这两种编码都合法只是长度不同。自己写汇编器时两种格式的选择直接影响代码密度——短格式省字节但只覆盖AL/AX长格式更通用。4.2 PUSH/POP/XCHG栈指令的字节长度差异PUSH和POP总是按字16位进行操作这是由8086的栈宽度决定的。PUSH的源可以是内存、通用寄存器或段寄存器其中通用寄存器还有1字节短格式push ax的短格式是50h二进制01010_000bpush di是57h01010_111b。而push word [bxsi0x1234]则需要完整编码FFh, B0h, 34h, 12h因为MOD10displacement是16位。POP对应地有短格式和长格式。pop ax的短格式是58h长格式是8Fh, 11_000_000b。两者的选择同样影响指令长度。XCHG比较特殊寄存器与内存交换数据时使用86h/87h操作码而通用寄存器与AX交换时有专用的1字节编码90h~97h。比如xchg ax, dx是92h10010_010bxchg ax, cx是91h。这类“固定编码的短指令”在解码时不需要查MOD/REG/R/M表直接用操作码就能确定操作数。4.3 LEA/LDS/LES与IN/OUT寻址模式的边界情况LEA指令只计算有效地址不访问内存操作码是8Dh。例如lea cx, [bxsi0x1234]的编码是8Dh, 10_001_000b, 34h, 12h。注意REG字段在这里用的是001CXMOD和R/M组合决定地址计算方式。LDS和LES从内存连续取出两个字分别送到通用寄存器和段寄存器。LDS的操作码是C5hLES是C4h。它们的共同点是固定从内存取两个16位值这是解码时最大的坑——如果内存操作数的MOD不是11后面必须跟disp。比如lds cx, [bxsi0x1234]是C5h, 10_001_000b, 34h, 12hdisp是16位。IN/OUT指令的编码相对简单特定端口用直接地址端口号放在立即数字节中DX间接端口则是一条无立即数的固定编码。in al, 20h是E4h, 20hin ax, dx是EDh。解码这类指令时立刻数宽度要根据是AL还是AX判断。5. 避坑清单8086机器语言解码中的五个常见翻车现场5.1 NASM 0.98不识别分组二进制常量现象源码里写了db 0c7h, 11_000_000b, 34h, 12h在NASM 0.98下编译直接报错提示非法字符或语法错误。原因NASM 0.98不支持下划线分组写法。11_000_000b在0.98中被解析为无效token。2.10以上版本才加入了对分组二进制的支持。解决要么升级NASM到2.x版本要么把所有分组常量改成连续写法如11000000b。如果你维护的构建环境不能升级批量替换下划线是唯一的出路。5.2 立即数长度与disp宽度误判现象字节流里明明应当是6字节的指令解码后只解出了4字节后续字节全部错位。原因没有根据w位和MOD字段正确判断disp和imm的长度。w1时imm是16位2字节w0时imm是8位1字节MOD10时disp是16位MOD01时disp是8位MOD00时无disp。解决解码时先写入参把w位、MOD值和操作码类型全部确定后再决定后续字段的长度。我的习惯是先算出一个“长度预测值”解完后再对比实际长度不匹配立即报错。比如mov word [bxsi0x1BCD], 0x1234操作码C7h确定w1MOD10确定disp16位imm16位所以总长是11226字节。5.3 段超越前缀和总线锁定前缀容易忽略现象遇到F0 3E 81 80 CD AB 34 12这类带前缀指令时解码器把F0当成无效操作码或者解出来的指令语义完全不对。原因8086指令前缀不是操作码但位于字节流开头。如果你没在前缀解析上做处理前缀字节会被当成操作码主线来解码。解决写一个前缀循环。先读第一个字节判断它是不是前缀F0/F2/2E/3E/26/36/64/65/66/67如果是就记录下来并继续读下一个前缀直到遇到真正的操作码。前缀最多两个所以这个循环是有上界的。5.4 固定编码指令被误判为双操作数指令现象0x37AAA指令被当成需要MOD/REG/R/M字节的指令来解结果多读两个字节后面的所有指令全部跑偏。原因没有先检查指令是否为固定编码的单字节操作码。AAA、AAS、AAD、AAM、LAHF、SAHF、PUSHF、POPF、XLAT、CBW等指令都是固定1字节编码不需要任何后续字段。解决在解码函数的开头建一个“单字节指令表”先查表命中命中就直接返回结果不走MOD/REG/R/M流程。这个顺序是必须的——查表在前可悲的是很多人反过来写。5.5 段寄存器与通用寄存器互传时操作码用错现象手写mov es, ax时用了8Ch段寄存器到寄存器而不是8Eh寄存器到段寄存器导致解码出的指令变成完全不同的语义。原因8Ch是mov r/m, sreg8Eh是mov sreg, r/m。这两个操作码只有一位之差方向完全相反。段寄存器的MOD字节中REG字段只有2位有效对应ES/CS/SS/DS第3位固定为0。解决把段寄存器互传操作码当成一对来记忆8Ch用于段寄存器作为源8Eh用于段寄存器作为目的。同时检查REG字段第3位是否为零如果为1那肯定不是段寄存器操作。6. 把笔记变成手算工具自建译码速查表与校验脚本笔记的价值在于可复用。我在读完这份示例笔记后做了一件事把它归纳成一张译码速查表和一段Python校验脚本。速查表的结构很简单按操作码族分组每组记录操作码、d/w位含义、后续字段长度。比如操作码指令族关键参数后续字段88h/89h/8Ah/8BhMOV r/m, r 与 MOV r, r/md位决定方向MOD/REG/R/M dispC6h/C7hMOV r/m, immw位决定imm宽度MOD disp immB0h~BFhMOV r/m, imm短格式低3位是寄存器编号immA0h~A3hMOV AL/AX, m 与 MOV m, AL/AXw位决定是AL还是AX16位地址偏移8Ch/8EhMOV sreg, r/m 与 MOV r/m, sregREG字段是段寄存器号MOD/REG/R/M50h~57h / 58h~5FhPUSH/POP r16低3位是寄存器编号无90h~97hXCHG AX, r16低3位是寄存器编号无下面这段Python脚本用于校验手工生成的机器码是否合理适合写入你自己的反汇编测试流水线# check_opcode.py —— 用于校验手工编码的 MOV 系列指令 # 思路根据操作码和参数自动生成预期字节长度与手写字节对比 def mov_encoding_length(opcode: int, mod: int) - int: 返回 MOV 指令的预期字节总长度。 opcode: MOV 变体的第一字节 mod: MOD/REG/R/M 组合字节的高两位 length 2 # 操作码 MOD/REG/R/M if mod 0b01: # disp8 length 1 elif mod 0b10: # disp16 length 2 if opcode in (0xC6, 0xC7): # 立即数指令w1 时 imm16 为 2 字节 length 2 if opcode 0xC7 else 1 return length # 示例字节串c7 80 cd 1b 34 12 opcode 0xC7 mod 0x80 6 # 0x80 的二进制 1000_0000MOD 10 manual_bytes [0xC7, 0x80, 0xCD, 0x1B, 0x34, 0x12] expected mov_encoding_length(opcode, mod) print(f期望长度: {expected}, 实际长度: {len(manual_bytes)}) assert expected len(manual_bytes), 长度不匹配指令字节数异常 print(校验通过)这段脚本的逻辑是先解析MOD/REG/R/M字节的高两位确定disp宽度再根据操作码类型加上立即数长度最终比对字节长度是否一致。实际使用时你还可以扩展成完整解码器——每解析一个字段就推进指针直到字节流终止。固定编码指令的强记清单也别落下AAA37h、AAS3Fh、CBW98h、CWD99h、LAHF9Fh、SAHF9Eh、PUSHF9Ch、POPF9Dh、XLATD7h。裁这些指令不需要任何MOD字节反汇编器里单独建一张哈希表就够了。从那以后我每次写汇编器译码模块都强制自己先过一遍这张速查表再用脚本校验字节长度最后才跑完整的指令测试集。这套流程救了我好几次——最严重的一次内存越界就是漏判了disp宽度靠长度校验脚本定位到了。希望帮到你。本文还有配套的精品资源点击获取