简介这是武汉理工大学计算机科学与技术学院汇编语言程序设计课程的实验报告适合正在学习汇编语言或需要完成同类实验作业的本专科生。报告涵盖四个实验熟悉DOSBox与debug调试环境、顺序程序设计、循环程序设计、子程序设计并以数据传送、加减法、乘除、逻辑与移位等指令为线索记录了每条指令执行后寄存器与内存的状态变化便于对照验证和复盘。整个资源为1个docx文档大小172KB内容包含实验目的、原理设计、调试过程与结果分析等完整模块可直接参考实验流程与结论整理。目前已有1264人学习可用于巩固CPU工作原理、栈机制、标志位变化及常用汇编指令的掌握对完成课程报告和上机实操均有较强参考价值。1. 汇编实验课程报告不是“写作文”而是把机器过程讲清楚第一次见到文件名是“武汉理工大学汇编实验课程报告.docx”时大部分人其实并不是缺代码而是不知道这份 Word 文档到底该写什么。汇编实验和 Java、Python 的实验完全是两种写法前者的核心是处理器状态变化不是“实现了某个功能”。很多人把报告做成代码大全和截图拼盘结尾再补一段希望结果被老师批“没有分析过程”。下面按一条能复现的路子走先把 8086 汇编实验的编译调试环境搭起来让每条指令都能跑、能单步、能看寄存器再按评分老师习惯的六段结构把实验过程和屏幕证据写进 .docx最后列几个几乎每次上机都会踩的编译与排版坑。目标只有一个让这份报告经得起复现与追问而不是靠页面堆砌碰运气。2. 8086 汇编实验环境搭起来DOSBox 挂载、MASM 编译、DEBUG 调试2.1 为什么选 DOSBox MASM而不是 TASM 或 emu8086本科汇编实验的主流组合是 DOSBox MASM 6.11部分课程用 TASM也有同学图省事装 emu8086。先讲差别。TASM 和 MASM 在语法层面差异不大但教学课件、参考代码和网上能查到的实验答案绝大多数按 MASM 写用 TASM 去编译 MASM 源码经常要改一两个伪指令才能过纯属给自己添麻烦。emu8086 有图形界面能直观看到寄存器和内存新手第一节课会觉得好用但它模拟的 DOS 中断行为与实际环境有偏差同一个程序在 DOSBox 里重跑输出顺序和 AH 返回值可能不一样。我一般建议直接用 DOSBox MASM 6.11遇到问题搜出来的解决方案最多报告里写“MASM 编译零警告”也最有底气。DOSBox 的作用是模拟一个能跑 16 位实模式程序的 DOS 环境。现代 Windows 系统已经移除了 NTVDM直接双击编译出的 .exe 基本跑不起来如果为了课程装虚拟机又太重。DOSBox 的好处是把宿主机上的一个目录映射成 DOS 的盘符编译、运行、调试都在这个盘里完成不需要准备镜像或软盘。注意一点DOSBox 对中文处理很弱实验目录必须用纯英文路径这一点第 5 章还会专门说。环境层面的“万能解法”就是这句话目录纯英文、挂载固定盘符、文件版本和报告同步。2.2 建立目录结构写出第一个能编译的 .asm动手第一步不是写代码而是定目录。我习惯在 D 盘建D:\ASM下面按实验编号建子目录L1、L2。这样做是为了后面第 4 章的版本对齐每个实验一个文件夹.asm、.exe、.docx放一起提交前一眼能检查完。目录建好后写第一个程序。这里不求算法复杂只求把“数据段、代码段、中断调用”三个要素走一遍。下面这个最小模板会在屏幕显示一行字符然后返回 DOS; 实验1 Hello 最小程序 ; 功能向屏幕输出一行字符后返回 DOS DATA SEGMENT MSG DB Hello, 8086!, 0DH, 0AH, $ DATA ENDS CODE SEGMENT ASSUME CS:CODE, DS:DATA START: MOV AX, DATA MOV DS, AX ; 数据段寄存器初始化 LEA DX, MSG MOV AH, 09H INT 21H ; DOS 功能调用显示字符串 MOV AH, 4CH INT 21H ; 返回 DOS CODE ENDS END START说明一下这段代码的逻辑。DATA SEGMENT开始数据段MSG是用DB定义的一串 ASCII 字符0DH, 0AH是回车和换行让输出后在屏幕不粘下一行提示符。最后的$是 DOS 功能调用 09H 的字符串终止标记很多新手在这里翻车漏写$程序会把数据段之后的随机内存当作字符串一路打印屏幕上出现一堆乱码。代码段里前两条指令MOV AX, DATA和MOV DS, AX是为了把数据段的段地址加载给 DS。8086 不会像高级语言那样自动设置数据段寄存器漏了这条LEA DX, MSG取到的偏移地址仍然指向旧 DS 的段基址运行结果必然错误。INT 21H是 DOS 中断AH09H显示字符串AH4CH结束进程。ASSUME CS:CODE, DS:DATA的含义是告诉汇编器这个代码段对应 CS数据段对应 DS。它只是给汇编器的编译指示并不会生成任何机器指令真正的段寄存器赋值要靠前两条 MOV 完成。END START则是指定程序入口地址是START标签相当于 C 语言的main入口声明。2.3 编译、连接、运行与单步调试命令和输出怎么看写完.asm后在 DOSBox 中先挂载目录再进入实验子目录mount c d:\asm c: cd L1 masm HELLO.ASM link HELLO.OBJ HELLO.EXEmount c d:\asm把宿主机目录映射成虚拟 C 盘如果 D 盘路径里带中文或空格挂载可能直接失败而且失败信息很隐晦所以第一步就必须保证全英文路径。masm HELLO.ASM会把源代码翻译成目标文件.obj中间如果提示有语法错误会给出行号和错误码。link HELLO.OBJ负责连接成可执行文件。两个命令后面都可以加分号表示“其余选项全部用默认值”比如masm HELLO.ASM;不按回车问源清单文件。程序运行结果如果在 DOSBox 窗口一闪而过可以在代码末尾的INT 21H前加一个等待按键的功能调用MOV AH, 01HINT 21H。但注意这会把最后返回 DOS 的状态搞乱更稳妥的做法是运行前在命令行先执行pause类的外部命令或者在 DOSBox 窗口标题栏设置“截图和录屏”快捷键准备抓图。调试环节才是汇编实验的精华位置。用 DEBUG 工具可以单步执行并观察寄存器状态debug HELLO.EXE -u -t -r-u是把当前位置的机器码反汇编成指令你会看到MOV AX, DATA的机器码前缀这正是报告“指令机器码分析”需要的证据。-t是单步执行一行-r则显示当前所有寄存器值。执行MOV AX, DATA后AX里的值会变成数据段基地址执行MOV AH, 09H后AH显示09。这些瞬间变化写进报告里比任何文字描述都有说服力。DEBUG 是汇编实验的黑匣子破除器程序在你眼中不再是一段文本而是寄存器、内存和标志位一步步变化。3. 报告正文的六段结构汇编实验的评分点拆解3.1 评分老师希望看到的六个模块和常见丢分点一份能站住的汇编实验报告结构上通常跑不出六个模块实验目的、实验原理、实验内容与步骤、源程序清单、运行结果、问题与总结。拿“武汉理工大学汇编实验课程报告.docx”这类文件名来说具体排版可能五花八门但评分维度大同小异。与其纠结模板格式不如先把这六块的“核心得分内容”列清楚。实验目的不要写“加深对计算机系统的认识”这种空话评分老师看到第一句就会判定你在凑字数。更稳的写法是“理解 MOV 指令对源操作数和目的操作数的位数约束观察 INC 指令对标志位 CF 的影响”。目的越具体越容易被判定为真实动手。实验原理要写清本实验涉及的硬件机制比如子程序调用时返回地址如何压栈、堆栈段 SP 的变化规律、DOS 功能调用时 AH 和 DX 的约定。原理不是抄课本定义而是解释程序里哪一行指令对应哪个机制。实验内容与步骤按“输入什么—执行什么—改变什么—看到什么”来写每一步对应一个可观察结果。下面是一个简化的模块评分对照按我多年见过的评卷习惯整理模块常见丢分点建议写法实验目的空泛没有落点写到具体指令、具体标志位、具体寻址方式实验原理大段抄书结合本次程序说明机制如子程序返回地址入栈过程内容与步骤只有代码没有过程每步配寄存器变化或内存变化源程序清单整段堆代码无注释分模块贴代码关键行写注释运行结果只有截图没有解释截图 寄存器值 内存地址说明问题与总结只写“我学会了”写实际遇到的现象、排查路径、最终结论这个表本身就可以当成报告提纲用。你写完每块内容后回头对照表格看有没有踩中丢分点基本能挽回一半分数。3.2 源程序清单的正确呈现模块拆分比整段粘贴更重要很多人把.asm文件从头到尾贴进 .docx一贴就是两页半。这个做法有两个问题第一汇编源码一行一行看非常累评卷人很难定位功能模块第二程序一旦超过一百行里面嵌套的循环和子程序调用逻辑根本看不清楚。我见过有人交上四百多行汇编代码全部铺在 Word 里、标号缩进全部丢失的报告截图里连注释都错位这种基本不会被细看。更好的做法是拆成三段展示数据定义、主程序、子程序。如果实验内容单一至少也要拆成“常量与数据段”“代码段入口”“功能调用与返回”三块。每块用明显的标题分隔代码内保留原始缩进关键行加中文注释。注释要解释“为什么”不是翻译指令。比如写MOV DS, AX注释写“DS 指向数据段否则 LEA 取到的偏移无意义”就比“将 AX 放入 DS”有价值得多。评卷人扫一眼你的注释就知道你有没有真明白。代码字体也要统一。Word 默认的等线字体显示 ASCII 字符时宽度不一致导致汇编代码的对齐全部错位。建议全选代码块字体改成 Courier New 或 Consolas字号小四到五号均可。缩进必须用空格不要用 Tab。很多编辑器默认会把 Tab 显示成 8 个字符宽粘进 Word 后一旦行距和制表位设置不一致代码缩进就彻底乱了。3.3 运行结果不仅要有截图还要有寄存器与内存快照运行结果这一块是汇编实验报告里最容易拉开差距的地方。C 语言实验截图能证明“程序运行了”汇编实验如果只有运行截图等于没有证明任何事因为汇编考的本来就是指令执行细节。我的习惯是每个关键步骤配三样东西程序运行的屏幕输出、DEBUG 或调试器里的寄存器状态、被修改的内存单元前后对照。举个例子实验要求是“用循环实现 10 个数的累加”。运行结果部分除了显示最终结果数字还可以在循环执行后打一个-r截取 AX 寄存器里的和再-d查看数据段内存的原始数据。报告里写“内存偏移 [SI] 初始值为 12H、34H循环后 SI 指向 [SI9]AX 累加值为 2A8H”。这句话一对上截图整个实验过程就完整了。这里要提一个几乎所有汇编实验报告都会踩的坑截图模糊。DOSBox 窗口默认分辨率不高截完图贴在 Word 里会变虚。解决方法是设置 DOSBox 的输出为 OpenGL 模式并将窗口放大后再截图或者在 DOSBox 中用CtrlF5直接保存 PNG 截图这个快捷键生成的 PNG 比按PrtSc键再粘贴要清晰得多。截图命名也要规范比如fig3-1-start.jpg、fig3-2-debug-r.jpg不要全是1.png、2.png后续写图和图序时不容易乱。4. 把汇编实验写进 .docx排版三原则与版本对齐4.1 代码块在 Word 中的排版三原则等宽、底纹、单倍行距从.asm源码到.docx的过程排版质量直接影响评阅体验。汇编代码对形位敏感符号对齐错乱后程序逻辑根本没法读。我处理代码块时永远遵守三件事第一字体全部用 Courier New 或 Consolas保证每个 ASCII 字符等宽列对齐不垮第二给代码段落加浅灰色底纹视觉上和正文区分通常用 Word 的“边框和底纹”功能对段落设置灰度为 10%~15%第三行距设为单倍取消段前段后距离否则每 30 行左右代码会多出半个屏幕的空白整个报告页数暴涨。这三件事用 Word 菜单操作起来不难选中代码段落字体选 Courier New然后“段落”对话框里行距选“单倍”底纹在“设计—页面边框—底纹”里调。更省事的方式是先定义好一个“汇编代码”段落样式后续每次贴代码都套这个样式。这里有一个小建议代码块内部的行号不要手工输入手工编号意味着每次修改代码都要重改一遍编号容易和实际行号对不上。确实需要行号时用 Word 的编号功能或者干脆不写行号报告中引用代码行时用附近的标签名说明位置比如“在 START 标号后的第三条指令处”。4.2 用表格承载寄存器状态对照减少长段文字汇编实验报告里经常要描述“执行前后”的变化。这类内容用文字写很啰嗦比如“执行 MOV AX, DATA 后AX 变成 0B2CHDS 还是 0B00H”这样的句子多了读起来像流水账。换成表格更简洁左侧一列写寄存器名中间写指令执行前的值右侧写执行后的值一眼就能对齐实验要求。例如子程序调用实验栈变化过程是考点可以做成下面的表观察点CALL 指令执行前CALL 指令执行后RET 指令执行后SP0FFEH0FFCH0FFEHSS1000H1000H1000HIP0180H0183H原始调用点下一条栈顶内容无关数据返回地址低字节已弹出表格行数不要太多一般 4~6 行足够。列名写清观察点评卷人可以直接拿它和标准答案比对。汇编实验报告中需要频繁使用的表还有变量清单格式为“变量名、类型、初值、作用”适用于数据段定义较多的实验。4.3 docx 里的代码必须重新编译通过提交前版本一致性这一条是我见过最普遍、也最致命的问题报告里的源码和磁盘上的.asm文件不一致。常见场景是你调好了运行版本写报告时又觉得某段代码注释不够于是在 Word 里逻辑修改代码并复制粘贴但忘了回改.asm源码。评卷时老师如果对比报告和可执行文件直接判“报告代码不可复现”。避免这个问题的方法很简单但必须形成习惯报告写完把报告里的代码块重新粘回一个新的.asm文件在 DOSBox 里完整跑一遍编译和连接确认生成结果和报告截图一致。如果报告是分模块贴代码的就把所有模块按顺序复制成一个完整文件再编译。模块化展示容易让人忽略“这些模块拼在一起是否能编译”这一步刚好能兜住。另外文件夹命名可以刻板一点L3_LETTERSORT里面放L3.asm、L3.exe、L3_实验报告.docx。提交前检查这三个文件的时间戳如果.exe时间早于.docx说明报告可能有新增改动没有重新编译如果.docx时间早于.asm说明报告可能没包含最后一次修改。这是个粗糙但有效的判断方法比靠记忆可靠。如果你习惯用脚本处理文档在 Windows 上用certutil -hashfile L3.asm SHA256算一下哈希把这个值作为附录写到报告末尾也算给“可复现性”加了个硬证据。不过这个操作对大多数课程并不必要太重的自证反而显得奇怪一般做到重新编译一致即可。如果想自动化比对 Word 段落Java 用 Apache POI 读取 docx 段落和对应章节可以把代码块文本抽出来与.asm做逐行 diff这在报告内容超过三页时能省下不少人工校对的精力。5. 汇编实验的避坑手册编译报错与报告翻车的五个实例5.1 运行输出一串乱码字符串终止符$丢失或错位现象程序编译连接都正常运行后目标字符串后面跟着十几个、?或随机字符甚至把后面的数据段内容也打印了出来。原因DOS 功能调用09H也就是INT 21H的字符串显示功能依赖内存中的$字符作为终止标记。字符串定义DB里没有$或者$位置写错在回车换行之前都会导致函数越过字符串边界继续读取内存直到碰到随机字节恰好是$才停。解决定义字符串时最后显式加DB ... , $注意$是普通字符不占用特殊含义检查时优先看回车换行符0DH, 0AH是否在$之前。报告里记录这个问题时把修改前输出乱码的截图和修改后正常输出的截图放一起正好对应实验“问题与分析”模块。5.2 编译报错 Operand must have size字节和字变量放错了位置现象MASM 编译时报错Operand must have size位置通常指向某一条 MOV 指令。原因数据段里定义了BUF DB 10 DUP(?)这是字节型变量代码里却写了MOV AX, BUF意图是把整个缓冲区内容搬进 AX。但BUF是字节类型AX 是 16 位寄存器汇编器不知道你究竟要取低 8 位还是连续取两个字节于是报“操作数必须指明大小”。解决如果是想取第一个字节改成MOV AL, BUF如果缓冲区声明本身就应该是字类型把定义改成BUF DW 10 DUP(?)。这种情况在字符串实验里尤其常见。报告里不要只写“改了类型”要写清楚你为了让数组元素逐个参与运算选择了用SI变址寻址逐字节访问并解释为什么不能用AX一次读入。5.3 条件跳转报错 Relative jump out of range短跳范围不是玄学现象程序加了段比较长的功能代码后MASM 提示Relative jump out of range报错的是某条JNZ或JZ。原因条件跳转指令在机器码层面只有 8 位相对偏移跳转范围是从下一条指令地址算起往前后各 128 字节也就是-128 ~ 127。目标标号距离当前指令太远条件跳转放不下这么大的偏移于是报错。解决把条件跳转变成两步。第一步“跳过”一个无条件跳转第二步用无条件跳转到真正目标。比如原代码是JNZ FAR_LABEL改写成JZ SKIP_JUMP ; 条件取反跳过下一个 JMP JMP FAR_LABEL ; 无条件跳转近跳转范围覆盖整个段 SKIP_JUMP:这段代码的逻辑是当条件成立时不执行JMP直接走SKIP_JUMP后面的指令条件不成立时执行JMP FAR_LABEL。注意条件由JNZ变成了JZ这是初学者最容易改错的地方。报告中记录这个错误时写清是从哪个标号改到哪个标号、距离大约多少字节比只报“修复跳转错误”更有说服力。5.4 DOSBox 挂载失败或目录打不开中文路径是万恶之源现象执行mount c d:\实验3后 DOSBox 提示Drive C does not exist!或者挂载成功后DIR列出乱码文件名程序运行时找不到文件。原因DOSBox 对中文目录和中文文件名的支持非常有限内部使用的代码页和现代 Windows 不匹配中文路径会被截断或映射错误。解决实验目录从根目录开始全部使用英文字母、数字、下划线例如D:\ASM\L3。已经建了中文目录的先复制到英文目录再挂载。这件事放在报告里不值得写进实验结果但可以在实验步骤中注明“实验环境要求所有文件路径为 ASCII 字符”这反而是个专业细节能体现你踩过坑并做了约束。5.5 报告代码与可执行文件对不上提交前的最后一分钟翻车现象老师复查时说报告的代码和可执行文件行为不符要求重写并扣过程分。原因多数是改完代码后忘了更新报告或者报告里贴的是早期版本。这类问题在拼接.docx时最明显——分模块贴代码虽然易读但也容易贴错模块顺序。解决写完报告后把报告里的代码块按顺序复制回一个新.asm文件重新执行masm、link和运行全部通过才算完活。DOSBox 里命令保存的文本可以复制到报告附录作为本次编译的原始记录。另一个更稳的习惯是每个实验目录里只保留最终版本的三个文件旧的中间版本一律放进backup子目录避免提交时抓错文件。6. 一个加分收尾用“重放日志”让报告不是一锤子买卖报告不是交上去就结束它其实是你的调试记录。我会在每次汇编实验里建一个叫REPLAY.md的文本文件格式非常简单日期、操作内容、关键命令、结果。比如“18:32 修改 L2.ASM 第 40 行将 LOOP 改为 DEC SI JNZ原因是 LOOP 修改 CX 导致内层循环计数丢失编译通过运行结果见 fig4”。这个文件不写进正式报告但它是写作报告时所有细节的来源。到了写 .docx 时我不会凭空回忆而是把重放日志里最有价值的三段摘出来第一次运行失败的截图及原因分析、第二次修改的逻辑依据、最终验证用的寄存器快照。这三段恰好对应报告里的“问题与总结”而且内容真实。没有这份日志就回到一边翻目录一边硬凑总结的老路最后只能写“通过本次实验加深了对汇编语言的理解”这种空句子。我自己吃过一次亏交的排序实验报告里贴的代码比实际.asm少了一个交换中间变量老师当场运行link后程序行为不一致直接退回来重写。后来我养成的习惯是报告里每一段代码都当场复制回一个干净的.asm编译、连接、运行、截图一条龙做完再继续写下一段。虽然慢但不会再出现“第 5.5 节那种翻车”。如果你现在刚开始写第一份汇编实验报告不妨也建一个重放日志把每次 DEBUG 看到的寄存器变化记下来报告结尾把这些结果当作“验证记录”列出来比任何心得体会都更能说明你动手做过。希望这个方法能帮到你。本文还有配套的精品资源点击获取