简介：面向计算机专业本科生与系统结构课程学习者，这份实验报告围绕Cache性能分析、MIPS指令系统与体系结构、流水线冲突、指令调度与延迟分支四个核心实验展开。每个实验均包含实验目的、平台选择、具体步骤与总结心得，结构完整，便于对照课堂理论进行仿真验证。报告使用MyCache、MARS/MIPSsim等模拟器，对Cache容量、块大小、替换策略、流水线数据依赖与分支冒险等关键问题给出了清晰的配置方法和分析思路，能帮助读者快速掌握命中率分析、冲突处理及指令调度优化技术。资源为1个doc文档，压缩包容量885KB，内容精炼、目录层次明确，可直接作为实验报告撰写模板或系统结构课程复习资料。目前已有1150人学习下载，适合需要实验指导、梳理实验流程或快速备战的读者。 很多人对《计算机系统结构》这门课的第一印象是偏理论，觉得把课本上的概念背熟就能应付考试。可真到了写实验报告的时候才会发现，那些在PPT上见过的指令周期图、Cache替换策略、流水线冒险处理，全都要在一个又一个实验里扎扎实实跑一遍。我最早做这套实验时也走过不少弯路，要么在模拟器环境上卡了两天，要么测出来的数据跟理论预期对不上，最后交上去的报告自己都不满意。这篇博文就结合我做这套计算机系统结构实验的实际过程，把从环境准备、核心实验设计、数据记录到报告撰写的完整链路拆开讲清楚，给正在做相关实验、或者想提前了解这门课的读者提供一份能直接上手的实操参考。
1. 实验环境的搭建：比想象中更折腾的前置工作
很多人拿到实验指导书后第一件事就是打开模拟器准备开跑，结果发现环境问题比实验本身还耗时。这一节我把选型和踩坑过程写清楚，少走点弯路。
1.1 模拟器选型，我为什么不直接用开发板
计算机系统结构实验通常有两类载体：一是真硬件开发板（比如带有MIPS或RISC-V核的FPGA板），二是软件模拟器。我当时选的是软件模拟器方案，核心原因是可观测性强。开发板上的信号你得靠逻辑分析仪去抓，而模拟器可以直接打印出每一条指令的寄存器变化、访存地址和流水线停顿周期，这对理解系统结构内部行为帮助非常大。
具体选型上，不同学校用的工具不一样，常见的有：
- Logisim：适合做单周期CPU、微程序控制这类偏数字逻辑的实验，能直观看到数据通路上每一位信号的变化。
- MARS：MIPS指令集模拟器，适合做指令系统、汇编级实验，但对流水线和Cache行为几乎没有建模能力。
- gem5：功能很全的体系结构模拟器，能模拟CPU流水线、多级Cache、甚至多核一致性协议，但配置复杂，学习曲线陡。
- QEMU：偏向真实系统级模拟，如果要跑完整操作系统和应用程序，用它比较合适。
我的建议是别盲目追求功能全的工具，先看清楚实验要求考察的是哪个层次。如果只要求展示数据通路和控制信号，Logisim这类可视化工具最高效；如果要求分析程序在流水线中的停顿周期，那就得用gem5或者QEMU这类能导出统计数据的模拟器。
1.2 环境配置的三个隐藏坑
配置模拟器环境看起来就是装个软件的事，实际运行起来问题不少。举几个我真实遇到的：
第一是Java运行环境版本问题。Logisim和MARS都依赖Java，我当时装的是新版JDK，结果MARS某些窗口显示乱码，Logisim偶尔还会闪退。后来换成JDK 8才稳定下来。如果学校机房统一用的是老版本，别急着升到最新版。
第二是gem5编译依赖缺失。gem5需要若干系统库和交叉编译器，编译时若缺少某个依赖包，报错信息并不直观，容易让人误以为源码下载不完整。这里比较省事的办法是看官方文档里的依赖清单，一个一个比对安装，不要等报错了再搜。
第三是路径和权限问题。模拟器通常会生成大量中间文件和结果日志，如果把工作目录放在中文路径或者权限受限的目录下，脚本容易读取失败。我后来统一把实验目录放在纯英文、无空格的路径下，问题立刻少了很多。
注意：无论用哪个模拟器，建议先跑一个官方的Example程序，确认能正常导出波形或日志，再开始做正式实验。这一步能排除掉一半以上的环境问题。
2. 核心实验一：单周期CPU设计，把指令周期落实到数据通路
单周期CPU实验的目标很简单：设计一条数据通路，让每条指令在一个时钟周期内完成取指、译码、执行、访存、写回。听起来不难，但真正动手时会发现，难点不在每条指令本身，而在于多条指令之间控制信号的协调。
2.1 指令集裁剪与数据通路设计思路
实验通常不会要求实现完整指令集，而是给一个子集。我当时实现的是经典的五类MIPS指令：取数（lw）、存数（sw）、运算（add/sub/and/or）、分支（beq）、跳转（j）。别小看这个裁剪，它已经覆盖了系统结构里最重要的几个部件：寄存器堆、ALU、数据存储器、指令存储器、立即数扩展器、控制单元。
数据通路的设计顺序我建议固定成三步走：
- 先画所有指令共用的部分，也就是取指通路：PC指向指令存储器，读出指令，同时PC+4。
- 再按指令类型分别接出它们独有的部件。运算指令需要读寄存器堆、进ALU；访存指令需要计算访存地址、读写数据存储器；分支指令需要比较两个寄存器值并计算分支目标地址。
- 最后把不同指令都需要但有差异的控制点汇总成一张控制信号表。
这套顺序的好处是，每一步都在搭上一层，而不是一上来就想画出完整成品，逻辑清晰很多。
2.2 控制信号真值表：从指令格式反推
控制信号表是单周期CPU设计的灵魂，也是实验报告评分最看重的部分之一。我当时列的表包含RegDst、ALUSrc、MemRead、MemWrite、MemtoReg、RegWrite、Branch、Jump这八个关键信号，每一行的取值都从一个问题出发：这条指令在数据通路上需要哪个部件做什么？
以R型运算指令为例：运算结果要写到寄存器堆，所以RegDst=1（写目标寄存器选rd），ALUSrc=0（ALU第二个操作数来自寄存器堆），MemRead=0、MemWrite=0（不访存），MemtoReg=0（写回数据选ALU结果），RegWrite=1（要写寄存器），Branch=0（不分支）。每一行都能用同样的逻辑推出来，而不是死记硬背。
我还做了一件事：在实验报告里把每条指令对应的“生命周期”画成了通路高亮图。比如lw指令，把IF到WB阶段经过的所有部件和信号用箭头标出来。这个图看似简单，但它能直观证明你是真的理解了指令是怎么走通数据通路的，比大段文字描述有效得多。
2.3 实测中暴露的边界问题
仿真过程中最容易出问题的两个点，一个是PC更新逻辑，另一个是分支目标地址计算。
PC更新的问题出在跳转指令上。j指令的目标地址不是PC+4加上偏移量，而是用指令中的26位立即数替换PC高4位之外的部分。我第一次实现时直接照搬分支指令的地址计算逻辑，结果仿真时跳到了完全错误的位置。这说明动手前必须先弄清不同指令的寻址方式差异。
分支目标地址的经典坑是偏移量基数不对。beq指令的目标地址是(PC+4) + sign_extend(offset << 2)，很多人容易把PC+4写成PC。这个错误在教学仿真里尤其是分支延迟槽开启时特别隐蔽，因为有些指令恰好能跑到正确结果，但一旦分支方向改变就乱了。我的建议是写几组不对称的测试用例，比如分支边界处、负数偏移量、跳转到程序末尾等，一次性把边界情况暴露出来。
3. 核心实验二：Cache行为模拟，命中率不是拍脑袋算出来的
存储层次相关实验里，Cache是最常考的方向。它的核心指标是命中率，但命中率受容量、块大小、相联度、替换策略、程序访问模式等多种因素影响，绝不是简单套公式就能算明白的。
3.1 模拟器参数配置与测试程序设计
我做的Cache实验基于一个简易的Cache模拟器，输入是内存访问trace，输出是命中率、缺失率、缺失次数等统计信息。模拟器允许配置的参数主要有：
- Cache容量：从1KB到64KB不等。
- 块大小：16B、32B、64B。
- 相联度：直接映射、2路、4路、全相联。
- 替换策略：LRU、随机替换、FIFO。
直接跑随机trace没有意义，我设计了三组有代表性的测试程序来观察程序局部性和Cache参数之间的关系：
- 顺序访问数组：步长为1，每个元素4字节，访问总量远大于Cache容量。
- 大步长跳跃访问：每次访问间隔64个元素，也就是256字节，正好跨过多个Cache块。
- 循环嵌套矩阵访问：按行优先和按列优先两种方式访问同一个二维数组。
这三组程序分别对应时间局部性强、空间局部性差、以及访问顺序影响命中率三种典型场景，基本覆盖了Cache行为讨论的主要维度。
3.2 从命中率数据反推程序局部性
数据出来后不要急着截图写报告，先做一轮数据交叉验证。我当时最直观的发现是：块大小从16B提升到64B时，顺序访问程序的命中率明显提升，但对随机跳跃程序的改进微乎其微。这说明大块尺寸是通过空间局部性获益的，如果程序本身空间局部性差，增大块大小只会白白增加缺失开销。
另一个值得写进报告的现象是：二维数组按行优先和按列优先访问，在同样Cache配置下命中率差异非常大。行优先因为充分利用了连续存放的优势，命中率能到90%以上；而列优先在列跨度大于块大小时，几乎每次访问都会触发缺失。这个实验非常有说服力，因为它把“程序结构影响系统性能”这个抽象结论变成了可测量的数据。
替换策略在低相联度下差异最明显，4路以下时LRU明显优于随机替换，但到了8路以上，LRU和随机替换的差距会缩小。原因是相联度提高后，候选位置变多，随机替换命中一个刚被使用块的几率也在下降，这个趋势实验里测很直观。
建议：记录数据时保留原始trace的关键特征，比如访问总数、不同指令占比、访存地址分布区间。这些东西不一定会出现在最终报告里，但分析异常结果时它们是第一手线索。
4. 实验报告里的数据呈现：怎么把结果写得不扣分
实验做完了，数据也拿到了，但报告写不好一样拿不到高分。我见过太多人把实验报告写成了说明书：先是实验目的复制粘贴，然后截图一堆仿真波形，最后一段“通过本次实验我了解了Cache的工作原理”草草结束。这种报告的问题在于，它只展示了“我做了”，没有展示“我理解了”。
4.1 数据记录的三条原则
实验指导书不会明说，但报告质量高不高的分水岭在于数据处理是否经得起追问。我后来总结出三条数据记录原则：
第一，每次改一个变量。比如对比块大小的影响时，容量、相联度、替换策略都保持不变，只改块大小。这样才能把命中率的变化因果归因到单一因素上。很多报告里的图表之所以被老师质疑，就是因为两三个变量同时变，根本看不出趋势是什么造成的。
第二，数据要记录原始值和推导值两层。原始值是模拟器直接输出的缺失次数、访问总次数；推导值是算出来的缺失率、命中率，以及在不同参数组合下的变化比例。导师问得最多的问题之一就是“这个数据是怎么来的”，如果报告里只写了命中率没有写访问总次数和缺失次数，基本一问一个准。
第三，对于反常识的数据，保留中间过程。比如我某次测试中发现，容量增加一倍但命中率几乎没变，一开始以为实验做错了。后来检查trace发现，是测试程序的工作集本身大于增倍后的容量，所以容量提升没有跨过工作集这个阈值。这个分析过程如果写进报告，比你堆十个图表都说明问题。
4.2 问题分析部分最忌“我以为”
实验报告里的“数据分析”不是把表格贴上去再加一句“命中率随容量增大而升高”就结束了。合格的写法是讲清楚趋势背后的机制。
我之前在Cache实验报告里写过一段让老师明确给加分的内容：分析直接映射与4路组相联的差异时，我补充了一个冲突缺失的实例，说明同一个组的两个地址块反复争抢同一个缓存行，导致命中率骤降。做法是在trace里挑出这些冲突地址对，展示它们被映射到同一个组，再结合程序循环周期，解释为什么每轮循环都会重复缺失。这种分析能把“相联度高所以命中率高”这种正确但没说透的话，变成一个具体的场景推演。
写问题分析时，我建议每张图下配2~3句结构化的解读：这个图变量是什么、趋势是什么、趋势的原因是什么。不要写“由下图可知”这种废话导语，直接进入信息本身。
4.3 心得部分的加分写法
实验心得是报告里最容易被写成流水账的部分，但其实也是最灵活的。我在最后会写两类内容：一是“本次实验里卡住最久的点”，二是“如果把实验条件改一改会怎样”。
卡住最久的点要写得具体。比如我在单周期CPU实验里被beq指令的分支地址计算卡了大半天，这个经历写出来就是很好的心得素材，因为它体现的是排查逻辑，而不是一句“遇到问题后我查阅了资料”。
“如果把条件改一改会怎样”这类内容则是展示思考深度的机会。比如Cache实验中，我写出了“如果改用LRU替换策略，miss率大概会下降多少、为什么”。哪怕不做实验，基于已有数据做一个定性推演，也比只说“我掌握了”强很多。
5. 复盘：时间分配、常用命令和后续扩展
计算机系统结构实验是一类“下限低、上限高”的课。想混过去很容易，模拟器上点两下截图就交差了；想真正搞懂也很花时间，因为每个实验背后都连着体系结构的核心问题。最后分享几个我复盘时觉得最有价值的经验。
5.1 时间分配建议
单周期CPU、流水线、Cache这几个大实验，我的时间分配比例大概是：理解要求占10%，搭建环境占20%，核心实现占40%，调试占20%，报告写作占10%。很多人把时间全砸在实现和调试上，最后只剩一个晚上写报告，写出来的内容自然苍白。
合理的做法是做到一半就开始记录“我为什么这样做、遇到了什么问题、是怎么解决的”。这些记录稍加整理就是实验报告里最好的素材。我后来建了一个简单的实验日志，每半小时记一条进展或疑问，虽然看起来多花了几分钟，但写报告时几乎不用回忆细节，效率反而更高。
5.2 可以继续深挖的方向
如果一个学期下来，你对系统结构的兴趣被这些实验勾起来了，后面有几个方向值得深入：
一是流水线实验，在单周期基础上加入IF/ID、ID/EX、EX/MEM、MEM/WB四级寄存器，处理数据冒险和控制冒险。 二是分支预测，在流水线里加入静态预测和动态预测的对比分析。 三是多级Cache实验，把一级Cache缺失后访问二级Cache的延迟和带宽因素加入模拟，考察不同层次缺失惩罚对总体性能的影响。 四是直接在真实机器上测性能计数器，比如用开发板跑一段循环程序，再通过硬件计数器观察真实的Cache miss和分支预测失败数据，和模拟器结果做对照。
这几个方向本质上都是同一个思路：把“系统结构概念”变成“可测量的行为”，再用行为数据去验证或者挑战书上写的理论。这也是我做完整套实验之后，最大的一个感受。
最后再分享一个小技巧：做完每个实验后，把自己写的代码或配置备份到一个单独的目录，并附一份README说明实验目的、关键参数和运行命令。这活儿看着不起眼，但当期末要综合对比多个实验、或者面试时想展示项目经历，这些记录就是最直接的材料。计算机系统结构实验的价值不只在分数上，你花在这些实验里的时间，会在后面学操作系统、编译原理甚至做性能优化时连本带利地还回来。
本文还有配套的精品资源，点击获取
