简介面向天津大学计算机科学与技术专业19级学生的《计算机系统基础》上机实验合集覆盖位操作、整数与浮点数、拆弹专家、代码注入攻击、高速缓存五大主题可作为课程实验、期末复习与考研面试准备参考资料。包内按实验分目录整理共35个文件整体约112.48MB其中以14份PDF实验指导/报告、6份C源码、4份DOC报告为主同时保留bomb、hex2raw、ctarget、rtarget及ASM汇编等可执行与底层文件并有TXT说明与PNG截图辅助还原实验环境。已有919人学习下载。资源既提供实验要求、思路和提交版报告也保留了可运行的实验代码与二进制文件便于对照理解补码与IEEE 754浮点表示、缓冲区溢出触发与防御、缓存替换策略和一致性协议等核心概念。适合正在上这门课、需要完成上机作业或准备计算机系统相关考核的本科生系统复习与实战演练。1. 计算机系统基础实验上机别等期末才翻车计算机系统基础实验和普通编程课实验完全不同——它不是让你写出一个能跑的功能而是让你在底层把程序“扒光”位级运算、反汇编、缓存命中率每一关都在挑战你以为“写 C 就行了”的惯性。这套某高校的《计算机系统基础》上机资源包包含实验指导书、原始 handout 代码、评测脚本和一份完整的上机记录覆盖 Data Lab、Bomb Lab、Cache Lab 等经典实验。适合三类人准备上机的在校生、想补 ICS 短板的转行开发者、以及凡是遇到位运算和调试就头疼的 C 语言选手。别等期末周才打开它先按下面的流程跑一遍你在评测系统上能少返工很多次。2. 实验包结构与上机环境先把工具链对齐2.1 资源包路径与文件清单拿到资源包第一步不是解压跑代码而是先看目录结构。这类实验包通常不是“一个文件夹放到底”而是每个 Lab 一个独立 handout 目录评分脚本按目录找文件。常见做法是解压后看到这样的布局路径内容用途docs/各实验指导书与评分规则先读别跳src/datalab-handout/Data Lab 的 bits.c、Makefile、dlc位运算上机src/bomb-handout/bomb 二进制、bomb.c、答案模板反汇编与调试src/cachelab-handout/csim、test-trans、trans.c缓存模拟与矩阵转置tools/driver.pl、评分脚本、环境检测脚本统一评测入口notes/上机记录、踩坑笔记、GDB 速查参考思路不是答案我一般会先花十分钟把docs/里的 README 和评分规则读完确认每个 Lab 的 Makefile 默认编译器、优化级别和提交物是什么。这个动作能省掉后面一大半“本地过了评测却挂了”的破事。2.2 上机环境gcc、gdb、make、multilib资源包里的实验多数在 Linux 下跑Windows 直接编译会遇到一堆路径和权限的坑。常见做法是 Ubuntu 虚拟机或容器装齐编译调试三件套再解压sudo apt update sudo apt install -y gcc gdb make perl gcc-multilib libc6-dev-i386 tar xzf cs-lab.tar.gz cd src/datalab-handout make clean make这条命令里最容易忽略的是gcc-multilib和libc6-dev-i386。Data Lab 和 Bomb Lab 的 Makefile 默认带-m32也就是编译成 32 位程序缺了 multilib 会在链接时报crt1.o: No such file之类的错。gdb是 Bomb Lab 的主力工具perl是因为评分脚本 driver.pl 用 Perl 写的没装的话脚本直接起不来。装完之后可以验证一下 32 位编译是否可用echo int main(){return 0;} | gcc -m32 -x c - -o /tmp/t /tmp/t; echo $?输出0就说明 32 位工具链没问题。这一步很关键很多人的实验卡在“make 报错”而不是“代码写错”。2.3 三种评测脚本的打开方式每个 Lab 的验收入口不一样先记住这三个命令后面每一章都围绕它们展开# Data Lab规则检查 功能评分 ./dlc -e bits.c ./driver.pl # Bomb Lab把答案写进文件一次跑完六个阶段 ./bomb ans.txt # Cache Lab跑矩阵转置并统计 miss ./test-trans -M 64 -N 64参数含义后面章节细说这里只要建立印象dlc管“运算符合不合法”driver.pl管“功能对不对”test-trans管“缓存命中率达标没有”。三个脚本的输出格式完全不同但有一个共同点——它们都是在你自己的机器上跑不代表评测机的结果。2.4 不要乱改 Makefile这是最容易翻车的地方。Data Lab 的 Makefile 里 CFLAGS 通常是-O1 -m32 -Wall -marchi586有人觉得优化级别太低改成-O2结果位运算题的边界行为在更高优化下表现不一致本地测试通过率反而下降。更危险的是自己往bits.c里加头文件或宏dlc 检查器会对陌生符号直接报非法。遇到 Bonus 题先看 Makefile 里有没有EXTRA_CREDIT或BONUS开关有的话按注释打开而不是自己造宏。评测脚本认的是官方入口而不是“你觉得更好的编译方式”。3. Data Lab 实战位运算约束与解题套路3.1 Data Lab 在考什么规则比代码更先定成败Data Lab 表面上考“用位运算实现某个函数”实际上考的是对补码、浮点数位模式的理解以及能不能在严格约束下表达逻辑。题目分两类一类是整数题比如bitXor、isTmax、logicalShift另一类是浮点题比如floatScale2、floatFloat2Int。整数题限制最狠只能用! ~ ^ | 这些运算符不能用if/for/while/?:不能用大于0xff的常量每道题还有最大运算符数量限制。常见误区是把它当普通编程题写先写一个能跑的函数再回来“凑”运算符。正确顺序是反过来的先看规则再想这个规则下能用什么表达。比如判断相等不能用但! (x ^ y)可以取负数-x不能用但(~x) 1可以。dlc 检查器会逐个函数扫描一旦出现非法运算符直接不通过所以写代码的过程其实是“在约束里推理”的过程。3.2 用 bitXor 建立位运算直觉bitXor要求只用~和实现异或最大 8 个运算符。很多人第一反应是无从下手因为直觉里异或要有|参与。但异或可以拆成“两个集合的并再排除交集”/* * bitXor - x^y using only ~ and * Example: bitXor(4, 5) 1 * Legal ops: ~ * Max ops: 8 */ int bitXor(int x, int y) { return ~(~x ~y) ~(x y); }逻辑说明x ~y表示“x 有而 y 没有的位”~x y表示“y 有而 x 没有的位”这两部分的并集就是异或结果。但因为不能用|所以用德摩根定律把或转成与非a | b等于~(~a ~b)。代入后就是上面这个式子。运算符数量两个~、三个加上外层~和共 7 个满足 8 的限制。这道题的价值不在于“实现异或”而在于让你接受一个事实任何布尔表达式都能只用~和表达。后面所有整数题都可以往这个方向想。3.3 isTmax边界条件比主逻辑更致命isTmax判断x是否为0x7fffffff允许的运算符比 bitXor 多但陷阱在于0xffffffff也满足很多“看起来只有 TMax 才满足”的性质。我的思路是利用“x 1等于~x”这个性质再排除掉0xffffffff/* * isTmax - returns 1 if x is the maximum signed int, and 0 otherwise * Legal ops: ! ~ ^ | * Max ops: 10 */ int isTmax(int x) { int t x 1; return !(~(x ^ t)) !!(~x); }逻辑说明如果x是0x7fffffff那么x 1等于0x80000000而~x也是0x80000000二者异或为 0!后为 1。但x 0xffffffff时x 1等于 0~x也等于 0同样满足前半句所以要用!!(~x)排除掉它。~x为 0 说明x是全 1不是 TMax。这个“排除项”就是 Data Lab 里最常丢分的地方——主逻辑写对了边界特例没处理。3.4 dlc/driver 双关卡验证写完后不要直接提交按顺序跑# 先查规则再测功能 ./dlc -e bits.c make clean make ./driver.pldlc -e会输出每个函数的运算符数量和是否合法-e参数表示打印每个函数的操作数统计。如果这里报错driver.pl 跑都不用跑。driver.pl会逐题编译运行并打分输出类似bitXor: 2/2的表格。如果某题失败但 dlc 过了说明逻辑边界有问题可以在本地写一个临时 main 调用该函数用 gdb 打断点看返回值逐步缩小范围。有一点要提醒dlc 只查规则不查逻辑driver 只查逻辑不查规则两个都必须过才算稳。提交前养成习惯先make clean再重新编译避免把本地测试时加过 printf 的版本交上去。3.5 float 题先把位模式拆开再分类浮点题允许用if和while但很多人反而挂得更惨因为它要求把 float 当成 32 位模式直接操作。以floatScale2为例输入是unsigned uf实际上是一个 float 的位模式需要返回uf * 2的位模式unsigned floatScale2(unsigned uf) { unsigned sign (uf 31) 1; unsigned exp (uf 23) 0xff; unsigned frac uf 0x7fffff; if (exp 0xff) return uf; // NaN 或 Inf 原样返回 if (exp 0) { frac 1; // 次正规数直接左移尾数 if (frac 0x800000) { // 尾数溢出进位到指数 frac 0x7fffff; exp 1; } return (sign 31) | (exp 23) | frac; } exp 1; // 正常数指数加一 return (sign 31) | (exp 23) | frac; }逻辑说明先按位拆出符号、指数、尾数然后分三类处理。指数全 1 是 NaN/Inf 直接返回指数全 0 是次正规数尾数左移一位溢出时进位正常数直接把指数加 1加满变成 Inf 由位模式天然表示。写 float 题的核心就是“先分类再动手”把uf当成一个结构体来拆而不是当成数值来算。4. Bomb Lab从 objdump 到 GDB 的拆弹路径4.1 反汇编先行objdump 把 bomb 变成可读文本Bomb Lab 给的是一个可执行文件bomb没有源码或者只有一个阉割版 main六个 phase 每个都要输入正确字符串或数字序列输错就爆炸退出。很多人的第一反应是“猜答案”但六个字符串猜中的概率基本为零。正确的路只有一条反汇编。objdump -d -M intel ./bomb bomb.asm grep -n phase_ bomb.asm strings -t x ./bomb | head -50-d是反汇编代码段-M intel指定 Intel 语法而不是默认的 ATT 语法读起来更顺。grep找六个 phase 函数的入口地址strings用来查看程序里的可见字符串比如phase_1可能直接比较输入的字符串和一个藏在 .rodata 里的固定串。这一步做完你至少能判断每个 phase 是“字符串比较”还是“数字运算”。4.2 GDB 下断点让 bomb 把答案“说”出来反汇编文本能告诉你每个 phase 调用了哪些函数、比较了什么寄存器但实际运行时还需要动态确认。GDB 是这里的核心工具gdb ./bomb (gdb) break explode_bomb (gdb) break phase_1 (gdb) run ans.txt (gdb) x/s $rdi (gdb) continuerun ans.txt让 bomb 从文件读答案而不是交互输入方便反复调试。在explode_bomb下断点是保命动作——即使答案错程序也会停在引信处而不是直接退出。在phase_1下断点后x/s $rdi打印第一个参数寄存器指向的字符串。在 x86-64 的 System V 调用约定里第一个参数走rdi所以phase_1(input)的input就在rdi里。这一步能从内存里直接看到当前输入是什么字符串配合反汇编里的比较目标答案基本就出来了。如果函数内部逻辑复杂用si单步执行汇编指令ni跳过函数调用finish执行完当前函数并返回。这三个命令足够应付大多数 phase。4.3 单步跟踪从比较函数回到输入约束phase_2 之后通常不是简单字符串比对了。有的是读一串数字先检查格式再算数列有的是查表映射比如 phase_5 用一个索引数组从字符表里取值。这种题不能只看.rodata要看调用点附近的比较指令。比如反汇编里出现cmp $0x6,%eax说明输入数量必须是 6出现call 401470 sscanfplt说明输入要满足某种%d格式。常见做法是先在phase_5断点用x/20wx 地址查看栈上的数组内容把字符表和索引值打印出来然后手工算出答案。phase_6 如果是链表排序题就用x/30wx把链表节点的 value 和 next 指针列成表按 value 排序后的节点顺序就是答案。整个过程像在解一道带调试器的谜题关键不是“看懂全部汇编”而是“找到输入和比较之间的映射关系”。4.4 答案文件与批量验证拆完六个 phase 后把答案逐行写进ans.txt注意每行一个 phase 的答案结尾必须有换行。批量验证命令很简单./bomb ans.txt如果输出Congratulations!说明全部通过。如果中间爆炸可以用xxd ans.txt检查文件有没有多余空格或特殊字符——bomb用fgets读行多一个空格都可能导致字符串比较失败。我习惯每过一 phase 就把已知答案追加进文件并重新运行而不是等到最后一次性填这样哪里错了能立刻定位。5. 避坑排错环境不一致、规则误判、玄学失败5.1 现象本地 driver 全绿上传评测却是 0原因评测机和你本机的编译环境不一致。最典型的是本机默认编译成 64 位评测机用-m32或者前一次 make 留下了旧的目标文件评测系统重新编译时读到的是缓存产物。解决固定用实验包自带的 Makefile不要手动改 CFLAGS提交前强制make clean删掉所有.o和可执行文件尽量用与评测环境一致的 Ubuntu 版本容器。从此我再也不在 Windows 上跑 Linux 实验一切以容器为准。5.2 现象dlc 报 illegal operator明明用的全是允许符号原因dlc 检查的是“最终提交的 bits.c”不是你自己测试用的临时版本。如果你在本地测试时加了printf、头文件或者用-号dlc 全部判非法。另一个常见原因是bits.c在 Windows 下用记事本编辑过行尾带^Mdlc 解析时把回车当成非法字符。解决所有文件用dos2unix bits.c转一次再提交临时测试代码放进单独的test.c不要污染bits.c。5.3 现象Bomb Lab 用管道喂答案一爆炸就是段错误原因echo 答案 | ./bomb只给程序喂了一行六个 phase 依次读取时第二行直接读到 EOF程序在未初始化状态下继续执行产生段错误。解决用文件重定向./bomb ans.txt保证六个 phase 都有内容读每行答案结尾要有\n不要有多余空格。另外不要在爆炸函数里打断点后继续用continue否则栈帧已经破坏后面的输出不可信。5.4 现象Cache Lab 分块了miss 却比不分块还高原因分块尺寸和缓存参数不匹配。用 16×16 的分块在一个只有 32 组、直接映射的 L1 缓存上块内冲突反而加剧尤其 64×64 矩阵里A[i][j]和B[j][i]的地址在某种分块下会映射到同一组造成连续驱逐。解决先读懂实验说明里给的s/E/b参数再计算一行占几个块、一个分块占几组最后用脚本扫描块大小而不是凭直觉选 8 或 16。5.5 现象提交内容被判定为雷同原因很多人从网上直接找现成答案合并进bits.c评测系统会对比代码特征或者你保留了大量无关注释和调试代码风格和原 handout 差异过大反而被当成异常。解决只用官方 handout 文件在既有函数注释下修改不删原有注释不新增文件提交前用diff和原始 handout 对比确认只改了题目函数体。实验的目的是训练不是“过查重”这一点想清楚能少很多麻烦。6. Cache Lab 调参把矩阵转置的 miss 压到阈值以下6.1 先根据 s/E/b 计算分块尺寸Cache Lab 的转置题会给出固定缓存参数比如s5, E1, b5意思是有 32 组、每组 1 行、每行 32 字节。矩阵是 32×32 时每行 32 个 int 正好占 128 字节也就是 4 个块。这时 8×8 分块是经典起点void transpose_submit(int M, int N, int A[N][M], int B[M][N]) { int i, j, k, t; for (k 0; k N; k 8) for (j 0; j M; j 8) for (i k; i k 8; i) for (t j; t j 8; t) B[t][i] A[i][t]; }逻辑说明8×8 分块让 A 的子块连续读B 的子块按列写但块内 8×8 的跨度正好覆盖一组缓存行的范围减少反复替换。test-trans的-M和-N参数分别指定矩阵的列数和行数跑一次会输出 miss 总数。对照实验说明里的满分阈值如果还差得远就调块大小。6.2 对角线冲突64×64 的隐藏坑同样 8×8 分块放到 64×64 矩阵上会失灵因为A[i][i]块和B[i][i]块的地址在取模后会映射到同一个缓存组形成对角线自冲突。破解办法是把 8×8 再拆成 4×4 的小步或者先把 A 的一行 8 个元素读进局部变量再写 B减少同一组内反复驱逐。这类优化属于“参数玄学”唯一可靠的做法是每次改完都跑一遍test-trans对比 miss 数字而不是靠感觉。6.3 提交前的自检动作提交前我会强制自己做三件事make clean后重新编译确认trans.c里没有测试用的 printf跑一遍官方test-trans并记录 miss用diff对比原始 handout 只保留必要改动。从那以后我每次拿到带评分的优化实验都先跑基础版拿到 baseline再动参数绝不靠感觉直接猜块大小。希望帮到你。本文还有配套的精品资源点击获取