背景

本文探討將 C 語言作為編譯目標（Compilation Target）的實務心得，作者 wingolog 分享了他在開發編譯器時，如何透過靜態內聯函數、避免隱式轉型、封裝原始指標以及手動暫存器分配等技巧，來提升生成程式碼的抽象化程度與效能。這引發了 Hacker News 社群對於 C 語言作為中間語言（IR）的優劣、記憶體管理挑戰以及與 Rust 等現代語言對比的深度討論。

社群觀點

社群對於「為何不直接生成 Rust」展開了激烈的辯論。部分討論者指出，Rust 的生命週期（Lifetimes）要求開發者提供明確的記憶體權屬資訊，這對於從不具備生命週期概念的原始語言進行轉譯時，會造成極大的技術障礙。雖然有觀點認為可以透過生成「不安全 Rust」（Unsafe Rust）來規避，但這反而抵消了 Rust 的安全優勢，且 C 語言在內聯函數與編譯器內建指令（Intrinsics）的支援上依然更為成熟。更有評論者幽默地指出，若要追求極致安全，難道要為了生成 Rust 而先用 Rust 寫一個編譯器？這反映出 C 語言作為「通用組合語言」的地位在短期內仍難以動搖。

在技術細節上，社群對垃圾回收（GC）的實作表現出高度關注。許多開發者認同 C 語言在處理精確 GC 時非常棘手，因為 C 的棧幀（Stack Frame）與編譯器優化往往會隱藏指標，導致掃描困難。常見的解決方案是維護一個影子棧（Shadow Stack），但這會帶來額外的寫入開銷並增加除錯難度。此外，關於 static inline 的使用也存在爭議。雖然它能消除抽象成本，但對於需要進行外部語言綁定（FFI）的開發者來說，這些函數在編譯後的二進位檔中並不具備符號，導致其他語言難以直接呼叫，這被視為 C 語言生態中對跨語言協作不夠友好的體現。

另一部分的討論聚焦於 C 語言的優化邊界。有經驗的開發者提醒，過度依賴內聯函數有時會觸碰編譯器的優化障礙，例如浮點數運算的收縮（Contraction）在跨越語句邊界時可能失效，進而影響效能。同時，針對 musttail 屬性的討論顯示，雖然開發者渴望可靠的尾遞迴優化，但主流編譯器在不同平台上的支援程度不一，這使得手動管理跳轉與暫存器分配在高效能編譯器開發中依然是必要的「惡」。

延伸閱讀

• C-- (C-minus-minus)：專為編譯器設計的類 C 中間語言，旨在提供比 C 更精確的底層控制。
• Lobster 程式語言：其實作了「借用優先」（Borrow-first）語義，成功在不具備 Rust 複雜性的前提下減少了引用計數的開銷。
• CompCert C / C0：具備正式語義定義的 C 語言子集，適合用於對安全性要求極高的生成目標。
• Virgil 程式語言：由討論者 titzer 開發，展示了從編譯到 C 轉向自研後端的演進歷程。