机器指令翻译成 JavaScript —— No.5 指令变化

上一篇,我们通过内置解释器的方案,解决任意跳转的问题。同时,也提到另一个问题:如果指令发生变化,又该如何应对。

指令自改

如果指令加载到 RAM 中,那就和普通数据一样,也是可以随意修改的。然而,对应的 JS 是事先翻译好的,已经不能改了。如果运行时突然变卦,那相应的 JS 就作废了 —— 如果修改的是跳转指令,甚至会影响已划分的流程。所以为了保守起见,指令被改后进入模拟状态。

因此,我们得监控指令区的修改:

function store(addr, val) {
	// 修改指令区
	if (0x0600 <= addr && addr <= ...) {
		...
	}
	MEM[addr] = val
}

将存储操作封装成函数,这样就可在写入时做一些判断。如果修改了指令区的数据,则进入解释模式(甚至永远保持解释模式)。

当然,还可以做一个 JIT 引擎,在运行时翻译。不过很复杂,这里就不考虑了。

对存储进行封装,这也是有必要的。之前为了简化问题,将整个地址空间都当做内存,其实是不严谨的。事实上,内存只是地址空间的一部分而已。其他还有屏幕、键盘,以及各种 ABI,都是通过地址交互的。

所以,读写最终都需要一层封装:

function store(addr, val) {
    ...
    MEM[addr] = val;
}

function load(addr) {
    ...
    return MEM[addr];
}

指令变化

如果不修改指令数据,指令是否也会变化?听起来有些匪夷所思。不过,在那个系统资源极度匮乏的年代,总会有些神奇的东西。

我们在第一篇中提到,地址总线是 16 位,最多只能访问 64K 的空间。这是否意味着,程序最大只能做到 64K?

回顾一下,小时候玩的红白机游戏(当然,那时都用卡带,也看不出游戏有多大)。后来有电脑模拟器,就可以看到 NES 文件的大小了。

事实上超过 64K 的多得是,有些「大型游戏」甚至有好几百 K,例如:

光靠 16 位的地址,是如何访问的?为此,前辈们发明了一种叫 Mapper 的黑科技。它内置在游戏卡带芯片里,对 CPU 是透明的。

Mapper 的种类五花八门,但基本思路差不多:用某些特殊地址,来扩展寻址能力。

假设 0x0000 ~ 0x0fff 空间是给卡带的。若把 0x0fff 这个特殊地址设置成 1,这时访问 0x0005,实际访问到的物理位置是 1 * N + 5;如果设置的是 2,再访问 0x0005,对应的物理位置则是 2 * N + 5。这样,就可突破 64K 的限制了。

相当于把特殊地址,当做类似段寄存器的功能。只不过这是卡带自己搞的一套内部方案,CPU 是毫不知情的。

当然,实际情况比这复杂得多。本系列我们讨论的仅仅是指令翻译,并非要实现一个 NES 环境,所以就不考虑了。

结尾

关于 6502 指令翻译成 JavaScript 的可行性分析,就到此为止。

我们之所以要翻译,而不是纯粹模拟,就是为了尝试追求最高效率。不过,就目前的翻译过程来看,仍存在很多可优化的地方。

下一篇,我们尝试利用现有工具,对逻辑进行深度优化。

posted @ 2016-07-05 20:02  EtherDream  阅读(506)  评论(0编辑  收藏  举报