摘要

RISC-V 汇编入门往往同时涉及指令格式、寄存器、立即数、存储器和程序计数器。静态课件能够解释语法，却难以展示一条指令执行前后机器状态的变化。我们围绕这一问题开发了 RISC-V 指令可视化教学软件，让学习者通过积木拼接指令，同步查看汇编文本，并在单步执行中观察 PC、寄存器和存储器变化。本文记录项目的教学思路、功能闭环、OpenHarmony 设备端适配方向，以及我在团队协作中的实际收获。

关键词：RISC-V、OpenHarmony、计算机组成原理、可视化教学、指令模拟器

一、为什么想做一个“能操作”的汇编课堂

第一次接触 RISC-V 汇编时，我最明显的感受不是某条指令特别难，而是很多概念同时出现：rd、rs1、rs2 分别表示什么，立即数为什么放在这个位置，lw 和 sw 的操作数顺序为什么不同，执行一条指令后 PC 又去了哪里。

课本和课件适合解释规则，但学习者很难从静态页面中直接看到“读取—计算—写回”的过程。于是团队提出一个比较朴素的想法：能不能让学生先把指令拼出来，再观察它怎样执行？

我们的目标不是用积木取代标准汇编，而是建立一座桥：

指令积木 → 结构化指令 → 标准汇编 → 模拟执行 → 机器状态变化

图1　项目工作台实测界面。左侧是按算术、逻辑、移位、访存、分支、跳转和复合分类的指令积木，中间是指令编辑区，右侧是机器状态与教学辅助栏。

从真实界面可以看出，我们没有只做一张演示效果图：工作台已经包含指令编辑、执行控制、速度调节、撤销、保存、导入、进度和机器状态等可操作模块。右上角的“OH·RV2”标识用于提示当前适配方向，但是否在真机运行仍需结合后文的设备照片和启动日志判断。

二、把指令格式做成“有约束的积木”

项目把指令主体和操作数分开。大积木表示 add、addi、lw、sw、beq、jal 等指令，小积木表示寄存器、立即数和标签。

槽位并不是随意填入的。例如：

• addi rd, rs1, imm 需要目标寄存器、源寄存器和立即数；
• lw rd, imm(rs1) 需要目标寄存器、偏移量和基址寄存器；
• sw rs2, imm(rs1) 写入的是 rs2，它与 lw 的字段含义并不相同。

学习者完成拼接后，系统同步生成标准汇编文本。这样做有两个好处：一是减少初学阶段因字段顺序造成的低级错误，二是让积木界面始终与真实指令格式对应，不形成一套脱离 RISC-V 的“教学专用语法”。

图2　实际生成的 ADDI x1, x0, #8 指令积木。三个槽位依次对应目标寄存器、源寄存器和立即数。

三、让寄存器、存储器和 PC 的变化真正可见

程序构造完成后，可以单步执行或连续运行。界面显示 PC、32 个整数寄存器和教学抽象存储器，被修改的单元会高亮。

以真实截图中的 addi x1, x0, 8 为例：

1. 读取 x0，其值恒为 0；
2. 与立即数 8 相加；
3. 把结果 8 写回 x1；
4. PC 前进到下一条指令。

系统还支持十进制、十六进制和二进制显示，便于讲解位运算、移位和无符号比较。对学生来说，0 → 8 如果只是一串数字，意义仍然有限；写成“寄存器 x1：0 → 8”“PC：0 → 1”，执行结果就清楚得多。

图3　单步执行第一条指令后的真实状态：辅助栏显示 x0=0 + imm=8 ⇒ x1=8，寄存器 x1 从 0 变为 8，PC 从 0 前进到 1。

需要说明的是，当前模拟器强调指令语义和机器状态变化，不是完整 CPU 流水线仿真器。我们更关心一条指令读了什么、计算了什么、最后改了什么。

四、为什么又把它搬到 OpenHarmony 设备端

项目早期形成了 Web/Windows 演示版本。为了让教学软件能够在 RISC-V 开发板和教学屏上运行，团队又建立了 OpenHarmony Stage 模型工程。

OpenHarmony 版本没有在短周期内重写全部 ArkUI 交互，而是采用 ArkTS 外壳，通过 ArkWeb 加载打包在 rawfile 中的本地教学页面。这样能够复用既有的解析器、模拟器和交互逻辑，同时继续处理设备端资源加载、触控输入和屏幕布局。

团队后续在香橙派 RV2 上完成了签名 HAP 的安装与启动验证，并围绕触摸拖拽、1080p 教学屏布局和 ArkWeb 稳定性进行了调整。

图4　教学屏与测试板卡环境中的实际运行画面。屏幕中可见完整工作台和“OH·RV2·模拟执行”标识；右侧可见测试板卡及连线。照片中的系统时钟未同步，右下角的 2000/1/1 不代表拍摄日期。

这张照片能够证明项目界面已经显示在实际设备环境中，但不能单独证明真实 GPIO 已接入，因此本文仍将当前硬件反馈准确表述为“模拟执行”。

五、项目做到了什么，没有做到什么

技术文章最容易出现的问题，是把阶段性原型写成“全面完成”。在整理项目材料时，我们给自己划了几条边界：

• 香橙派 RV2 是运行和验证平台，不是团队自主研发的硬件；
• 当前 GPIO、LED 是软件模拟反馈，不能写成已经接入真实 GPIO 外设；
• OpenHarmony 版本采用 ArkTS + ArkWeb，不是完整 ArkUI 原生重写；
• 尚未完成的分布式设备协同，不写成已经实现；
• 没有统计过的数据，不虚构用户数、课程覆盖人数和下载量。

六、下一步计划

接下来计划从四个方向继续完善：

1. 增加适合课堂使用的指令案例；
2. 完善 OpenHarmony 原生文件保存和导入接口；
3. 整理香橙派 RV2 的公开复现步骤；
4. 通过 Issue 和文章评论收集真实复现反馈。

对初学者来说，最有价值的也许不是一次性演示，而是一套能够自己运行、修改和验证的实验材料。

项目链接

• 团队完整开发仓库：https://github.com/cu616/Riscv-Visual-Teaching
• OpenHarmony 公开复现仓库：https://atomgit.com/txydc/openharmony-riscv-teaching
• 个人学习笔记：https://github.com/flora1131/openharmony-riscv-learning-notes