一位知名的喜劇演員曾經創造了這句流行用語──“我很不喜歡這種感覺！”(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外部。

這些修改終于完成且經測試過了，而這款接口機箱在那之后還用了好多年。我自己也對這一點成績感到相當自豪。