Files

Moe Charm 11506cee3b Phase 11-12: LLVM backend initial, semantics layer, plugin unification

Major changes:
- LLVM backend initial implementation (compiler.rs, llvm mode)
- Semantics layer integration in interpreter (operators.rs)
- Phase 12 plugin architecture revision (3-layer system)
- Builtin box removal preparation
- MIR instruction set documentation (26→Core-15 migration)
- Cross-backend testing infrastructure
- Await/nowait syntax support

New features:
- LLVM AOT compilation support (--backend llvm)
- Semantics layer for interpreter→VM flow
- Tri-backend smoke tests
- Plugin-only registry mode

Bug fixes:
- Interpreter plugin box arithmetic operations
- Branch test returns incorrect values

Documentation:
- Phase 12 README.md updated with new plugin architecture
- Removed obsolete NYIR proposals
- Added LLVM test programs documentation

Co-Authored-By: Claude <noreply@anthropic.com>

2025-09-01 23:44:34 +09:00

3.3 KiB

Raw Blame History

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. 明確な設計文書の重要性

# VM設計方針
VMはMIR命令の意味論を定義する参照実装である。
他のバックエンド（JIT/AOT/LLVM）は、VMの実装を
仕様書として参照し、同じ動作を保証する。

2. 新しい概念の説明方法

既存の概念との違いを明確に
具体例を用いた説明
図解の活用

3. 定期的な認識合わせ

実装前のレビュー
設計意図の再確認
AIパートナーからのフィードバック

改善策：Semanticsトレイトの導入

最終的に、ChatGPT5との議論を経て、Semanticsトレイトという形で設計意図を明確化：

// MIR解釈の統一インターフェース
trait Semantics {
    type Val;
    fn interpret_instruction(&mut self, inst: &MirInstruction) -> Self::Val;
}

これにより、各バックエンドが同じ意味論に従うことが保証される。

後日談：LLVMからCraneliftへの戦略的転換（2025-09-01）

転換の経緯

LLVM統合の試み → 巨大、ビルド困難、環境依存地獄
問題認識 → 「ユーザーにこの苦労をさせられない」
既存資産の再評価 → Phase 10.7のCranelift実装に立ち返る

# LLVM: 100MB+、環境構築1日、ビルド数時間
# Cranelift: 5-10MB、cargo add一発、ビルド数分
# → 明らかにCraneliftが実用的！

AI協調開発の真の教訓

新しいものに飛びつく前に既存資産を評価
「大きい・複雑」なものに遭遇したら立ち止まる
方向転換は敗北ではなく賢明な判断

3.3 KiB Raw Blame History Unescape Escape