修复基于VMEBus的处理器接口机箱

一位知名的喜剧演员曾经创造了这句流行用语──“我很不喜欢这种感觉！”(I hate it when that happens!!!)。我其实完全能够了解那种感受。每一次当我不得不去破解、调试或改善“别人的设计”(Someone Else's Design；SED)时，我相信自己都说了这句话。

有一天，我的老板给了我一个任务，要我去弄清楚一个基于VMEBus的处理器接口机箱究竟是哪里出错了。由于这是在1990年代那个桌上型电脑独大的“黑暗时代”(Dark Ages)，这个接口机箱中有一款摩托罗拉68010微处理器，并采用汇编语言(而非C语言、JAVA或HTML)进行编码。我们所做的事就是将两个6RU机架高、以线绕连接且基于7400逻辑电路的客制化接口机箱置入一个5RU高的VMEBus盒中，并使其维持与两个HP1000 Fast Fortran处理器的连接。

这个接口机箱表面平滑：前方的触控面板用于执行处理器的状态显示，并显示从接口所记录到的数据信息等。但这个接口机箱原本面临的问题十分吊诡──想想，你如何能将10磅的东西放在只能装5磅的袋子里？从封装、布线、后面板的连接器、电源以及冷却器看来都很正常。但问题是，为了尽量地节省机架空间等，设计者采用了超越其能力所及的汇编语言进行编码。

原来的接口仅建置了‘L’模式。新的VMEBus设计则同时建置‘L’和‘S’模式，使复杂度增加了4倍。在‘L’模式下，每125微秒从144bit的数据框架下提取DF和NV位元，使L模式成功地完成建置。

然而，'S'模式是一种新的编码方式。这种模式则是每四个193位元、125ms提供一个DF和NV位元。测试此模式后发现无法顺利运作。我怀疑问题就出在以汇编语言编码的逻辑电路设置。我后来打了几次电话询问才知道当初的设计者已经离职了，现在已经没人可回答有关他所设计的任何问题。

我只好开始研究汇编语言代码，发现设计者对于所做的一切都进行了完整的建档操作。但有关汇编语言所要解决的最大难题通常都跟“子程序”(subroutine)语言有关。如果你看到布满'JSR'和'RTS'的代码，你可就很难追踪到逻辑建置了。很快地你就会发现，子程序读取操作也需要利用一些CPU周期来执行。而这就是在编写汇编语言时用于进行控制的关键参数。而处理中断服务程序(ISR)就更棘手了，因为只要外部中断一发生，ISR即随时启动执行。

最后我终于发现，大部分用于寻找DF和NV的逻辑是透过ISR内部所执行的，每512微秒执行两次ISR操作。现在我几乎就要解决这个问题了。我找到了Motorola Assembler手册，然后开始增加执行ISR所需的CPU指令周期，接着就发现其中一个ISR无法在下一次中断发生前完成指令操作，因而不断地耗用CPU堆栈中的暂存器，直至存储器耗尽后死机。

实际动手进行修复并不简单。我花了一个多月的时间重新建置ISR，使ISR内部仅执行关键的指令集，并建立了一个可立即储存中间计算值的方式，以便使这些值也可用于ISR外部。

这些修改终于完成且经测试过了，而这款接口机箱在那之后还用了好多年。我自己也对这一点成绩感到相当自豪。