【要約】ChatGPT PlusのProjectsだけでプログラミング言語を作り始めて早8週間 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がC言語をバックエンドとして利用するコンパイラを設計する際、Cの未定義動作（UB）が言語仕様に混入する問題に直面している。Cの仕様に依存することで、以下のような課題が発生する。
- ・Cのsigned integer overflowが、Aneの意図するラップアラウンド挙動と異なる。
- ・Cの演算子をそのまま出力すると、コンパイラの最適化によって予期せぬ動作を招く。
- ・shift countや除算、配列アクセスなどの境界が、CのUBへ直結するリスクがある。
// Approach
開発者は、Aneの言語仕様をCの挙動から独立させ、backendがその境界を守る設計を採用した。具体的には以下の手法を用いている。
- ・固定幅整数の演算（+, -, *, unary -）を、2の補数によるラップアラウンドとして言語仕様に定義。
- ・C backendでは、符号なし演算への変換やヘルパー関数を用い、CのUBを回避して実装。
- ・shift countをビット幅で正規化し、除算やインデックスアクセスはsafe/unsafeの境界を明確化。
- ・ASanやUBSanを用いて、生成されたCコードが仕様通りに動作するかを検証。
// Result
Aneの「safe」な境界が明確になり、CのUBへ直行しない設計基盤が構築された。これにより以下の成果が得られている。
- ・typed IR上で演算を管理することで、backendの実装ミスをUBSanで検知可能になった。
- ・言語仕様とCの挙動を分離し、将来的な自己ホスト化に向けた足場を固めた。
- ・コンパイラの回帰テストや実行時検査の経路を分離し、検証の精度を向上させた。
Senior Engineer Insight
> 低レイヤー言語開発において、バックエンドのUB回避は「実装の作法」ではなく「言語仕様の根幹」である。Cの挙動に依存せず、言語としての意味論を先に定義し、backendにその遵守を強いる設計は極めて堅実だ。特に、sanitizerを「仕様」ではなく「実装の検証手段」と位置づける姿勢は、大規模システムにおける信頼性確保の観点からも高く評価できる。実装の複雑化を許容してでも、言語の境界を厳格に定義する判断は、長期的な保守性と安全性を担保する上で不可欠である。