逆向工程 1980 年代的 Spacelab 電腦：在太空梭上飛行的法製 16 位元電腦與 32 位元 ALU 設計
righto.com (Ken Shirriff) · 2026-05-24
Ken Shirriff 最新的逆向工程文章鎖定 Mitra 125 MS，這是 CIMSA 為歐洲太空計畫製造的軍規 16 位元迷你電腦，曾作為 Spacelab 實驗室的控制電腦隨太空梭飛行。與現代系統不同，它的「16 位元處理器」不是單一晶片，而是由數塊 PCB 上的離散 IC 組合而成。
意外的 32 位元 ALU
逆向工程過程中最令人意外的發現是：這台名義上的 16 位元電腦，其 ALU 架構實際上是 32 位元的。工程師選擇擴充位元寬度，以提升乘法運算與 32 位元浮點計算的效能。ALU 核心由八顆 54S181 軍規 ALU 晶片組成（每顆處理四個位元），配合多工器（MUX）從八種不同輸入組合中選擇，整個 ALU 子系統橫跨三塊 PCB，共使用約 75 顆積體電路。
架構設計包含三個 32 位元暫存器（其中兩個功能為移位暫存器），以及快速進位傳播（carry-lookahead）晶片。第三個暫存器僅用於接續算術操作，不直接暴露給一般指令。
逆向方法與 PCB 特徵
Shirriff 使用三用電表連通性測試（beep out），逐一追蹤 IC 之間以及連接器到連接器的走線，再以 KiCad 繪製實體佈局圖，最後轉換為邏輯符號圖以便閱讀。
PCBs 展現典型軍規特徵：均勻間距的圓孔格（有別於消費級 PCB 的不規則佈線）、垂直散熱片、以及 96 針鍵式連接器（防止方向錯誤插入）。這些設計在太空任務的振動與溫度環境下提供更高的機械可靠性。
原始來源：righto.com
PHP 的兩個設計怪癖：陣列作為有序字典的洩漏抽象，以及「未初始化」與 null 的分裂型別狀態
flowtwo.io · 2026-05-24
一篇來自有五年 PHP 開發經驗的工程師的觀察文章，聚焦於兩個在 PHP 成熟版本中仍存在的語言設計問題，這兩個問題都曾在實際專案中引發難以察覺的 bug。
陣列作為有序鍵值字典的漏洞
PHP 的陣列在底層是有序鍵值字典，而非傳統意義的連續陣列。關鍵問題出現在變異操作：array_filter() 過濾後保留原始鍵名，unset($arr[0]) 刪除後留下鍵名空缺。
$fruits = ["apples", "oranges", "limes"];
$filtered = array_filter($fruits, fn($f) => $f === "limes");
// $filtered = [2 => "limes"]
// 存取 $filtered[0] → Undefined array key 0解法是呼叫 array_values() 重建連續索引，但這個步驟需要開發者記住這個反直覺的行為，稍有疏忽就會在迴圈或 JSON 輸出時埋下 bug。
型別化屬性的三態問題
PHP 引入型別化屬性後，屬性出現了「未初始化」這個與 null 不同的獨立狀態，造成防禦性檢查邏輯複雜化：
- 未型別化屬性：預設為
null（舊行為） - 型別化屬性（如
public string $x）：建構後為「未初始化」，存取時拋出 Fatal Error - Nullable 型別屬性（
public ?string $x）：同樣為「未初始化」，非null
is_null()、isset()、property_exists() 三個函式對這三種狀態的行為各不相同且難以預測。作者建議 PHP 應讓 nullable 屬性預設初始化為 null，並要求非 nullable 屬性使用建構子提升（constructor promotion）或預設值——使型別系統的承諾與執行期行為一致。
原始來源：flowtwo.io
--dangerously-skip-reading-code：當 LLM 生成速度超越人類審查能力，工程紀律應該向哪裡移動？
olano.dev · 2026-05-24
這篇文章提出一個思想實驗：如果 LLM 生成程式碼的速度已讓人類逐行審查不再可行，組織是否應該正式宣告「停止讓開發者閱讀 LLM 生成的程式碼」，就像我們不再閱讀編譯器的組合語言輸出一樣？
Amdahl's Law 視角
作者援引 Amdahl's Law 分析這個問題：即使程式碼生成速度提升 100 倍，如果其他環節（審查、測試、部署）沒有同步加速，整體效率瓶頸只是轉移而不是消除。讓開發者「每天生成兩萬行程式碼」同時讓其他人審查，只是在製造新的積壓，而非提升產出。
紀律應向規格與測試移動
作者的核心主張是：工程嚴謹性不是消失，而是轉移到更上游。具體來說：
- 標準化 Markdown 規格（spec）成為知識的最小單位，開發者對規格負責，而非對程式碼實作負責
- 自動化驗證確保程式碼符合規格並通過測試，取代人工逐行審查
- 採納「重工幾乎免費」的哲學，允許基於更清晰的規格重新生成，而非修補難以理解的舊程式碼
這個轉變要求組織層面的協調：必須是「整個組織的規定」而非個別工程師的決定。當只有部分人閱讀 LLM 程式碼、部分人不閱讀時，組織實際上是在接受隨機品質保證。
原始來源：olano.dev