机器指令翻译成 JavaScript —

上一篇，我们顺利将 6502 指令翻译成 C 代码，并演示了一个案例。

现在，我们来完成最后的目标 —— 转换成 JavaScript。

中间码输出

我们之所以选择 C，就是为了使用 LLVM。现在来看看，生成的 LLVM 中间表示：

不难看出，顺序执行的逻辑都在一个 label 中，跳转则用 br 符号。

这种风格，和我们之前讨论的指令切割非常相似。一个 label 块，正好翻译成一个 block_xxx 的 JS 函数。

所以，理论上翻译成 JS 并不困难，写一个 LLVM backend 插件即可。

现有工具

不过，实际操作起来还是挺麻烦的。

LLVM 中间码和汇编差不多，一步一个操作。如果直接翻译，生成的 JS 会很累赘，类似这样：

$301 = MEM[16];

$302 = $301 + 10;

$303 = ($302 == 0);

if ($303) {

    ...

}

如果能将多步操作合并成一行 JS，则会简洁得多。另外，变量名分配和重用，也是比较麻烦的。

事实上 LLVM 输出成 JS，前辈们早就尝试过了。例如 emscripten，目前已非常成熟。所以，我们不如就用现成的工具吧。

emscripten 是如何处理流程及跳转的？其实和我们之前讨论的切割类似，也是用额外的变量模拟流程。只不过它是用数字变量，而不是函数变量。

例如这样的流程：

a:  xx 1

    goto c

b:  xx 2

    goto a

c:  xx 3

    goto b

生成的 JS 类似这样：

while (1) {

    switch (label) {

    case 1:

        xx 1

        label = 3; continue;

    case 2:

        xx 2

        label = 1; continue;

    case 3:

        xx 3

        label = 2; continue;

    }

}

使用数字，就可以在同个 function 里控制流程，因此更合理一些。

但如果流程复杂，则会陷入众多的判断。哪个方案更好，还得看浏览器的实际优化能力。

线程模型

既然要在浏览器中运行，当然就不能用 sleep 了，取而代之的是 yield。

但 emscripten 生成的代码，显然是不会有 yield 的。因此，我们得手动实现上下文的切换。

我们在切出前，记住当前的流程位置，然后 return；下次调用时，根据上一次的流程位置，跳转到相应的地方继续执行（用上一篇提到的动态表）。

这样，就符合浏览器的线程模型了。

接口交互

之前为了演示，使用新线程 + getchar() 来接受输入，这显然不符合浏览器的模型。

我们得监听键盘事件，在回调中更新相应的内存数据。

不过，emscripten 内置了 SDL 框架（类似于 DirectX），它封装了各种事件处理、图形渲染、音频播放等，非常实用。

SDL 会把消息记录在自己的队列里。任何时候，我们可以通过 Poll 的方式去拉取。这样就避免了回调，也不会有阻塞。

因此最终的模型，就类似这样：

void render() {

    cycle_remain = N;

    input();        // 获取输入

    update();       // 指令逻辑（执行到 cycle_remain <= 0）

    output();       // 屏幕输出

}

// 通过浏览器的 rAF 接口实现

emscripten_set_main_loop(render);

具体可以参考：这个文件。

最终结果

我们将上一篇的「贪吃蛇」编译成 JavaScript，在浏览器中运行：

在线演示（ASDW 控制方向）

由于 emscripten 打包了一些 C 运行时、辅助函数、SDL 框架等各种程序，所以生成的脚本很大，超过 200 KB。事实上 6502 指令对应的 JS 并不多，可以参考下面链接。

回顾下整个翻译过程：

机器码 --> (现有工具) --> 汇编码 --> (小脚本) --> C 代码 --> (emscripten) --> JS 代码

虽然这种方式不是最完美的，但实现起来很简单。

当然，我们的目标并非为了实现 6502 指令，只是借此学习一下「程序流程」相关的知识，以及探索一些开脑洞的想法。