101 lines
3.3 KiB
Markdown
101 lines
3.3 KiB
Markdown
|
# VMのMIR解釈層としての役割が伝わらなかった事例（2025-09-01追記）
|
|||
|
|
|
|||
|
|
## 背景
|
|||
|
|
|
|||
|
|
NyashのVM実装は、元々「MIR解釈の参照実装」として設計されていた。しかし、この意図がAI開発パートナーに正しく伝わらず、結果として同じMIR解釈ロジックが複数回実装される事態となった。
|
|||
|
|
|
|||
|
|
## 何が起きたか
|
|||
|
|
|
|||
|
|
### 開発者の意図
|
|||
|
|
```
|
|||
|
|
VM = MIR解釈層（統一された意味論の実装）
|
|||
|
|
↓
|
|||
|
|
JIT/AOT/LLVMはVMの解釈ロジックを参照して実装
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 実際の実装
|
|||
|
|
```
|
|||
|
|
VM → 独自のMIR解釈実装
|
|||
|
|
JIT → 独自のMIR解釈実装（微妙に異なる）
|
|||
|
|
LLVM → また独自のMIR解釈実装
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## なぜ伝わらなかったか
|
|||
|
|
|
|||
|
|
### 1. 用語の誤解
|
|||
|
|
- 「VM」という名前から「実行専用」と誤解された
|
|||
|
|
- 「MIR解釈層」という抽象的な概念として伝えるべきだった
|
|||
|
|
|
|||
|
|
### 2. 固定観念
|
|||
|
|
- AIパートナーが「各バックエンドは独立実装」という一般的なパターンを前提とした
|
|||
|
|
- VMが参照実装になるという発想が新しすぎた
|
|||
|
|
|
|||
|
|
### 3. コンテキストの不足
|
|||
|
|
- プロジェクト初期の設計意図が文書化されていなかった
|
|||
|
|
- 口頭での説明に依存しすぎた
|
|||
|
|
|
|||
|
|
## 結果として生じた問題
|
|||
|
|
|
|||
|
|
### 1. 重複実装
|
|||
|
|
- 同じロジックを3-4回実装
|
|||
|
|
- 各実装で微妙に動作が異なる
|
|||
|
|
|
|||
|
|
### 2. デバッグの困難
|
|||
|
|
- どの実装が「正しい」のか不明
|
|||
|
|
- バグ修正を全実装に反映する必要
|
|||
|
|
|
|||
|
|
### 3. フォールバック機能の追加
|
|||
|
|
- 実装の違いを吸収するためにフォールバック機能を追加
|
|||
|
|
- さらなる複雑性の増大
|
|||
|
|
|
|||
|
|
## 学んだ教訓
|
|||
|
|
|
|||
|
|
### 1. 明確な設計文書の重要性
|
|||
|
|
```markdown
|
|||
|
|
# VM設計方針
|
|||
|
|
VMはMIR命令の意味論を定義する参照実装である。
|
|||
|
|
他のバックエンド（JIT/AOT/LLVM）は、VMの実装を
|
|||
|
|
仕様書として参照し、同じ動作を保証する。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 2. 新しい概念の説明方法
|
|||
|
|
- 既存の概念との違いを明確に
|
|||
|
|
- 具体例を用いた説明
|
|||
|
|
- 図解の活用
|
|||
|
|
|
|||
|
|
### 3. 定期的な認識合わせ
|
|||
|
|
- 実装前のレビュー
|
|||
|
|
- 設計意図の再確認
|
|||
|
|
- AIパートナーからのフィードバック
|
|||
|
|
|
|||
|
|
## 改善策：Semanticsトレイトの導入
|
|||
|
|
|
|||
|
|
最終的に、ChatGPT5との議論を経て、Semanticsトレイトという形で設計意図を明確化：
|
|||
|
|
|
|||
|
|
```rust
|
|||
|
|
// MIR解釈の統一インターフェース
|
|||
|
|
trait Semantics {
|
|||
|
|
type Val;
|
|||
|
|
fn interpret_instruction(&mut self, inst: &MirInstruction) -> Self::Val;
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
これにより、各バックエンドが同じ意味論に従うことが保証される。
|
|||
|
|
|
|||
|
|
## 後日談：LLVMからCraneliftへの戦略的転換（2025-09-01）
|
|||
|
|
|
|||
|
|
### 転換の経緯
|
|||
|
|
1. **LLVM統合の試み** → 巨大、ビルド困難、環境依存地獄
|
|||
|
|
2. **問題認識** → 「ユーザーにこの苦労をさせられない」
|
|||
|
|
3. **既存資産の再評価** → Phase 10.7のCranelift実装に立ち返る
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
# LLVM: 100MB+、環境構築1日、ビルド数時間
|
|||
|
|
# Cranelift: 5-10MB、cargo add一発、ビルド数分
|
|||
|
|
# → 明らかにCraneliftが実用的！
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### AI協調開発の真の教訓
|
|||
|
|
- 新しいものに飛びつく前に既存資産を評価
|
|||
|
|
- 「大きい・複雑」なものに遭遇したら立ち止まる
|
|||
|
|
- 方向転換は敗北ではなく賢明な判断
|