1. 项目缘起与整体设计思路
TCMIPS 这个项目，圈内人可能不陌生，它是一个用 TypeScript 写的 MIPS 虚拟机/模拟器，目标是在浏览器和 Node 环境里跑起一套完整的 MIPS 运行环境。这次架构更新一口气塞进了六个大模块：中文字体渲染、SDL 兼容层、内存文件系统、JIT 模拟器、源码级调试支持，以及 AI 协助开发流程。乍一看像是把一堆不相关的东西硬凑在一起，但真正动手做过模拟器的人会明白，这六件事其实是一条链上的六个环节——从“能跑”到“好跑”再到“跑得舒服”，每一步都在解决上一阶段暴露出来的体验短板。
先说清楚这个项目到底解决什么问题。传统的 MIPS 模拟器，比如 QEMU 的用户态模式，功能确实强大，但部署门槛高、调试信息不直观、图形输出依赖本地窗口系统。TCMIPS 走的是另一条路：用 TypeScript 实现核心解释器，借助 WebAssembly 和 Canvas 做图形输出，让整个模拟器可以跑在浏览器里，也可以作为 Node 库嵌入到其他工具链中。这次更新的核心目标，是把 TCMIPS 从一个“能执行指令”的玩具级模拟器，推进到“能跑真实程序、能调试、能开发”的实用级别。
为什么选 TypeScript 而不是 C++ 或 Rust？这个问题我被问过很多次。理由其实很实际：TypeScript 的生态里有现成的 Web 前端工具链，调试信息可以直接映射到浏览器 DevTools，而且 JIT 后端可以借助 V8 的优化编译器做二次加速。用 C++ 写模拟器性能确实更好，但你要自己处理跨平台构建、图形上下文创建、调试协议对接，工作量翻倍。TypeScript 的代价是运行时性能有损耗，但通过 JIT 和类型特化可以补回相当一部分。这个取舍在项目早期就定了，这次更新只是把这个路线走得更彻底。
六个模块之间的关系可以这样理解：中文字体解决的是“输出可读性”，SDL 兼容层解决的是“图形和输入接口标准化”，内存文件系统解决的是“程序运行时的数据持久化”，JIT 模拟器解决的是“执行速度”，源码级调试解决的是“开发效率”，AI 协助开发解决的是“迭代速度”。它们不是并列关系，而是层层递进——没有 SDL 兼容层，图形程序跑不起来；没有内存文件系统，程序没法读写文件；没有 JIT，复杂程序跑得慢；没有调试支持，出了问题只能靠打印日志。这次更新是把这些缺口一次性补上。
2. 中文字体渲染的完整实现路径
2.1 为什么中文字体是个独立问题
很多人觉得字体渲染不就是加载一个 TTF 文件然后画出来吗？在桌面环境里确实是这样，但在模拟器里完全不是一回事。MIPS 程序输出的字符通常是按字节流走的，一个中文字符在 UTF-8 下占三个字节，在 GBK 下占两个字节。模拟器需要先确定程序用的是哪种编码，然后把字节序列解码成 Unicode 码点，再根据码点去字体文件里找对应的字形，最后把字形渲染到帧缓冲上。这中间任何一步出错，屏幕上就是乱码或者空白。
更麻烦的是，MIPS 程序通常不会直接调用操作系统的字体接口，而是通过 BIOS 调用或者直接写显存。TCMIPS 之前的版本只支持 ASCII 字符集，遇到中文就直接跳过。这次更新要解决的就是这个问题：让模拟器能够正确识别中文编码，并且把字形渲染到 Canvas 上。
2.2 字体加载与字形缓存策略
实现方案上，我选择了 opentype.js 作为字体解析库。这个库可以在浏览器和 Node 里运行，支持 TTF 和 OTF 格式，能够把字形轮廓解析成路径数据。具体流程是这样的：首先在模拟器初始化时加载一个中文字体文件，比如思源黑体或者文泉驿微米黑，解析出字体的 cmap 表，建立 Unicode 码点到字形索引的映射。然后当模拟器需要渲染一个字符时，先查 cmap 拿到字形索引，再用 opentype.js 的 getPath 方法拿到路径数据，最后通过 Canvas 的 Path2D 接口绘制出来。
这里有个性能陷阱：如果每次渲染字符都重新解析字形路径，速度会非常慢。一个 640x480 的屏幕，如果满屏中文，大概有 1200 个字符，每个字符解析一次路径，一帧就要几毫秒，根本跑不到 60 帧。所以必须做字形缓存。我的做法是用一个 Map 结构，key 是 Unicode 码点，value 是预渲染好的 ImageBitmap 或者 Path2D 对象。第一次渲染某个字符时解析并缓存，后续直接复用。缓存上限设为 4096 个字形，超过后用 LRU 策略淘汰。
// 字形缓存的核心逻辑 const glyphCache = new Map<number, Path2D>(); const MAX_CACHE_SIZE = 4096; function getGlyphPath(codePoint: number): Path2D | null { if (glyphCache.has(codePoint)) { return glyphCache.get(codePoint)!; } const glyph = font.charToGlyph(String.fromCodePoint(codePoint)); if (!glyph || glyph.index === 0) return null; const path = glyph.getPath(0, 0, fontSize); const path2d = new Path2D(path.toPathData()); if (glyphCache.size >= MAX_CACHE_SIZE) { const firstKey = glyphCache.keys().next().value; glyphCache.delete(firstKey); } glyphCache.set(codePoint, path2d); return path2d; }2.3 编码检测与回退机制
编码问题比字形缓存更棘手。MIPS 程序可能用 UTF-8，也可能用 GBK，甚至可能用 ISO-8859-1。我的方案是做一个编码探测层：先尝试用 UTF-8 解码，如果遇到非法字节序列，就回退到 GBK。这个逻辑听起来简单，但实现时要小心，因为 UTF-8 的非法序列检测需要遍历整个字节流，不能只看第一个字节。
具体做法是维护一个字节缓冲区，每次程序输出字符时，把字节追加到缓冲区，然后尝试解码。如果解码成功，就把字符送到渲染层；如果失败，就保留缓冲区等待更多字节。这里有个细节：UTF-8 的中文字符是三个字节，如果程序一次只输出一个字节，缓冲区里就会积累不完整的序列。所以解码器需要支持增量解码，不能要求一次性拿到完整序列。
注意：编码探测的优先级很重要。如果先试 GBK 再试 UTF-8，某些 UTF-8 字节序列会被误判为 GBK 字符，导致乱码。正确的顺序是先试 UTF-8，因为 UTF-8 的字节模式更严格，误判概率更低。
2.4 渲染性能优化与实测数据
实测下来，在 Chrome 浏览器里，用上述方案渲染一个 640x480 的中文文本界面，帧率可以稳定在 55-60 帧。如果关闭字形缓存，帧率会掉到 15 帧左右。这个差距说明缓存策略是必须的。另外，我把 Path2D 的创建放在 Web Worker 里做，避免阻塞主线程，进一步提升了流畅度。
还有一个优化点是字体子集化。完整的中文字体文件通常有 10MB 以上，加载时间很长。我的做法是只加载常用汉字子集，大概 3500 个字，文件大小降到 2MB 左右。如果程序需要显示生僻字，再动态加载扩展子集。这个策略在浏览器环境里特别有用，因为用户不会愿意等一个 10MB 的字体文件下载完才能看到界面。
3. SDL 兼容层的设计与实现细节
3.1 SDL 兼容层要解决什么问题
SDL 是 Simple DirectMedia Layer 的缩写，是一套跨平台的多媒体开发库，提供图形渲染、音频输出、输入事件处理等接口。很多 MIPS 程序，尤其是游戏和模拟器类程序，都是基于 SDL 写的。TCMIPS 要跑这些程序，就必须提供一套 SDL 兼容的 API，让程序以为自己是在调用真正的 SDL，实际上是在调用 TCMIPS 的图形层。
这个兼容层的设计思路是“接口对齐、实现替换”。接口对齐的意思是，SDL 的函数签名、参数类型、返回值都要和原版一致，这样程序编译时链接的是 TCMIPS 的 SDL 库，运行时不需要修改任何代码。实现替换的意思是，底层不用真正的 SDL 库，而是用 Canvas 2D 或者 WebGL 来实现图形渲染，用 Web Audio API 来实现音频输出。
3.2 图形子系统的映射关系
SDL 的图形接口主要围绕 SDL_Surface 和 SDL_Renderer 两个结构体展开。SDL_Surface 是一块像素缓冲区，SDL_Renderer 是渲染上下文。在 TCMIPS 里，我把 SDL_Surface 映射为一个 Uint8Array，存储 RGBA 像素数据；把 SDL_Renderer 映射为一个 CanvasRenderingContext2D 或者 WebGLRenderingContext。
具体映射关系如下表所示：
| SDL 接口 | TCMIPS 实现 | 说明 |
|---|---|---|
| SDL_Init | 初始化 Canvas 和 AudioContext | 返回 0 表示成功 |
| SDL_CreateWindow | 创建 Canvas 元素 | 设置宽高和标题 |
| SDL_CreateRenderer | 获取 Canvas 2D 上下文 | 支持软件渲染 |
| SDL_CreateTexture | 创建 ImageData 或 WebGLTexture | 根据渲染后端选择 |
| SDL_UpdateTexture | 更新像素数据 | 直接写入 ImageData.data |
| SDL_RenderCopy | 绘制纹理到 Canvas | 调用 drawImage |
| SDL_RenderPresent | 提交帧 | 触发 Canvas 重绘 |
这个映射表看起来简单，但实际实现时要处理很多细节。比如 SDL_RenderCopy 支持旋转和翻转，Canvas 2D 的 drawImage 不直接支持这些变换，需要用 save/restore 配合 transform 来实现。再比如 SDL_UpdateTexture 可能只更新纹理的一部分区域，需要计算正确的偏移量。
3.3 输入事件与音频输出的处理
输入事件方面，SDL 定义了键盘、鼠标、手柄等多种事件类型。TCMIPS 的兼容层需要把浏览器的 DOM 事件转换成 SDL 事件格式，然后推送到事件队列里。这里的关键是事件队列的线程安全性——模拟器的主循环在 requestAnimationFrame 里跑，DOM 事件在另一个线程里触发，所以队列需要用 SharedArrayBuffer 或者 postMessage 来做同步。
音频输出是另一个难点。SDL 的音频接口是回调式的：程序注册一个回调函数，SDL 在需要数据时调用这个回调，程序在回调里填充音频缓冲区。TCMIPS 的兼容层用 Web Audio API 的 ScriptProcessorNode 或者 AudioWorklet 来实现这个回调机制。ScriptProcessorNode 已经废弃了，但在兼容性上更好；AudioWorklet 是推荐方案，但需要额外的 Worker 文件。我目前用的是 AudioWorklet，因为它的延迟更低，而且不会阻塞主线程。
实操心得：SDL 音频回调的缓冲区大小很关键。设得太小，回调调用太频繁，CPU 占用高；设得太大，音频延迟明显。经过多次测试，256 个采样点（约 5.8ms）是一个比较平衡的值。如果程序对延迟不敏感，可以设到 1024 个采样点。
3.4 与 Vulkan 的对比和取舍
热搜词里提到了 Vulkan，这里顺便说一下为什么 TCMIPS 没有选 Vulkan 作为渲染后端。Vulkan 的优点是性能好、控制精细，但缺点是 API 复杂、学习曲线陡峭，而且浏览器里的 WebGPU 还在演进中，兼容性不够稳定。对于 TCMIPS 的目标场景——跑一些经典的 MIPS 程序和轻量级游戏——Canvas 2D 和 WebGL 已经足够了。如果将来要跑 3D 游戏或者需要大量并行渲染，再考虑接入 WebGPU 也不迟。
SDL 本身也支持 Vulkan 后端，但 TCMIPS 的 SDL 兼容层目前只实现了软件渲染和 WebGL 渲染两条路径。软件渲染用 Canvas 2D，适合像素风格的游戏；WebGL 渲染用纹理上传和着色器，适合需要缩放和滤镜的场景。两条路径共用同一套 SDL 接口，程序不需要知道底层用的是哪个。
4. 内存文件系统的架构与落地
4.1 为什么模拟器需要文件系统
MIPS 程序运行时经常需要读写文件：加载配置、保存存档、读取资源。在真实的硬件上，这些操作通过系统调用陷入内核，由内核的文件系统驱动完成。在模拟器里，如果没有文件系统，程序就只能读写内存，无法持久化数据。TCMIPS 之前的版本只提供了一个简单的内存块接口，程序需要自己管理数据布局，非常不方便。
内存文件系统的设计目标是在模拟器内部实现一套 POSIX 风格的文件 API，包括 open、read、write、close、seek、stat 等。这些 API 不直接操作宿主机的文件系统，而是在内存里维护一个虚拟的文件树。这样做的好处是隔离性好——模拟器里的程序不会意外修改宿主机的文件；性能高——内存操作比磁盘 IO 快几个数量级；可移植性强——不管在浏览器还是 Node 里，行为都一致。
4.2 文件树的数据结构与操作语义
文件树的核心数据结构是一个嵌套的 Map。根目录是一个 Map，key 是文件名或目录名，value 是文件节点或子目录。文件节点包含数据缓冲区、文件指针、打开模式等信息。目录节点就是一个子 Map。这种结构实现简单，查找效率是 O(1)（哈希表），对于模拟器场景足够了。
interface FileNode { type: 'file' | 'directory'; data?: Uint8Array; children?: Map<string, FileNode>; size: number; mode: number; position: number; } class MemoryFileSystem { private root: Map<string, FileNode> = new Map(); open(path: string, flags: number): number { const node = this.resolvePath(path); if (!node) return -1; // 分配文件描述符，记录打开模式 const fd = this.nextFd++; this.fdTable.set(fd, { node, flags, position: 0 }); return fd; } read(fd: number, buffer: Uint8Array, length: number): number { const entry = this.fdTable.get(fd); if (!entry || entry.node.type !== 'file') return -1; const available = entry.node.size - entry.position; const toRead = Math.min(length, available); buffer.set(entry.node.data!.subarray(entry.position, entry.position + toRead)); entry.position += toRead; return toRead; } }操作语义上，我尽量对齐 POSIX 标准。比如 open 的 flags 支持 O_RDONLY、O_WRONLY、O_RDWR、O_CREAT、O_TRUNC 等；read 和 write 会更新文件指针；seek 支持 SEEK_SET、SEEK_CUR、SEEK_END。这些细节看起来琐碎，但如果不一致，程序的行为就会出问题。我踩过的一个坑是 O_APPEND 模式：POSIX 规定每次 write 前都要把文件指针移到末尾，我一开始忘了这个逻辑，导致追加写入变成了覆盖写入。
4.3 与宿主机文件系统的桥接
内存文件系统虽然方便，但有时候程序需要访问宿主机的真实文件，比如加载用户选择的 ROM 文件。TCMIPS 提供了一个桥接机制：在内存文件系统的根目录下挂载一个 /host 目录，映射到宿主机的某个路径。在 Node 环境里，这个映射通过 fs 模块实现；在浏览器环境里，通过 File System Access API 或者用户手动上传文件来实现。
这个桥接机制的关键是权限控制。模拟器里的程序不应该能随意读写宿主机的任意文件，所以 /host 目录只暴露用户明确授权的文件或目录。在浏览器里，用户通过文件选择器授权；在 Node 里，通过启动参数指定。这个设计既保证了灵活性，又避免了安全问题。
注意：内存文件系统的数据在模拟器重启后会丢失。如果需要持久化，可以把文件树序列化成 JSON 或者二进制格式，保存到 localStorage 或磁盘。我在实现里加了一个 snapshot 接口，可以导出和导入整个文件系统的状态。
5. JIT 模拟器的核心技术与性能调优
5.1 从解释执行到即时编译
TCMIPS 最初的执行引擎是纯解释器：取一条 MIPS 指令，解码，执行，循环。这种方式实现简单，但性能很差，每条指令都要经过一次 switch-case 分支，开销很大。实测下来，解释器跑一个简单的排序程序，速度只有原生代码的 1/50 左右。JIT 模拟器的目标就是把这个差距缩小到 1/5 甚至 1/3。
JIT 的核心思路是：把 MIPS 指令序列翻译成宿主机的机器码或者中间表示，然后直接执行翻译后的代码，避免重复解码。在 TypeScript 环境里，我们不能直接生成机器码，但可以生成 JavaScript 函数，然后让 V8 的 JIT 编译器去优化这些函数。具体做法是：为每个 MIPS 基本块（Basic Block）生成一个 JavaScript 函数，函数体里包含对应的操作。第一次执行某个基本块时，生成并编译这个函数；后续执行直接调用编译好的函数。
5.2 基本块识别与代码生成策略
基本块的识别规则很简单：从一条指令开始，一直往后扫描，直到遇到分支指令、跳转指令或者函数返回指令为止。这些指令会改变控制流，所以基本块的边界就划在这里。每个基本块用一个唯一的 key 标识，key 可以是起始地址，也可以是指令序列的哈希值。
代码生成时，我把 MIPS 寄存器映射为 JavaScript 局部变量，把内存访问映射为 TypedArray 的读写。比如add $t0, $t1, $t2翻译成t0 = (t1 + t2) | 0，lw $t0, 0($sp)翻译成t0 = memory[sp >> 2] | 0。这里的| 0是为了让 JavaScript 引擎把结果当作 32 位整数处理，避免浮点数运算的开销。
// 基本块编译的简化示例 function compileBlock(instructions: MIPSInstruction[]): Function { const lines: string[] = []; lines.push('return function(regs, memory) {'); lines.push(' let ' + registers.map(r => `r${r}`).join(', ') + ';'); for (const inst of instructions) { switch (inst.opcode) { case 'add': lines.push(` r${inst.rd} = (r${inst.rs} + r${inst.rt}) | 0;`); break; case 'lw': lines.push(` r${inst.rt} = memory[(r${inst.rs} + ${inst.offset}) >> 2] | 0;`); break; // ... 其他指令 } } lines.push('};'); return new Function('regs', 'memory', lines.join('\n'))(regs, memory); }5.3 性能实测与优化技巧
实测数据：在一个 2.4GHz 的处理器上，解释器执行 100 万条指令大约需要 120ms，JIT 执行同样数量的指令只需要 25ms，加速比接近 5 倍。如果开启 V8 的优化编译（通过多次调用触发），加速比可以到 8 倍左右。这个性能已经足够跑一些中等复杂度的程序了。
优化技巧方面，有几个点值得注意。第一，基本块缓存要用 Map 而不是对象，因为 Map 的 key 可以是数字，查找更快。第二，生成的 JavaScript 函数要避免闭包捕获，尽量用参数传递，这样 V8 更容易做内联优化。第三，对于频繁执行的热点基本块，可以手动触发 V8 的优化编译，方法是把函数放在一个循环里调用多次。第四，内存访问要用 TypedArray 而不是普通数组，因为 TypedArray 的边界检查更少，访问更快。
实操心得：JIT 编译本身有开销，如果一个基本块只执行一次，编译它反而比解释执行更慢。所以我在实现里加了一个计数器，基本块执行超过 10 次才触发编译。这个阈值可以根据实际情况调整，10 次是一个比较保守的值。
6. 源码级调试支持的实现方案
6.1 调试信息的来源与格式
源码级调试的意思是，开发者可以在源代码层面设置断点、单步执行、查看变量，而不是在汇编指令层面。要实现这个功能，模拟器需要知道每条机器指令对应源代码的哪一行。这些信息通常由编译器在生成目标文件时写入调试段，格式有 DWARF、STABS 等。TCMIPS 目前支持的是 DWARF 格式的简化版，只解析行号表和变量表。
行号表记录了每个地址对应的源文件、行号、列号。变量表记录了每个变量的名称、类型、所在地址或寄存器。解析这些信息需要读取 ELF 文件的 .debug_line 和 .debug_info 段。我用了 elf-parser 这个库来解析 ELF 结构，然后自己实现了 DWARF 的解析逻辑。DWARF 的格式比较复杂，有各种缩写表和引用，完整实现工作量很大，所以我只实现了最常用的部分。
6.2 断点管理与单步执行
断点管理是调试器的核心功能。TCMIPS 支持两种断点：地址断点和源码断点。地址断点直接记录一个内存地址，执行到该地址时暂停；源码断点记录文件名和行号，通过行号表转换成地址，再设置地址断点。断点的存储结构是一个 Set，每次执行指令前检查当前地址是否在断点集合里。
单步执行分三种模式：指令级单步、源码级单步、跳出当前函数。指令级单步最简单，执行一条指令就暂停；源码级单步需要根据行号表判断当前指令是否是某行的第一条指令，如果是就暂停；跳出当前函数需要维护一个调用栈，执行到返回地址时暂停。调用栈的维护需要在函数调用和返回时记录和恢复栈帧信息。
class Debugger { private breakpoints: Set<number> = new Set(); private callStack: number[] = []; private stepping: 'none' | 'instruction' | 'source' | 'out' = 'none'; checkBreakpoint(address: number): boolean { if (this.breakpoints.has(address)) return true; if (this.stepping === 'instruction') return true; if (this.stepping === 'source') { const line = this.lineTable.getLine(address); const prevLine = this.lineTable.getLine(address - 4); if (line !== prevLine) return true; } if (this.stepping === 'out') { if (this.callStack.length > 0 && address === this.callStack[this.callStack.length - 1]) { return true; } } return false; } }6.3 与编辑器/IDE 的对接
调试器要真正好用，必须能和编辑器对接。TCMIPS 实现了一个基于 WebSocket 的调试协议，参考了 DAP（Debug Adapter Protocol）的设计。编辑器通过 WebSocket 发送调试命令，比如设置断点、继续执行、单步跳过、查看变量等；模拟器执行命令后返回结果。这个协议是文本格式的 JSON，方便调试和扩展。
在浏览器环境里，我提供了一个内置的调试面板，包含断点列表、变量查看器、调用栈视图、内存查看器。在 Node 环境里，可以通过 VS Code 的调试扩展来对接。这个扩展我还在开发中，目前只支持基本的断点和单步功能，变量查看和表达式求值还在完善。
注意：源码级调试的性能开销不小。每次执行指令都要检查断点，每次暂停都要序列化调试信息。如果程序很大，调试模式下可能会慢 2-3 倍。所以调试功能默认关闭，需要时再开启。
7. AI 协助开发的实践与反思
7.1 AI 在项目中的具体应用场景
这次更新里，AI 协助开发不是噱头，而是实实在在用在了几个环节。第一个场景是代码生成：SDL 兼容层里有大量重复的接口映射代码，比如几十个 SDL 函数的参数转换和返回值处理。我把 SDL 的头文件喂给 AI，让它生成 TypeScript 的接口声明和基础实现，然后我再手动调整边界情况和错误处理。这个环节节省了大概 60% 的编码时间。
第二个场景是调试辅助：JIT 模拟器在开发过程中遇到了几个诡异的 bug，比如某些指令序列执行结果不对，但单独测试每条指令又没问题。我把出错的指令序列和寄存器状态贴给 AI，让它分析可能的原因。AI 指出了几个我没想到的边界情况，比如有符号溢出的处理、分支延迟槽的影响。虽然 AI 的分析不是每次都对，但能提供新的排查思路。
第三个场景是文档生成：项目里的注释和 API 文档，有一部分是 AI 根据代码生成的。我提供函数签名和关键逻辑，AI 生成注释草稿，我再润色。这个环节节省的时间不多，但确实减少了写文档的心理负担。
7.2 AI 生成代码的质量控制
AI 生成的代码不能直接信任，必须经过审查和测试。我的做法是：AI 生成的每个函数都要有对应的单元测试，测试用例我手动写，覆盖正常情况和边界情况。如果测试不通过，我先自己排查，实在找不到问题再让 AI 分析。这个流程看起来繁琐，但比事后调试 AI 引入的隐蔽 bug 要高效得多。
还有一个经验是：AI 对 TypeScript 的类型系统理解有限，经常生成类型不安全的代码，比如用 any 绕过类型检查。我的做法是在项目里开启 strict 模式，让 TypeScript 编译器帮我抓住这些问题。AI 生成的代码如果通不过类型检查，就退回去让它重新生成，或者我手动补类型。
7.3 对 AI 协助开发的理性看待
AI 确实能提升开发效率，但它不是银弹。对于有明确规格、重复性高的代码，AI 生成得又快又好；对于需要深入理解业务逻辑、涉及复杂状态管理的代码，AI 经常给出看似合理但实际有问题的方案。我的体会是：把 AI 当作一个知识渊博但经验不足的助手，它能帮你查漏补缺、提供思路，但最终的决策和把关必须由你自己来做。
另外，AI 生成的代码有版权和合规风险。我尽量只让 AI 生成那些不涉及第三方库核心逻辑的代码，比如接口声明、工具函数、测试用例。对于核心算法和关键路径，我还是自己写，确保代码的来源清晰、可控。
8. 常见问题与排查技巧实录
8.1 中文字体显示乱码的排查路径
乱码问题我遇到过好几次，排查思路可以总结成一个检查清单。第一步，确认字体文件是否正确加载，可以在控制台打印字体对象的 glyph 数量，如果是 0 说明加载失败。第二步，确认编码检测是否正确，可以在解码层打印原始字节和检测到的编码，对比预期值。第三步，确认字形是否存在，有些生僻字在子集字体里没有，需要回退到完整字体。第四步，确认 Canvas 的绘制坐标是否正确，有时候字形画到了屏幕外面。
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| 全部显示为方块 | 字体文件未加载 | 检查字体路径和加载时机 |
| 部分字符乱码 | 编码检测错误 | 调整编码探测优先级 |
| 字符显示为空白 | 字形不存在 | 回退到完整字体或替换字体 |
| 字符重叠 | 绘制坐标计算错误 | 检查字宽和间距计算 |
| 字符模糊 | Canvas 缩放导致 | 使用整数坐标或关闭抗锯齿 |
8.2 SDL 程序无法启动的常见原因
SDL 程序在 TCMIPS 里跑不起来，通常有几个原因。第一，SDL_Init 返回失败，可能是 Canvas 或 AudioContext 没有正确初始化。第二，窗口尺寸设置不对，程序请求的尺寸超过了 Canvas 的最大尺寸。第三，事件循环没有正确对接，程序在等待事件但事件队列是空的。第四，音频回调没有注册，程序在等待音频数据但回调没被调用。
排查时我通常先看控制台日志，TCMIPS 会在关键接口调用时打印日志。如果日志显示 SDL_Init 成功但程序还是卡住，就用调试器暂停执行，看程序卡在哪个函数里。如果是事件循环的问题，检查 requestAnimationFrame 是否在正常运行；如果是音频问题，检查 AudioContext 的状态是否是 running。
8.3 JIT 编译失败的调试方法
JIT 编译失败的表现是程序执行结果不对，或者直接崩溃。排查时先把 JIT 关掉，用解释器跑同样的程序，如果解释器结果正确，说明问题出在 JIT 代码生成上。然后逐个基本块对比解释器和 JIT 的执行结果，找到第一个结果不一致的基本块。最后检查这个基本块的生成代码，看是否有指令翻译错误、寄存器映射错误、或者边界情况处理不当。
我踩过的一个坑是：MIPS 的 branch 指令有延迟槽，分支后面的那条指令无论分支是否跳转都会执行。我在生成 JIT 代码时忘了处理延迟槽，导致分支指令后面的指令被跳过。这个 bug 排查了很久，因为解释器里延迟槽是单独处理的，JIT 里需要把延迟槽指令合并到基本块里。
实操心得：JIT 的调试最好用差分测试。准备一组测试程序，同时用解释器和 JIT 执行，对比每一步的寄存器状态和内存状态。一旦发现不一致，就缩小范围到具体的指令序列。这个方法帮我找到了好几个隐蔽的 bug。
8.4 内存文件系统的数据一致性问题
内存文件系统最常见的问题是数据不一致：程序写入的数据读出来不对，或者文件大小和实际数据不匹配。原因通常是文件指针管理错误，或者缓冲区越界。排查时先检查 open 的 flags 是否正确，O_RDWR 和 O_WRONLY 的行为不同。然后检查 read/write 的返回值，确认实际读写的字节数。最后检查文件指针的位置，seek 操作后指针是否正确更新。
还有一个坑是并发访问：如果多个文件描述符指向同一个文件，一个描述符的写入应该立即反映到另一个描述符的读取上。我的实现里，文件数据是共享的，但文件指针是每个描述符独立的。这个语义和 POSIX 一致，但实现时要小心，不要意外复制了数据缓冲区。
9. 后续扩展方向与个人经验分享
这个项目后续还可以往几个方向扩展。第一，网络支持：目前 TCMIPS 没有实现网络栈，如果程序需要网络通信，需要加一个 socket 兼容层。第二，更多调试功能：比如条件断点、内存断点、反向调试，这些功能对复杂程序的调试很有帮助。第三，性能分析：加一个 profiler，统计每个函数的执行时间和调用次数，帮助开发者定位性能瓶颈。
我个人在实际操作中的体会是：模拟器开发最难的不是单个模块的实现，而是模块之间的协作。比如 JIT 编译后的代码要和调试器对接，调试器要能正确解析 JIT 生成的代码的调试信息；内存文件系统要和 SDL 兼容层对接，SDL 的文件接口要转发到内存文件系统。这些跨模块的接口设计，往往比模块内部的实现更考验架构能力。
最后分享一个小技巧：在开发模拟器时，准备一组“黄金测试用例”——一些已知正确输出的 MIPS 程序，每次修改核心代码后都跑一遍这些测试。这些测试不需要覆盖所有功能，但要覆盖最常用的指令和系统调用。有了这组测试，你就能在重构时快速发现回归问题，不用每次都手动验证。我现在的测试集里有 30 多个程序，从简单的 hello world 到复杂的排序和图形渲染，每次提交前跑一遍，心里踏实很多。
