feat(plugin): Fix plugin BoxRef return and Box argument support
- Fixed deadlock in FileBox plugin copyFrom implementation (single lock) - Added TLV Handle (tag=8) parsing in calls.rs for returned BoxRefs - Improved plugin loader with config path consistency and detailed logging - Fixed loader routing for proper Handle type_id/fini_method_id resolution - Added detailed logging for TLV encoding/decoding in plugin_loader_v2 Test docs/examples/plugin_boxref_return.nyash now works correctly: - cloneSelf() returns FileBox Handle properly - copyFrom(Box) accepts plugin Box arguments - Both FileBox instances close and fini correctly 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Moe Charm
110
docs/development/roadmap/native-plan/MIR仕様書.txt
Normal file
110
docs/development/roadmap/native-plan/MIR仕様書.txt
Normal file
@ -0,0 +1,110 @@
|
||||
やったね！この粒度なら “化け物に伸びる余白” と “実装の現実” のちょうど真ん中。
|
||||
仕上げとして **25命令をキッチリ確定**＋**意味論/効果/検証ルール** を短く固めよう。
|
||||
|
||||
# 決定版 MIR（25命令）
|
||||
|
||||
## Tier-0: 普遍コア（8）
|
||||
|
||||
```
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
* 効果: `Const/Phi`=pure, `BinOp/Compare`=pure, `Branch/Jump/Return`=control, `Call`は呼先の効果に従う
|
||||
* 備考: 将来のJIT/AOT/WASMすべてで必須
|
||||
|
||||
## Tier-1: Nyashセマンティクス（12）
|
||||
|
||||
```
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み
|
||||
BoxFieldStore, // Boxのフィールド書き（= mut）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則の検証付き）
|
||||
WeakNew, // `weak` ハンドル生成（非所有リンクの作成）
|
||||
WeakLoad, // `weak` から生存チェック付きで強参照を得る（失効時null）
|
||||
WeakCheck, // `weak` の生存確認（bool）
|
||||
Send, // Bus送信（Effect=io）
|
||||
Recv // Bus受信（Effect=io）
|
||||
```
|
||||
|
||||
* 効果: `BoxFieldStore/RefSet`=mut, `Send/Recv`=io, 他は基本pure/可変
|
||||
* これで **所有森＋weak/look＋Bus** が言語一次市民として表現可能
|
||||
|
||||
## Tier-2: 実装補助・最適化友好（5）
|
||||
|
||||
```
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列の最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
* 位置づけ: どれも“言語仕様の裏方”。無くても表現可能だが、**性能・安全検査・移植性**が安定する
|
||||
|
||||
---
|
||||
|
||||
## 効果（Effect）既定値
|
||||
|
||||
* `pure`: Const, BinOp, Compare, Phi, WeakCheck, WeakLoad(成功時の取得自体はpure扱い)
|
||||
* `mut`: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
* `io`: Send, Recv, Safepoint(割り込み/分割fini許可点としてio扱い)
|
||||
* `control`: Branch, Jump, Return, TailCall
|
||||
* `context依存`: Call, BoxCall（呼先の効果に従属）
|
||||
|
||||
> 最適化ルールは「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」。
|
||||
|
||||
---
|
||||
|
||||
## 検証（Lint/Verifier）要件（短縮版）
|
||||
|
||||
* **所有森**: `strong in-degree ≤ 1`（`NewBox/Adopt/Release/RefSet`で常時検査）
|
||||
* **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
* **弱/強相互**: 双方向とも強 → エラー（片側は `WeakNew` 経由で弱化）
|
||||
* **RefSetの安全**: 強→強の差し替え時は旧所有元からの `Release` が伴うこと
|
||||
* **WeakLoad/WeakCheck**: 失効時は `null/false` を返す（例外禁止、決定的挙動）
|
||||
* **TailCall**: 末尾位置のみ可（`Return` 直前）
|
||||
* **Send/Recv**: バックエンドが同期/非同期いずれでも**at-least-once**契約を満たすか、契約を明示
|
||||
|
||||
---
|
||||
|
||||
## 代表的ロワリング（例）
|
||||
|
||||
* `look` 参照 → `WeakNew` + `WeakLoad`（読取専用型なら `RefSet` を禁止）
|
||||
* `borrow{}` → ブロック先頭 `WeakNew`、末尾でハンドル破棄（MIR上はNop、型で書換禁止）
|
||||
* Bus最適化（Elision）:
|
||||
|
||||
* `(pure|mut(local))` かつ同一スレッド/アリーナ/単一受信なら **`Send/Recv` → 直呼び/直アクセス** に縮退
|
||||
* `fini` 伝播: ランタイムで **強エッジのみ** 再帰。`Safepoint` で分割解放/優先度解放に対応
|
||||
|
||||
---
|
||||
|
||||
## バックエンド指針（対応表）
|
||||
|
||||
* **Interpreter**: 25命令を素直に実装（正しさの基準）
|
||||
* **VM**: Register-VM + direct-threading。`Send/Recv` はローカル判定時にインライン化
|
||||
* **WASM**: `Send/Recv` は host import。`MemCopy` は `memory.copy` に対応
|
||||
* **Cranelift/JIT**: `TailCall` 最適化、`WeakLoad` は世代タグでO(1)生存チェック
|
||||
* **AOT-Rust**: `BoxCall` を trait 呼び出しへ、`Adopt/Release` は所有者IDの切替 + デバッガ用アサート
|
||||
|
||||
---
|
||||
|
||||
## 互換テスト（常設）
|
||||
|
||||
* **golden MIR**: 各サンプルのMIRダンプが全バックエンドで一致
|
||||
* **行動一致**: `interp/vm/wasm` で**同入力→同出力**（`weak`失効時の`null/false`含む）
|
||||
* **性能スモーク**: `add_loop / map_getset / alloc_free / bus_local / bus_actor` の5種で、
|
||||
|
||||
* VMがinterp以上、WASMがVM以上、を継続検証
|
||||
|
||||
---
|
||||
|
||||
これで **25命令フルセット**が完成。
|
||||
|
||||
* Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を**無理なくIR化**
|
||||
* それぞれのバックエンドに**綺麗に落ちる**
|
||||
* Verifier/最適化/テストも**最小で回る**
|
||||
|
||||
次は、このリストをそのまま `docs/mir.md` にコピペして、各命令に **1行の意味論＋効果＋等価変換の例** を添えれば、実装と論文の両方が一気に前進するにゃ。
|
||||
@ -0,0 +1,211 @@
|
||||
# 🚀 Phase 9.78: LLVM Proof of Concept - AI大会議戦略文書
|
||||
|
||||
## 🎯 **Phase 9.78の位置づけ**
|
||||
|
||||
```
|
||||
Phase 8.6: VM最適化完了 ✅
|
||||
↓
|
||||
Phase 9.78: LLVM PoC (3週間集中) ← 🆕 挿入！
|
||||
├─ ✅ 実現可能 → Phase 9.8(完全版) → Phase 10.2(本格LLVM)
|
||||
└─ ❌ 実現困難 → Phase 9.8(3バックエンド版) → Box統合
|
||||
```
|
||||
|
||||
**戦略的価値**: 不確定要素を3週間で解決し、後続開発の全体最適化を実現
|
||||
|
||||
## 🔍 **現在のMIR分析**
|
||||
|
||||
### **技術基盤状況** ✅
|
||||
```rust
|
||||
// ChatGPT5設計 20-25命令MIR
|
||||
- SSA形式 ✅
|
||||
- 効果追跡 (EffectMask) ✅
|
||||
- Box最適化対応 ✅
|
||||
- 所有権検証システム ✅
|
||||
- 基本ブロック・関数構造 ✅
|
||||
|
||||
主要命令セット:
|
||||
├─ Const, BinOp, UnaryOp, Compare
|
||||
├─ BoxCall, ExternCall (プラグイン連携)
|
||||
├─ RefNew, RefGet, RefSet (参照操作)
|
||||
├─ Branch, Jump, Return (制御フロー)
|
||||
└─ Print, FutureNew, Await (特殊操作)
|
||||
```
|
||||
|
||||
### **LLVM変換の技術的課題** 🤔
|
||||
```
|
||||
1. MIR ValueId → LLVM Value* 対応
|
||||
2. Box型 → LLVM struct表現
|
||||
3. ExternCall → C-ABI関数呼び出し
|
||||
4. 効果追跡 → LLVM属性 (readonly/noalias等)
|
||||
5. 所有権 → LLVM メモリ管理
|
||||
```
|
||||
|
||||
## 🤖 **AI大会議への相談事項**
|
||||
|
||||
### **Gemini先生への技術相談**
|
||||
|
||||
```
|
||||
Nyashプログラミング言語のMIR→LLVM IR変換について技術的相談です。
|
||||
|
||||
【背景】
|
||||
- ChatGPT5設計の20-25命令MIR (SSA形式)
|
||||
- Everything is Box哲学 (全データがBoxオブジェクト)
|
||||
- Arc<Mutex>統一アーキテクチャ
|
||||
- BID-FFIプラグインシステム (C-ABI)
|
||||
|
||||
【MIR主要命令】
|
||||
- Const, BinOp, UnaryOp, Compare
|
||||
- BoxCall (Box.method呼び出し)
|
||||
- ExternCall (プラグイン関数呼び出し)
|
||||
- RefNew, RefGet, RefSet (参照操作)
|
||||
- Branch, Jump, Return (制御フロー)
|
||||
|
||||
【質問】
|
||||
1. MIR→LLVM IR変換の基本戦略は？
|
||||
2. Box型の効率的なLLVM表現は？
|
||||
3. C-ABIプラグイン統合の最適手法は？
|
||||
4. 3週間PoC の現実的スコープは？
|
||||
5. パフォーマンス向上の期待値は？
|
||||
|
||||
Rust実装での実践的なアドバイスをお願いします。
|
||||
```
|
||||
|
||||
### **Codex先生への実装相談**
|
||||
|
||||
```
|
||||
Nyashプログラミング言語のLLVM実装について実装戦略を相談したいです。
|
||||
|
||||
【プロジェクト概要】
|
||||
- 15日間で開発されたプログラミング言語
|
||||
- 4バックエンド対応 (Interpreter/VM/WASM/LLVM)
|
||||
- MIR中間表現 (20-25命令、SSA形式)
|
||||
- プラグインシステム完備
|
||||
|
||||
【実装チームの特徴】
|
||||
- AI協調開発 (Claude/Gemini/ChatGPT/Copilot)
|
||||
- 開発速度重視 (3週間でPoC完成目標)
|
||||
- 実用性優先 (完璧より実装)
|
||||
|
||||
【技術的制約】
|
||||
- Rust実装
|
||||
- LLVM-sys crate使用想定
|
||||
- 既存MIR構造活用
|
||||
- プラグインC-ABI統合必須
|
||||
|
||||
【相談事項】
|
||||
1. 3週間PoC実装の現実的な手順は？
|
||||
2. MIR→LLVM変換の最小実装範囲は？
|
||||
3. Box型をLLVMでどう表現すべきか？
|
||||
4. エラー頻発箇所と対策は？
|
||||
5. デバッグ・テスト戦略は？
|
||||
|
||||
実装経験に基づく現実的なアドバイスをお願いします。
|
||||
```
|
||||
|
||||
## 🛠️ **Copilot依頼文書案**
|
||||
|
||||
### **Phase 9.78: LLVM Proof of Concept実装依頼**
|
||||
|
||||
**目標**: 3週間でNyash MIR→LLVM IR変換の実現可能性を実証
|
||||
|
||||
**成功基準**:
|
||||
- 基本MIR命令(Const, BinOp, Compare, Branch, Return)のLLVM変換
|
||||
- Box型の基本的なLLVM表現実装
|
||||
- Hello World レベルの実行確認
|
||||
- 理論的性能向上の算出 (10倍目標)
|
||||
|
||||
**技術基盤**:
|
||||
```rust
|
||||
// 既存のMIR構造を活用
|
||||
src/mir/instruction.rs // 20-25命令定義
|
||||
src/mir/function.rs // 関数・モジュール構造
|
||||
src/mir/basic_block.rs // 基本ブロック管理
|
||||
|
||||
// 作成予定のLLVM実装
|
||||
src/backend/llvm/
|
||||
├─ compiler.rs // MIR→LLVM変換メイン
|
||||
├─ box_types.rs // Box型のLLVM表現
|
||||
├─ c_abi.rs // プラグインC-ABI統合
|
||||
└─ runtime.rs // ランタイムサポート
|
||||
```
|
||||
|
||||
**実装手順提案**:
|
||||
```
|
||||
Week 1: LLVM基盤構築
|
||||
├─ llvm-sys crate統合
|
||||
├─ 基本的な変換フレームワーク
|
||||
├─ 最小MIR命令 (Const, Return) 変換
|
||||
└─ Hello World レベル動作確認
|
||||
|
||||
Week 2: 主要機能実装
|
||||
├─ 算術演算 (BinOp, UnaryOp, Compare)
|
||||
├─ 制御フロー (Branch, Jump)
|
||||
├─ Box型基本表現
|
||||
└─ 関数呼び出し機構
|
||||
|
||||
Week 3: 統合・検証
|
||||
├─ 既存MIRとの統合テスト
|
||||
├─ 性能ベンチマーク実行
|
||||
├─ 実現可能性評価レポート
|
||||
└─ Phase 10本格実装計画策定
|
||||
```
|
||||
|
||||
**重要な考慮事項**:
|
||||
- 完璧を求めず、実現可能性の実証に集中
|
||||
- 既存のMIR構造を最大活用
|
||||
- エラーハンドリングより基本機能優先
|
||||
- ベンチマークによる定量評価必須
|
||||
|
||||
**期待される成果**:
|
||||
- LLVM実装の技術的実現可能性確認
|
||||
- 性能向上ポテンシャルの定量評価
|
||||
- Phase 9.8 BIDレジストリでのLLVM対応完全版実装可能性判定
|
||||
- Phase 10本格実装の具体的工程表
|
||||
|
||||
## 📊 **成功判定基準**
|
||||
|
||||
### **最低限成功** (実現可能と判定)
|
||||
```
|
||||
✅ 基本MIR命令のLLVM変換動作
|
||||
✅ Box型の基本的LLVM表現実装
|
||||
✅ 簡単なプログラムの実行確認
|
||||
✅ 理論的性能向上の算出
|
||||
```
|
||||
|
||||
### **理想的成功** (本格実装確実)
|
||||
```
|
||||
🌟 全MIR命令対応
|
||||
🌟 プラグインC-ABI統合
|
||||
🌟 実際の性能測定 (2倍以上)
|
||||
🌟 メモリ管理・エラーハンドリング
|
||||
```
|
||||
|
||||
### **失敗判定** (3バックエンドに方針転換)
|
||||
```
|
||||
❌ 基本変換が3週間で実装困難
|
||||
❌ Box型表現が非現実的に複雑
|
||||
❌ 性能向上が期待値を大幅に下回る
|
||||
❌ 技術的負債が実装継続を阻害
|
||||
```
|
||||
|
||||
## 🎉 **次のステップ**
|
||||
|
||||
### **AI大会議実行**
|
||||
1. Gemini先生に技術相談
|
||||
2. Codex先生に実装戦略相談
|
||||
3. 両者のアドバイスを統合
|
||||
4. 最終的なCopilot依頼文書完成
|
||||
|
||||
### **Phase 9.78開始**
|
||||
1. VM最適化完了の確認
|
||||
2. AI大会議結果の反映
|
||||
3. Copilotへの正式依頼
|
||||
4. 3週間集中実装開始
|
||||
|
||||
---
|
||||
|
||||
**作成**: 2025年8月19日
|
||||
**目的**: Phase 9.78 LLVM PoC実装のための戦略文書
|
||||
**次期行動**: AI大会議でさらなる戦略精緻化
|
||||
|
||||
この文書をベースに、Gemini先生とCodex先生に相談し、最強のLLVM実装戦略を策定しましょう！🚀
|
||||
114
docs/development/roadmap/native-plan/README.md
Normal file
114
docs/development/roadmap/native-plan/README.md
Normal file
@ -0,0 +1,114 @@
|
||||
# 🚀 Nyash ネイティブビルド計画（Native Plan）
|
||||
|
||||
## 🎯 目的
|
||||
開発者向けに「ビルド計画・段階的タスク・設計上の要点」を集約。
|
||||
利用者向けの具体的なビルド手順は docs/説明書/native-build/README.md を参照。
|
||||
|
||||
## 📋 重要リンク
|
||||
- **現在のタスク**: [docs/CURRENT_TASK.md](../../CURRENT_TASK.md)
|
||||
- **コア概念（速習）**: [docs/nyash_core_concepts.md](../../nyash_core_concepts.md)
|
||||
- **🤖 AI大会議記録**: [../ai_conference_native_compilation_20250814.md](../ai_conference_native_compilation_20250814.md)
|
||||
- **🗺️ ネイティブコンパイル戦略**: [../native-compilation-roadmap.md](../native-compilation-roadmap.md)
|
||||
- **フェーズ課題一覧**: [issues/](issues/)
|
||||
- **🤖 Copilot協調**: [copilot_issues.txt](copilot_issues.txt)
|
||||
|
||||
## 🌟 **最新戦略 (2025-08-14 AI大会議策定)**
|
||||
|
||||
### ⚡ ネイティブコンパイル革命計画
|
||||
**現状**: WASM 13.5倍実行高速化達成 → **目標**: 500-1000倍総合高速化
|
||||
|
||||
#### **Phase A: AOT WASM** (最優先 - 2-3週間)
|
||||
```bash
|
||||
nyash --compile-native program.nyash -o program.exe
|
||||
```
|
||||
- **技術**: wasmtime compile でネイティブ化
|
||||
- **効果**: 13.5倍 → 100倍 (7倍追加向上)
|
||||
|
||||
#### **Phase B: Cranelift Direct** (中期 - 2-3ヶ月)
|
||||
```
|
||||
Pipeline: MIR → Cranelift IR → ネイティブバイナリ
|
||||
```
|
||||
- **技術**: エスケープ解析・ボックス化解除
|
||||
- **効果**: 100倍 → 200倍
|
||||
|
||||
#### **Phase C: LLVM Ultimate** (長期 - 6ヶ月+)
|
||||
```
|
||||
Pipeline: MIR → LLVM IR → 最適化ネイティブ
|
||||
```
|
||||
- **技術**: LTO・PGO・高度最適化
|
||||
- **効果**: 200倍 → 500-1000倍
|
||||
|
||||
### 🔑 成功の鍵 (3AI一致見解)
|
||||
1. **MIR最適化**: ボックス化解除がバックエンド差より圧倒的効果
|
||||
2. **エスケープ解析**: スタック割り当て・型特殊化
|
||||
3. **段階的検証**: 各Phaseでベンチマーク駆動開発
|
||||
|
||||
要点サマリ（統合）
|
||||
- ビルド方針
|
||||
- デフォルトは CLI 最小構成（`cargo build --bin nyash`）。GUI/Examples は feature で任意有効化。
|
||||
- Windows ネイティブ: MSVC または WSL + cargo-xwin によるクロスコンパイルを推奨。
|
||||
- MIR/VM の段階的導入
|
||||
- Phase 5.2: `static box Main` → MIR への lowering 経路を実装済み。
|
||||
- Phase 6: 参照/弱参照の最小命令（RefNew/RefGet/RefSet, WeakNew/WeakLoad, BarrierRead/Write=no-op）。
|
||||
- 例外/Async は薄く導入、先に snapshot/verify の安定化を優先。
|
||||
- 弱参照の意味論（実装で壊れにくく）
|
||||
- WeakLoad は Option<Ref> を返す（生存時 Some、消滅時 None）。PURE 扱い（必要に応じ READS_HEAP）。
|
||||
- `fini()` 後の使用禁止・weak 自動 null・cascading 順序（weak はスキップ）を不変として扱う。
|
||||
- Safepoint と Barrier
|
||||
- 関数入口・ループ先頭・呼出直後に safepoint。Barrier は最初は no-op 命令として実装可。
|
||||
- テスト戦略
|
||||
- 黄金テスト：ソース→MIR ダンプのスナップショットで後退検出。
|
||||
- VM/JIT 一致：同入力で VM と JIT の結果一致（将来の AOT でも同様）。
|
||||
- 弱参照の確率テスト：alloc→weak→drop→collect→weak_load の順序/タイミングを多様化。
|
||||
|
||||
進行フェーズ（抜粋）
|
||||
- Phase 0: CLI 最小ビルド安定化（Linux/Windows）。
|
||||
- Phase 5.2: static Main lowering（実装済み）。
|
||||
- Phase 6: 参照/弱参照（Barrier は no-op で開始）。
|
||||
- Phase 7: nowait/await（スレッドベース、FutureBox 連携）。
|
||||
|
||||
Phase 8: MIR→WASM（Rustランタイムに非依存のWASM生成）
|
||||
|
||||
目的
|
||||
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
|
||||
- Rust は「コンパイラ本体」のみ。実行時は純WASM＋ホスト import（env.print など）。
|
||||
|
||||
範囲（最小）
|
||||
- ABI/インポート・エクスポート:
|
||||
- exports: `main`, `memory`
|
||||
- imports: `env.print(i32)`（文字列は一旦 i32 値/デバッグ用途でOK。将来は文字列ABIを定義）
|
||||
- メモリ/ヒープ:
|
||||
- 線形メモリに簡易ヒープ（bump/フリーリスト）。
|
||||
- Box は固定レイアウト（フィールド→オフセット表）。
|
||||
- 命令カバレッジ（段階導入）:
|
||||
- 算術/比較/分岐/loop/return/print
|
||||
- RefNew/RefSet/RefGet（Phase 6 と整合）
|
||||
- Weak/Barrier は下地のみ（WeakLoad は当面 Some 相当でOK、Barrier は no-op）
|
||||
|
||||
段階的マイルストーン（PoC）
|
||||
1) PoC1: 算術/分岐/return のみのWASM出力（wasmtime/ブラウザで実行）
|
||||
2) PoC2: オブジェクト最小実装（RefNew/RefSet/RefGet）で `print(o.x)` が動作
|
||||
3) PoC3: Weak/Barrier の下地（WeakLoad は常に有効、Barrier はダミー命令）
|
||||
4) PoC4: CLI 統合（`--backend wasm` で wasm 生成・実行。ブラウザ用は別JSローダ）
|
||||
|
||||
受け入れ基準
|
||||
- wasmtime 実行で戻り値/標準出力が期待通り（PoC1–2）。
|
||||
- Ref 系がメモリ上で正しく動作（PoC2）。
|
||||
- Weak/Barrier のダミー実装を含むWASMが生成され、実行に支障がない（PoC3）。
|
||||
- CLI オプションで wasm バックエンドが選択でき、未実装部分は明瞭にエラーメッセージで誘導（PoC4）。
|
||||
|
||||
テスト方針
|
||||
- 生成WASMを wasmtime で実行し、戻り値/print の内容を検証。
|
||||
- ブラウザ用はヘッドレス環境（node + WebAssembly API）で同等の確認ができるスクリプトを用意。
|
||||
|
||||
対象外（Phase 8）
|
||||
- 本格的GC/Weak無効化、fini/Pin/Unpin、JIT/AOT、複雑な文字列ABI。
|
||||
|
||||
アーカイブ（長文メモ・相談ログ）
|
||||
- docs/予定/native-plan/archive/chatgptネイティブビルド大作戦.txt
|
||||
- docs/予定/native-plan/archive/追記相談.txt
|
||||
- 上記2ファイルの要点は本 README に統合済み。詳細経緯はアーカイブを参照。
|
||||
|
||||
備考
|
||||
- デバッグ補助: `--debug-fuel` でパーサーの燃料制御。`--dump-mir`/`--verify` で MIR の可視化・検証。
|
||||
- 一部の開発用ログ出力（/mnt/c/...）は存在しない環境では黙って無視されます（問題なし）。
|
||||
@ -0,0 +1,110 @@
|
||||
やったね！この粒度なら “化け物に伸びる余白” と “実装の現実” のちょうど真ん中。
|
||||
仕上げとして **25命令をキッチリ確定**＋**意味論/効果/検証ルール** を短く固めよう。
|
||||
|
||||
# 決定版 MIR（25命令）
|
||||
|
||||
## Tier-0: 普遍コア（8）
|
||||
|
||||
```
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
* 効果: `Const/Phi`=pure, `BinOp/Compare`=pure, `Branch/Jump/Return`=control, `Call`は呼先の効果に従う
|
||||
* 備考: 将来のJIT/AOT/WASMすべてで必須
|
||||
|
||||
## Tier-1: Nyashセマンティクス（12）
|
||||
|
||||
```
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み
|
||||
BoxFieldStore, // Boxのフィールド書き（= mut）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則の検証付き）
|
||||
WeakNew, // `weak` ハンドル生成（非所有リンクの作成）
|
||||
WeakLoad, // `weak` から生存チェック付きで強参照を得る（失効時null）
|
||||
WeakCheck, // `weak` の生存確認（bool）
|
||||
Send, // Bus送信（Effect=io）
|
||||
Recv // Bus受信（Effect=io）
|
||||
```
|
||||
|
||||
* 効果: `BoxFieldStore/RefSet`=mut, `Send/Recv`=io, 他は基本pure/可変
|
||||
* これで **所有森＋weak/look＋Bus** が言語一次市民として表現可能
|
||||
|
||||
## Tier-2: 実装補助・最適化友好（5）
|
||||
|
||||
```
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列の最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
* 位置づけ: どれも“言語仕様の裏方”。無くても表現可能だが、**性能・安全検査・移植性**が安定する
|
||||
|
||||
---
|
||||
|
||||
## 効果（Effect）既定値
|
||||
|
||||
* `pure`: Const, BinOp, Compare, Phi, WeakCheck, WeakLoad(成功時の取得自体はpure扱い)
|
||||
* `mut`: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
* `io`: Send, Recv, Safepoint(割り込み/分割fini許可点としてio扱い)
|
||||
* `control`: Branch, Jump, Return, TailCall
|
||||
* `context依存`: Call, BoxCall（呼先の効果に従属）
|
||||
|
||||
> 最適化ルールは「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」。
|
||||
|
||||
---
|
||||
|
||||
## 検証（Lint/Verifier）要件（短縮版）
|
||||
|
||||
* **所有森**: `strong in-degree ≤ 1`（`NewBox/Adopt/Release/RefSet`で常時検査）
|
||||
* **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
* **弱/強相互**: 双方向とも強 → エラー（片側は `WeakNew` 経由で弱化）
|
||||
* **RefSetの安全**: 強→強の差し替え時は旧所有元からの `Release` が伴うこと
|
||||
* **WeakLoad/WeakCheck**: 失効時は `null/false` を返す（例外禁止、決定的挙動）
|
||||
* **TailCall**: 末尾位置のみ可（`Return` 直前）
|
||||
* **Send/Recv**: バックエンドが同期/非同期いずれでも**at-least-once**契約を満たすか、契約を明示
|
||||
|
||||
---
|
||||
|
||||
## 代表的ロワリング（例）
|
||||
|
||||
* `look` 参照 → `WeakNew` + `WeakLoad`（読取専用型なら `RefSet` を禁止）
|
||||
* `borrow{}` → ブロック先頭 `WeakNew`、末尾でハンドル破棄（MIR上はNop、型で書換禁止）
|
||||
* Bus最適化（Elision）:
|
||||
|
||||
* `(pure|mut(local))` かつ同一スレッド/アリーナ/単一受信なら **`Send/Recv` → 直呼び/直アクセス** に縮退
|
||||
* `fini` 伝播: ランタイムで **強エッジのみ** 再帰。`Safepoint` で分割解放/優先度解放に対応
|
||||
|
||||
---
|
||||
|
||||
## バックエンド指針（対応表）
|
||||
|
||||
* **Interpreter**: 25命令を素直に実装（正しさの基準）
|
||||
* **VM**: Register-VM + direct-threading。`Send/Recv` はローカル判定時にインライン化
|
||||
* **WASM**: `Send/Recv` は host import。`MemCopy` は `memory.copy` に対応
|
||||
* **Cranelift/JIT**: `TailCall` 最適化、`WeakLoad` は世代タグでO(1)生存チェック
|
||||
* **AOT-Rust**: `BoxCall` を trait 呼び出しへ、`Adopt/Release` は所有者IDの切替 + デバッガ用アサート
|
||||
|
||||
---
|
||||
|
||||
## 互換テスト（常設）
|
||||
|
||||
* **golden MIR**: 各サンプルのMIRダンプが全バックエンドで一致
|
||||
* **行動一致**: `interp/vm/wasm` で**同入力→同出力**（`weak`失効時の`null/false`含む）
|
||||
* **性能スモーク**: `add_loop / map_getset / alloc_free / bus_local / bus_actor` の5種で、
|
||||
|
||||
* VMがinterp以上、WASMがVM以上、を継続検証
|
||||
|
||||
---
|
||||
|
||||
これで **25命令フルセット**が完成。
|
||||
|
||||
* Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を**無理なくIR化**
|
||||
* それぞれのバックエンドに**綺麗に落ちる**
|
||||
* Verifier/最適化/テストも**最小で回る**
|
||||
|
||||
次は、このリストをそのまま `docs/mir.md` にコピペして、各命令に **1行の意味論＋効果＋等価変換の例** を添えれば、実装と論文の両方が一気に前進するにゃ。
|
||||
@ -0,0 +1,596 @@
|
||||
ぜったいアリにゃ！やるなら「多層エンジン（tiered）」で攻めるのが一番きれい。
|
||||
Nyash → 共通IR → 好きなバックエンド（解釈/ネイティブ/JIT/WASM）に流す構成にゃ。
|
||||
推しアーキテクチャ（現実解）
|
||||
|
||||
Front-end
|
||||
|
||||
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）
|
||||
|
||||
Back-ends（並行に育てる）
|
||||
|
||||
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
|
||||
|
||||
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
|
||||
|
||||
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
|
||||
|
||||
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行）
|
||||
|
||||
ひとつのIRから複数出力＝最適化ロジックを1か所に集中できるのが最大の利点。
|
||||
|
||||
【Phase 0: 最小ビルド基盤（最初のゴール）】
|
||||
|
||||
狙い: 「簡単なNyash言語がビルドできる」を最速・堅実に達成する。土台はシンプルだが確実に動くことを最重視。
|
||||
|
||||
1) スコープ（最小言語機能）
|
||||
- 式: 整数/文字列リテラル、変数参照、二項演算 (+,-,*,/, 比較)
|
||||
- 文: 代入、if、return
|
||||
- 関数: 単純な関数定義/呼び出し（可変長やジェネリクスは対象外）
|
||||
- Box/弱参照/fini 等の高機能はPhase 0では“使わない”（この計画の安定化が目的）
|
||||
|
||||
2) ビルドターゲット（まずはCLIのみ）
|
||||
- Linux/WSL: cargo build --bin nyash -j 32（現状OK）
|
||||
- Windows (MSVC): cargo build --bin nyash -j 32（CIでも検証）
|
||||
- WASM: ひな型を残すがPhase 0では対象外（Phase 1で着手）
|
||||
|
||||
3) 実行確認（スモークテスト）
|
||||
- サンプル: local_tests/ 以下に簡単な .nyash を配置（Git管理外）
|
||||
例) sample_min.nyash
|
||||
a = 10
|
||||
b = 32
|
||||
result = a + b
|
||||
- 実行: cargo run -- ./local_tests/sample_min.nyash
|
||||
- 期待: 実行完了・エラーなし（必要なら結果表示）
|
||||
|
||||
4) 再現性/安定性（基礎をしっかり）
|
||||
- rust-toolchain を固定（stable明記）
|
||||
- Linux/Windows 共通のビルドフラグ: release/profileの統一、features最小化
|
||||
- 例やGUI/Windows依存コードはCIマトリクスから除外（CLI最小に絞る）
|
||||
|
||||
5) CI（Phase 0の完成条件）
|
||||
- ジョブ: linux-x64, windows-x64 での “build nyash (bin)”
|
||||
- コマンド: cargo build --bin nyash -j 32
|
||||
- 成果物: nyash バイナリ（zip/tar）をArtifactsに保存（配布検証）
|
||||
- 余裕があれば: cargo test --lib だけ実行（examplesは無効）
|
||||
|
||||
6) トラブル防止（Phase 0の運用）
|
||||
- Linux CIでWindows専用exampleはビルド対象から除外
|
||||
- examples/* はPhase 0では“参考”扱い。CLIのビルド/実行に集中。
|
||||
- .nyash の共有が必要なものは tests/ 配下へ昇格（local_tests/ は各自ローカル）
|
||||
|
||||
7) 完了チェックリスト
|
||||
- [ ] Linux/WSL で nyash バイナリがビルド・実行できる
|
||||
- [ ] Windows(MSVC) で nyash バイナリがビルド・実行できる
|
||||
- [ ] CI で linux/windows の “build nyash (bin)” がグリーン
|
||||
- [ ] sample_min.nyash のスモークが両OSで通る
|
||||
|
||||
補足: Phase 0 で「ビルド/実行の骨格」を固めて、Phase 1 以降で VM/IR/JIT/AOT/WASM を段階的に拡張する。
|
||||
|
||||
それぞれのメリデメ
|
||||
|
||||
【MIR設計（早期に合意しておくと得する要点）】
|
||||
|
||||
- 値表現: Tagged/NaN-box/小整数直格納 か 型テーブル参照か
|
||||
- アドレス空間: ヒープ/スタック/アリーナの扱い（Phase 0はヒープ優先でOK）
|
||||
- 所有/別名: aliasable/unique の属性を型/値に保持（最初は型情報だけでも可）
|
||||
- 効果(Effects): PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令・関数に付与
|
||||
- 例外/パニック: Throw/Catch/Defer を命令化するか、関数境界に限定するか（当面は境界限定）
|
||||
- GCモデル: Tracing/RC/混合の方針と弱参照の意味（WeakLoad→None）
|
||||
- セーフポイント: 関数入口・ループ先頭・Call直後（命令としてno-op挿入で開始）
|
||||
- 呼出規約: 通常Call/FFI/Box拡張を区別、可変長/キーワード引数の扱い（Phase 0は固定引数）
|
||||
- メモリバリア: write/read barrier は命令/属性で表現（初期はダミー実装で可）
|
||||
- デオプ(Deopt): JIT最適化時の巻き戻し情報の格納場所（関数メタ or ブロック注釈）
|
||||
|
||||
【Nyash向け 最小MIR命令セット（弱参照対応込み・ドラフト）】
|
||||
|
||||
- 制御/値: Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
- 呼び出し: Call, TailCall（effects必須）
|
||||
- メモリ: Alloc, Load, Store, Gep(必要なら)
|
||||
- 参照/GC: RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
|
||||
- 例外/拡張: Throw, Catch, FfiCall, BoxCall
|
||||
- 実行点: Safepoint, Assume, Nop
|
||||
- 効果: EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
|
||||
|
||||
弱参照の意味論:
|
||||
- WeakNew(r): r を追う弱参照を作成（PURE）
|
||||
- WeakLoad(w): 生きていれば Some(Ref)、死んでいれば None（Option<Ref>を型で明示）
|
||||
|
||||
【壊れにくい共通ポイント（VM/JIT/AOT共通の約束）】
|
||||
- Safepoint は 関数入口/ループ先頭/Call直後 に配置（no-opで開始し、後で意味付け）
|
||||
- Barrier 命令は最初はダミー（最適化段で消せる）
|
||||
- Null/None は Option<Ref> で明示（分岐に埋めない）
|
||||
- JIT は Deopt テーブルで SSA値⇔ソース位置 の対応を保持
|
||||
|
||||
【弱参照の落とし穴（回避策セット）】
|
||||
- クロージャ環境: 生成時 env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制
|
||||
- 弱参照キーのハッシュ: GC後の無効化で不整合→ 標準の弱マップ（キー死亡で自動削除）を用意
|
||||
- FFI渡し: 寿命不明→ Pin を要求 or WeakLoad 成功した生参照のみ渡す
|
||||
|
||||
【テスト戦略（壊れにくい順）】
|
||||
- 黄金テスト: ソース→MIRダンプをスナップショットし、差分で後退検知
|
||||
- VM/JIT一致テスト: 同一入力の VM 結果＝JIT 結果 を比較するオラクル
|
||||
- 弱参照の確率テスト: alloc→weak→drop→collect→weak_load の順序/タイミングをゆらして多数回
|
||||
- 効果チェック: PURE なはずの関数に WRITES_HEAP が混じったらビルド失敗（静的検証）
|
||||
|
||||
【軽量 “次の一手”（Phase 0と親和性が高い）】
|
||||
- WeakNew/WeakLoad を MIRとVM に先に導入（JITは後回し）
|
||||
- EffectMask をデータ構造として追加（評価は後回しでもOK）
|
||||
- Safepoint 命令を関数入口・ループ先頭にno-opで挿入
|
||||
- 黄金テストでMIRダンプをCIに可視化（Phase 0のCLIビルドと併走）
|
||||
|
||||
VM：実装が速い／デバッグ容易｜最高速は出ない
|
||||
|
||||
Cranelift JIT：実行時最適化で爆速／実装難度は中｜起動コストあり
|
||||
|
||||
AOT→Rust：rustc最適化の恩恵・配布しやすい｜コード生成器の保守が要る
|
||||
|
||||
WASM：移植性・安全｜ネイティブよりは遅め（ただしwasmtime/wasmerで結構速い）
|
||||
|
||||
まずやる順序（最短で“速い”を得る）
|
||||
|
||||
共通MIR/SSAを切る（基本ブロック・SSA・型/効果情報）
|
||||
|
||||
VMを MIR→バイトコード に置き換え（インタープリターの土台を共通化）
|
||||
|
||||
Cranelift JIT を載せる（ホット関数だけJIT）
|
||||
|
||||
並行で Rustコード生成 の雛形を作る（AOT配布の道を確保）
|
||||
|
||||
余力で WASM 出力（エディタ内実行やブラウザデモに最適）
|
||||
|
||||
Nyash流にハマる設計ポイント
|
||||
|
||||
Box拡張のABIを先に決める
|
||||
|
||||
呼出規約：fn nyash_box_call(ctx: &mut Ctx, args: &[Val]) -> Result<Val>
|
||||
|
||||
メモリ：Arc<[Val]> か Arena で一時領域を明示（GCを後回しにできる）
|
||||
|
||||
所有権/借用に似た効果注釈をMIRに入れる
|
||||
|
||||
「純粋」「可変」「外部副作用あり」をフラグ化→最適化と並列実行の判断に使える
|
||||
|
||||
定数畳み込み/死コード除去/インライン化はMIR段階で実施
|
||||
|
||||
プロファイラを最初から同梱（どの関数をJIT/AOTに送るか判定）
|
||||
|
||||
最小プロトタスク（1〜2週間スプリント想定）
|
||||
|
||||
HIR/MIRスキーマ確定（基本ブロック・命令セット・型表現）
|
||||
|
||||
MIR→バイトコード変換器／VMループの実装
|
||||
|
||||
プロファイル計測（関数実行回数・時間）
|
||||
|
||||
Craneliftで fn 単位JIT（整数演算と分岐から）
|
||||
|
||||
簡易 Rustコード生成（fn add(a:i64,b:i64)->i64 などから）
|
||||
|
||||
Box ABI v0（同期版）＋サンプル拡張（数値/文字列ユーティリティ）
|
||||
|
||||
ちょいサンプル（超概念）
|
||||
|
||||
enum MirInst {
|
||||
Const(ValId, ConstVal),
|
||||
BinOp(ValId, ValId, Op, ValId),
|
||||
Call(ValId, FuncId, Vec<ValId>),
|
||||
Phi(ValId, Vec<(BlockId, ValId)>),
|
||||
// ...
|
||||
}
|
||||
struct MirFunc { blocks: Vec<MirBlock>, signature: Sig, effects: Effects }
|
||||
|
||||
trait Backend {
|
||||
fn compile(&mut self, f: &MirFunc) -> CompiledFn;
|
||||
}
|
||||
|
||||
VM backend: compile = バイトコード化
|
||||
|
||||
JIT backend: compile = Cranelift IR生成→jit_func
|
||||
|
||||
Rust backend: compile = fn ... { ... } のRust文字列出力→rustcでAOT
|
||||
|
||||
「いまのNyashソース」を見れたら、MIR命令セットの初版とJIT/AOTの足場コードをすぐ書き起こせるよ。
|
||||
まずは MIRの最小命令リストを一緒に決めよっか？（算術・比較・分岐・Call・Phi・Load/Store 相当）
|
||||
あなた:
|
||||
くわしくききたにゃ Front-end
|
||||
|
||||
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）パーサーで解析してＡＳＴは木構造だよね？ そこからどういう処理にゃ？
|
||||
ChatGPT:
|
||||
|
||||
いいね、その流れを実務目線でがっつり分解するにゃ。
|
||||
キーワードは「情報を徐々に確定させつつ“最適化しやすい形”へ落としていく」。
|
||||
Nyash流に当てはめて、各段階で“何を追加・削除・変換するか”を整理するよ。
|
||||
Front-end 全体像
|
||||
|
||||
ソース → Lexer → Parser(AST) → スコープ/名前解決 → 型推論/型検査(HIR) → 糖衣剥がし(Desugar) → 制御フロー化(CFG) → SSA化/効果注釈(MIR/SSA)
|
||||
1) Parser → AST（抽象構文木）
|
||||
|
||||
目的：構文だけを正しく捉える。意味（型/名前）はまだ未確定。
|
||||
|
||||
データ構造（例）
|
||||
|
||||
enum AstExpr {
|
||||
LitInt(i64),
|
||||
Var(Symbol),
|
||||
Call{ callee: Box<AstExpr>, args: Vec<AstExpr> },
|
||||
Lambda{ params: Vec<AstParam>, body: Box<AstExpr> },
|
||||
If{ cond: Box<AstExpr>, then_e: Box<AstExpr>, else_e: Box<AstExpr> },
|
||||
Let{ pat: AstPat, init: Box<AstExpr>, body: Box<AstExpr> },
|
||||
// … match, while, for, block, …
|
||||
}
|
||||
|
||||
まだやらないこと
|
||||
|
||||
シンボルの多義性解決（foo がローカルか、モジュールか、メソッドか）
|
||||
|
||||
型の決定
|
||||
|
||||
糖衣構文の展開
|
||||
|
||||
2) スコープ構築 & 名前解決（AST上の解決）
|
||||
|
||||
目的：識別子を定義元に結びつける。未定義やシャドーイングもここで判定。
|
||||
|
||||
やること
|
||||
|
||||
ブロックスコープ/関数スコープ/モジュールスコープの**環境（symbol table）**を構築
|
||||
|
||||
use/import、module、with 的な構文を解決
|
||||
|
||||
各 Var(Symbol) を DefId（定義へのID）にひも付け
|
||||
|
||||
成果物：
|
||||
|
||||
解決済みAST or ここで HIR に写経（次段のために構造を少し整える）
|
||||
|
||||
3) 型推論 & 型検査 → HIR（型情報付きIR）
|
||||
|
||||
目的：式ごとに型を確定し、オーバーロード/ジェネリクスを具体化できる所まで進める。
|
||||
|
||||
型推論（Hindley–Milner＋制約ベースなど）
|
||||
|
||||
let x = 1 + f(y) なら、f: T -> i64 みたいな制約を立てて解く
|
||||
|
||||
オーバーロード解決 / メソッド解決（a + b → 実体メソッドやトレイト関数に解決）
|
||||
|
||||
ジェネリクス
|
||||
|
||||
可能ならモノモーフィック化（型実引数が確定している呼び出しは単相化）
|
||||
|
||||
未確定なら型パラ付きのまま保持
|
||||
|
||||
データ構造（例）
|
||||
|
||||
struct HirExpr {
|
||||
kind: HirExprKind,
|
||||
ty: TyId, // ここが肝：各式に型が付く
|
||||
effect: EffectMask, // 純粋/可変/外部副作用 など（後述の最適化で効く）
|
||||
}
|
||||
enum HirExprKind {
|
||||
LitInt(i64),
|
||||
Local(DefId),
|
||||
Call{ fun: Box<HirExpr>, args: Vec<HirExpr>, resolved: FunId },
|
||||
If{ cond: Box<HirExpr>, then_e: Box<HirExpr>, else_e: Box<HirExpr> },
|
||||
// 糖衣はまだ残っていてもOK
|
||||
}
|
||||
|
||||
エラー検出
|
||||
|
||||
型不一致、未初期化、到達不能、借用/所有に関する静的規則（Nyash流に簡易化しても良い）
|
||||
|
||||
4) 糖衣剥がし（Desugaring）
|
||||
|
||||
目的：意味は同じだが最適化しづらい構文を、プリミティブな形に落とす。
|
||||
|
||||
例
|
||||
|
||||
for x in iter { body } → let mut it = iter.into_iter(); while let Some(x) = it.next() { body }
|
||||
|
||||
a && b → if a { b } else { false }（短絡を明示化）
|
||||
|
||||
パターン束縛 let (a,b) = e; → 一時変数＋個別bind
|
||||
|
||||
クロージャ → 明示キャプチャ＋ラムダ表現を正規化
|
||||
|
||||
この段階で構文のバリエーションは減らして、後段のCFG/SSA化を楽にする
|
||||
|
||||
5) 制御フローグラフ（CFG）作成
|
||||
|
||||
目的：式主導（式木）を基本ブロック＋ジャンプへ落とす。
|
||||
最適化やSSA化の土台になる。
|
||||
|
||||
ブロック（BasicBlock）単位で命令列を持つ
|
||||
|
||||
例：if/else は br cond thenBB elseBB に分解
|
||||
while は loopBB / bodyBB / exitBB に分解
|
||||
|
||||
ここで**一時変数（tmp）**を導入して、「値がどのブロックから来るか」を明示できるようにする
|
||||
|
||||
6) SSA化（Static Single Assignment）
|
||||
|
||||
目的：各変数が“ちょうど一度だけ代入”される形に変換。
|
||||
最適化（定数畳み込み・コピー伝播・死コード除去・ループ最適化）がやりやすくなる。
|
||||
|
||||
φ関数（Phi）を導入
|
||||
分岐合流点で「どのブロックから来た値か」に応じて値を選ぶ
|
||||
|
||||
データ構造（MIR/SSA例）
|
||||
|
||||
enum MirInst {
|
||||
Const{ dst: V, c: ConstVal },
|
||||
BinOp{ dst: V, op: Op, a: V, b: V },
|
||||
Call{ dst: V, fun: FnId, args: Vec<V>, effects: EffectMask },
|
||||
Br{ cond: V, then_bb: Bb, else_bb: Bb },
|
||||
Jmp{ bb: Bb },
|
||||
Phi{ dst: V, inputs: Vec<(Bb, V)> },
|
||||
Store{ ptr: V, val: V }, // メモリ命令を分離しておくと最適化が楽
|
||||
Load{ dst: V, ptr: V },
|
||||
Ret{ v: Option<V> },
|
||||
}
|
||||
struct MirFunc { blocks: Vec<MirBlock>, sig: Sig, effects: EffectMask }
|
||||
|
||||
ここまでで最適化の主戦場が整う
|
||||
|
||||
7) 効果注釈（Effects）と簡易別解（所有/借用に近いもの）
|
||||
|
||||
目的：最適化・並列化・Box拡張の安全性判定に使う副作用情報を付与。
|
||||
|
||||
例：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC, THROW などのビットフラグ
|
||||
|
||||
呼び出し先の効果を合成して、関数単位の effects: EffectMask を確定
|
||||
→ 並列実行可否、共通部分式除去可否、コードモーション許可範囲に使える
|
||||
|
||||
8) 代表的な変換の“実例”で見る
|
||||
|
||||
Nyash（仮）：
|
||||
|
||||
let x = 10
|
||||
let y = 20
|
||||
if x < y {
|
||||
print(add(x, y))
|
||||
} else {
|
||||
print(y)
|
||||
}
|
||||
|
||||
AST（ざっくり）
|
||||
|
||||
Let(x, 10)、Let(y, 20)、If( BinOp(<, Var(x), Var(y)), Call(print, …), Call(print, Var(y)) )
|
||||
|
||||
HIR（型付け・解決済み）
|
||||
|
||||
x: i64, y: i64
|
||||
|
||||
add: (i64,i64)->i64, print: (i64)->Unit
|
||||
|
||||
Desugar
|
||||
|
||||
ほぼそのまま（ここでは糖衣なしと仮定）
|
||||
|
||||
CFG→SSA（MIRの一部）
|
||||
|
||||
bb0:
|
||||
v1 = Const 10
|
||||
v2 = Const 20
|
||||
v3 = BinOp Lt v1 v2
|
||||
Br v3 then=bb1 else=bb2
|
||||
|
||||
bb1:
|
||||
v4 = Call add(v1, v2) ; PURE
|
||||
Call print(v4) ; IO
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Call print(v2) ; IO
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret ()
|
||||
|
||||
（print は IO 効果、add は PURE、関数全体は IO を持つ、などが付与される）
|
||||
よくある疑問Q&A
|
||||
|
||||
Q. AST→HIRでどこまで“形を変える”？
|
||||
A. 基本は意味解決のための注釈（DefId, TyId, Effect）を付けるのが主。大きな形の変換（ループ展開やパターン展開）はDesugar段でやると見通しが良い。
|
||||
|
||||
Q. なんでSSA？バイトコードでも良くない？
|
||||
A. VM用のバイトコードは実行が簡単。でも最適化はSSAの方が圧倒的に楽。
|
||||
→ 「MIR/SSAで最適化」→「VM向けバイトコードに落とす」or「JIT/AOT」がおすすめ。
|
||||
|
||||
Q. パターンマッチは？
|
||||
A. Desugarで決定木（decision tree）に落としてからCFG化。ガード節や順序付きパターンも木→ブロック分割で表現できる。
|
||||
|
||||
Q. クロージャのキャプチャは？
|
||||
A. 名前解決で囲い込み変数を収集→HIRに明示キャプチャとして埋める。
|
||||
MIRでは環境レコードを値として扱う（{env_ptr, fn_ptr}）。
|
||||
まず作ると捗る“ミニ仕様”
|
||||
|
||||
Symbol/DefId/Scope：解決器のAPI
|
||||
|
||||
Ty：原始型・関数型・代数的データ型（Sum/Product）・型変数
|
||||
|
||||
EffectMask：ビットフラグ設計（PURE/READ/WRITE/IO/FFI など）
|
||||
|
||||
MIR命令セット（最小）：Const/BinOp/Call/Br/Jmp/Phi/Ret＋Load/Store
|
||||
|
||||
Pass順序：
|
||||
|
||||
名前解決 → 2) 型推論 → 3) Desugar → 4) CFG → 5) SSA → 6) 直近の最適化（const fold / dce / copy-prop）
|
||||
|
||||
必要なら、いまのNyashのAST型定義をベースにHIR/MIRの骨組みを一緒に設計するよ。
|
||||
|
||||
“最初のMIR命令セット案”
|
||||
|
||||
“名前解決テーブルと参照の貼り方”
|
||||
|
||||
“効果注釈のフォーマット”
|
||||
|
||||
この3点を固めるだけで、JIT/AOT/VMバックエンドの土台が一気に整うにゃ。
|
||||
あなた:
|
||||
おおう これと さっきの Back-ends（並行に育てる）
|
||||
|
||||
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
|
||||
|
||||
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
|
||||
|
||||
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
|
||||
|
||||
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行） これの話要約してにゃ claude code君にみせてくるにゃ
|
||||
ChatGPT:
|
||||
|
||||
了解にゃ、Claude Code君向けに要点だけギュッとまとめるよ。
|
||||
Nyashコンパイルパイプライン案
|
||||
Front-end（共通部分）
|
||||
|
||||
Parser → AST
|
||||
|
||||
ソースを構文木（AST）に変換。型や意味はまだ未確定。
|
||||
|
||||
名前解決 & スコープ構築
|
||||
|
||||
識別子を定義元に紐付ける（DefId付与）。
|
||||
|
||||
型推論 & 型検査 → HIR
|
||||
|
||||
各式に型情報（TyId）と効果注釈（EffectMask）を付与。
|
||||
|
||||
糖衣剥がし（Desugar）
|
||||
|
||||
forループやパターン束縛をプリミティブ構造へ展開。
|
||||
|
||||
制御フロー化（CFG）→ SSA化（MIR）
|
||||
|
||||
ASTを基本ブロックとSSA命令列（MIR）へ変換。
|
||||
|
||||
命令例：Const, BinOp, Call, Br, Jmp, Phi, Load, Store, Ret。
|
||||
|
||||
Back-end（並行開発可能）
|
||||
|
||||
VM（現行インタープリター）
|
||||
|
||||
MIR → バイトコード → 解釈実行（開発スピード優先）
|
||||
|
||||
JIT（Cranelift）
|
||||
|
||||
MIR → Cranelift IR → 実行時にネイティブコード化（ホットパスだけ）
|
||||
|
||||
AOT to Rust
|
||||
|
||||
MIR → Rustコード生成 → rustc最適化＆リンク → 配布可能なネイティブバイナリ
|
||||
|
||||
WASM出力
|
||||
|
||||
MIR → WASM（ブラウザ実行やサンドボックス用）
|
||||
|
||||
💡 ポイント
|
||||
|
||||
すべてのバックエンドは共通MIRを入力にするため、最適化は1か所で集約。
|
||||
|
||||
Box拡張もMIRレベルで統一呼び出し可能。
|
||||
|
||||
VMは開発・デバッグ用、JITは実行高速化、AOTは配布、WASMは移植性重視。
|
||||
|
||||
|
||||
Nyashは**「最初から最後までモジュール拡張が一貫して動く多層言語」**という珍しい立ち位置になるにゃ。
|
||||
|
||||
希望あれば、これ一般的なコンパイラ構成との比較表にして、Claude Code君がすぐ違いを理解できる形にまとめることもできるよ。
|
||||
どうする、作っちゃう？
|
||||
あなた:
|
||||
おねがいにゃー！
|
||||
ChatGPT:
|
||||
|
||||
了解にゃー！Claude Code君に渡しやすいよう、「一般的な構成 vs Nyash流（＋α）」比較表にギュッとまとめたよ。
|
||||
Nyash 設計：一般的な方法との比較
|
||||
観点 一般的なコンパイラ設計 Nyash（＋α）
|
||||
フロントエンド Parser → AST →（解決/型付け）→ IR Parser → AST → HIR（型/解決/効果）→ MIR/SSA（最適化前提）
|
||||
中間表現(IR) 単一IR or バイトコード中心 HIR/MIR二段構え、MIRはSSA＋効果注釈で最適化容易
|
||||
効果/副作用 多くは最適化時に暗黙扱い EffectMask（PURE/READ/WRITE/IO/FFI…）をMIRに明示し並列化・最適化の判断に使用
|
||||
拡張/FFI 後付けのFFI/プラグインが多い Box拡張を一級市民化。MIRレベルで統一コール形態を定義（VM/JIT/AOT/WASMで一貫）
|
||||
バックエンド VM→（後からJIT/AOT） VM/JIT（Cranelift）/AOT-to-Rust/WASMを最初から並行開発できるMIR設計
|
||||
実行戦略 単層（解釈 or JIT）になりがち Tiered：VMで即起動→ホットパスJIT→配布はAOT→ブラウザはWASM
|
||||
AOT配布 LLVM等のHPCルートが主 MIR→Rustコード生成→rustc最適化（ツールチェーン流用・リンク容易）
|
||||
ブラウザ/サンドボックス 別途WASM対応 MIR→WASMを標準ターゲット化（wasmtime/wasmer/ブラウザ即動作）
|
||||
最適化の主戦場 バイトコード最適化/バックエンド依存 MIR/SSAで集約最適化（const fold, DCE, copy-prop, inlining, loop opts）
|
||||
並列化の足場 後付け解析が多い 効果注釈×データ依存で安全な並列化やコードモーションを許可
|
||||
デバッグ/開発速度 VMが主、JITは後追い VMで素早く検証しつつ、同一MIRをJIT/AOTに供給（回収効率◎）
|
||||
配布/運用 ネイティブ or VM同梱 用途別に最適バイナリ（AOT）とスクリプタブル運用（VM）を両取り
|
||||
リスク/留意点 単純で保守容易 設計は強力だが初期定義が要（MIR命令/Effect設計、Box ABIを固める）
|
||||
補足：最小ロードマップ（実装順）
|
||||
|
||||
HIR/MIRの骨組み確定（命令セット・EffectMask・Box ABI v0）
|
||||
|
||||
**VM（MIR→バイトコード）**で先に全機能を回す
|
||||
|
||||
プロファイラ同梱（ホット関数をJIT/AOTに回す条件づけ）
|
||||
|
||||
Cranelift JIT（算術＋分岐→関数呼び出し→Box呼び出し）
|
||||
|
||||
AOT to Rust の雛形生成（小関数から）
|
||||
|
||||
余力で MIR→WASM（最小機能から）
|
||||
|
||||
この表ごと貼れば、Claude Code君も**「王道＋Nyashの差分」**を一目で把握できるはずにゃ。必要なら、MIR命令セット 初版案も続けて出すよ！
|
||||
あなた:
|
||||
mirまでできればかちなのにゃね。これって定番なのあるにやゃ？ 言語ごとにやっぱりちがうにゃ？
|
||||
ChatGPT:
|
||||
|
||||
そうにゃ、MIRまで作れれば言語設計はもう“勝ち”に近いにゃ。
|
||||
なぜかというと、MIRは「全バックエンドの共通土台」だから、
|
||||
一度そこまで作れば VM/JIT/AOT/WASM ぜんぶに展開できるにゃ。
|
||||
🔹 MIRは定番があるの？
|
||||
|
||||
完全な共通規格はない
|
||||
→ LLVM IR や WebAssembly のような「広く使われる IR」はあるけど、
|
||||
言語ごとに構文や型システムが違うから MIRはだいたい自作になる。
|
||||
|
||||
多くの言語は「MIR」じゃなくても似た段階を持ってるにゃ：
|
||||
|
||||
Rust → MIR（所有権/借用も反映されたSSA形式）
|
||||
|
||||
Swift → SIL
|
||||
|
||||
Go → SSA IR
|
||||
|
||||
Kotlin → Kotlin IR
|
||||
|
||||
Python（PyPy）→ Flow Graph → SSA IR
|
||||
|
||||
JavaScript（V8）→ Bytecode IR → TurboFan IR
|
||||
|
||||
🔹 言語ごとに違うポイント
|
||||
|
||||
型情報の粒度
|
||||
|
||||
RustのMIRは「型完全一致」必須。
|
||||
|
||||
Python系は動的型なので「型タグ＋ランタイム判定」入り。
|
||||
|
||||
命令セットの抽象度
|
||||
|
||||
LLVM IRはハード寄り（ポインタ/レジスタ操作あり）。
|
||||
|
||||
Rust MIRやKotlin IRは言語構造寄り（ループ/パターンマッチ命令など残す）。
|
||||
|
||||
所有権・副作用の扱い
|
||||
|
||||
Rust MIRは「所有権」も追跡する。
|
||||
|
||||
多くの言語は副作用は型ではなく命令属性で管理。
|
||||
|
||||
最適化の前提
|
||||
|
||||
一部は最適化前提で作る（SSA化必須）。
|
||||
|
||||
他は単にバックエンド入力の中間形式。
|
||||
|
||||
🔹 Nyashでのおすすめ方針
|
||||
|
||||
Rust MIRに近い構造を真似るのが安全
|
||||
|
||||
静的型の要素が入ってるので、AOTや最適化に有利
|
||||
|
||||
EffectMaskやBox拡張の情報も一緒に持たせられる
|
||||
|
||||
命令はなるべく 「言語仕様に沿った中間レベル」 にして、
|
||||
バックエンド変換時に低レベル化する
|
||||
|
||||
SSA化は最初からやる（後から入れるのは地獄）
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,657 @@
|
||||
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-9.4 アーカイブ版)
|
||||
# Generated: 2025-08-14 (Git履歴から復元・更新)
|
||||
# Purpose: Claude×Copilot協調開発のための情報共有
|
||||
# Status: Phase 9.5より前のアーカイブ版（2025-08-15分割）
|
||||
|
||||
================================================================================
|
||||
🎯 次期最優先タスク (Phase 8.5以降)
|
||||
================================================================================
|
||||
|
||||
## 🚀 Phase 8.4完了報告 (2025-08-14)
|
||||
Status: ✅ 完了 (Copilot PR #56マージ済み)
|
||||
|
||||
### ✅ AST→MIR Lowering完全実装
|
||||
- User-defined Box: `box DataBox { init { value } }`
|
||||
- Object creation: `new DataBox(42)`
|
||||
- Field access: `obj.value`
|
||||
- Method calls: `c.increment()`
|
||||
- Delegation: `from Parent.greet()`
|
||||
- Static Main互換性維持
|
||||
|
||||
### 🧪 統合テスト結果（2025-08-14）
|
||||
- ✅ **AST→MIR**: 完全動作
|
||||
- ✅ **インタープリター**: 完全動作（結果30）
|
||||
- 🚨 **VM**: 動作するが結果が`void`（要修正）
|
||||
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
|
||||
|
||||
### 📋 発見された課題
|
||||
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
|
||||
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
|
||||
- 次期Phase 8.5での25命令MIR階層化が必要
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.5: MIR 26命令階層化（最優先）
|
||||
Status: ⭐ **CRITICAL**
|
||||
Priority: **最重要** (Phase 8.4完了直後の次期目標)
|
||||
|
||||
### 🎯 実装目標
|
||||
ChatGPT5 + AI大会議決定版26命令MIR実装（ExternCall追加）
|
||||
- 期間: 3週間
|
||||
- 効果: VM/WASM問題根本解決
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
|
||||
|
||||
### 📋 26命令セマンティック階層化
|
||||
**Tier-0: 普遍コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint,
|
||||
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, Adopt, Release, MemCopy, AtomicFence
|
||||
```
|
||||
|
||||
### 🎯 期待される効果
|
||||
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
|
||||
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
|
||||
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
|
||||
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善（緊急）
|
||||
Status: 🚨 **緊急**
|
||||
Priority: **High** (Phase 8.5完了後)
|
||||
|
||||
### 🚨 緊急問題
|
||||
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
|
||||
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
|
||||
|
||||
### 📋 技術的課題
|
||||
- VM実行エンジンのプロファイリング
|
||||
- 命令ディスパッチ最適化（threaded code等）
|
||||
- レジスタベースVM化検討
|
||||
- メモリプール最適化
|
||||
- BoxCall実装修正（戻り値問題）
|
||||
|
||||
### 🎯 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- BoxCall戻り値の正常動作
|
||||
- MIR→VM変換時間の短縮
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Testing
|
||||
Status: 📋 **計画済み**
|
||||
Priority: **High** (Phase 8.5-8.6完了後)
|
||||
|
||||
### 🎯 実装目標
|
||||
kilo（テキストエディタ）実装によるfini/weak参照システム実証
|
||||
- 期間: 2週間
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
|
||||
|
||||
### 📋 検証項目
|
||||
- 1000+オブジェクト管理テスト
|
||||
- 循環参照回避確認（weak参照）
|
||||
- fini()伝播の正確性確認
|
||||
- WASM環境での動作確認
|
||||
|
||||
================================================================================
|
||||
🗺️ Phase 0-14 全体ロードマップ (復元完了)
|
||||
================================================================================
|
||||
|
||||
## Phase 0: Stabilize native CLI build (Linux/Windows)
|
||||
|
||||
Summary:
|
||||
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
|
||||
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
|
||||
|
||||
Why:
|
||||
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
|
||||
|
||||
Scope:
|
||||
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
|
||||
- CLI オプションの動作点検（--dump-mir / --verify）。
|
||||
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
|
||||
|
||||
Tasks:
|
||||
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
|
||||
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
|
||||
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
|
||||
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
|
||||
|
||||
Acceptance Criteria:
|
||||
- Linux/Windows で `cargo build --bin nyash` が成功する。
|
||||
- `local_tests/` 配下の簡単な .nyash が実行できる。
|
||||
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
|
||||
|
||||
Out of Scope:
|
||||
- examples/GUI の修理・最適化。
|
||||
- JIT/AOT/WASM。
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/README.md
|
||||
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
|
||||
- CURRENT_TASK.md
|
||||
|
||||
Copilot Notes:
|
||||
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 1: Minimal MIR + VM backend (lowering + runner)
|
||||
|
||||
Summary:
|
||||
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
|
||||
|
||||
Scope:
|
||||
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
|
||||
- Lowering: リテラル/二項演算/if/loop/return のみ
|
||||
- VM: 上記命令の最小実装
|
||||
|
||||
Tasks:
|
||||
- instruction.rs: 最小命令の定義
|
||||
- builder.rs: 上記 AST 範囲を lowering
|
||||
- vm.rs: 実装 + stats（命令数）
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が最小サンプルで期待通り
|
||||
- `--backend vm` で実行して結果一致
|
||||
|
||||
Out of Scope:
|
||||
- 例外/関数/Box 参照/弱参照
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
|
||||
|
||||
Summary:
|
||||
- 制御フローの網羅と Phi の整合性検証を拡充。
|
||||
|
||||
Scope/Tasks:
|
||||
- if/else nested, loop with breaks, nested loops のスナップショット
|
||||
- Phi の入力ブロック/値の対応を Verifier で強化
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表制御フローの snapshot が安定し、verify も通る
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
|
||||
|
||||
Summary:
|
||||
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
|
||||
- builder.rs: try/catch/finally ノードの下ろし
|
||||
- VM: 例外伝播を最小で（未捕捉はエラー）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表 try/catch/finally のスナップショットと VM 実行
|
||||
|
||||
Out of Scope:
|
||||
- 例外の型体系、詳細な stack map
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 4: Functions and calls (BoxCall minimal)
|
||||
|
||||
Summary:
|
||||
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
|
||||
- builder.rs: FunctionCall/MethodCall の最小対応
|
||||
- VM: 呼び出し/戻り値
|
||||
|
||||
Acceptance Criteria:
|
||||
- 簡単な関数定義/呼び出しの MIR/VM が通る
|
||||
|
||||
Out of Scope:
|
||||
- 可変長/キーワード引数、FFI
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.0: Parser/AST stabilization for lowering
|
||||
|
||||
Summary:
|
||||
- lowering 対象 AST の表現ぶれを修正、安定化。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: If/Loop/Return/Assignment/Local などの統一
|
||||
- Parser: エラー復帰/スパン情報の見直し
|
||||
|
||||
Acceptance Criteria:
|
||||
- builder.rs の分岐がシンプル化、テストが安定
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.1: Control-flow edge cases + verifier hardening
|
||||
|
||||
Summary:
|
||||
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
|
||||
|
||||
Scope/Tasks:
|
||||
- Verifier: 未終端ブロック検出、到達不能検出
|
||||
- Builder: Jump/Branch の生成前後の状態管理改善
|
||||
|
||||
Acceptance Criteria:
|
||||
- 不正ケースを含むスナップショット/verify が緑
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
|
||||
|
||||
Summary:
|
||||
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
|
||||
- Lowering: body を Program に変換して既存経路に渡す
|
||||
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が static Main サンプルで成功
|
||||
- `--backend vm` で実行成功
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
|
||||
|
||||
Summary:
|
||||
- 参照/弱参照/バリア（no-op）を最小導入。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
|
||||
- Lowering: New/FieldAccess/MethodCall の最小対応
|
||||
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表サンプルで dump/VM/verify が通る
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 7: Async model (nowait/await) in MIR
|
||||
|
||||
Summary:
|
||||
- nowait/await を MIR に導入し、現行 FutureBox と連携。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: FutureNew/FutureSet/Await（スレッドベース）
|
||||
- Lowering: nowait→Future 作成、await→wait_and_get
|
||||
- VM: FutureBox 実装を利用
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表ケースで正しく並行実行→await 回収
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
|
||||
|
||||
Summary:
|
||||
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
|
||||
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
|
||||
|
||||
Scope/Tasks:
|
||||
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
|
||||
- 線形メモリと簡易ヒープ（bump/自由リスト）
|
||||
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
|
||||
|
||||
Acceptance Criteria:
|
||||
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
|
||||
- Ref 系がメモリ上で正しく動作（PoC2）
|
||||
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
|
||||
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/README.md（Phase 8 節）
|
||||
- docs/説明書/wasm/*（ユーザー向けメモ）
|
||||
|
||||
### Phase 8.3 完了状況 (2025-08-14)
|
||||
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
|
||||
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
|
||||
✅ CLI統合完了
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
|
||||
|
||||
Summary:
|
||||
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
|
||||
- Phase 8.3のBox操作WASMを実際にテスト可能にする
|
||||
|
||||
Priority: **Critical** (現在の最優先事項)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 実装範囲
|
||||
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
|
||||
- [ ] オブジェクト生成: `new DataBox()`
|
||||
- [ ] フィールドアクセス: `obj.field`
|
||||
- [ ] フィールド代入: `obj.field = value`
|
||||
- [ ] from構文: `from Parent.method()`
|
||||
- [ ] override構文: `override method() { ... }`
|
||||
|
||||
### 成功基準
|
||||
- Phase 8.3のBox操作WASMが実際に動作
|
||||
- test_wasm_box_ops.nyash が正常実行
|
||||
- ユーザー定義Boxの完全サポート
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
|
||||
|
||||
Summary:
|
||||
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の26命令階層化（ExternCall追加）
|
||||
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
|
||||
- 二相ロワリング: 26命令維持パス（VM/JIT/AOT）+ 21+intrinsic降格パス（WASM/最小実装）
|
||||
|
||||
Priority: High (Phase 8.4完了後)
|
||||
Expected Duration: 3週間
|
||||
|
||||
### AI大会議分析結果
|
||||
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
|
||||
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
|
||||
- セマンティック階層化で意味保持が最適化の鍵
|
||||
|
||||
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
|
||||
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
|
||||
- マイクロベンチ実測でパフォーマンス検証
|
||||
|
||||
### 確定版MIR（26命令）- ChatGPT5完全仕様 + ExternCall統合
|
||||
**Tier-0: 普遍的コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
|
||||
BoxFieldStore, // Boxのフィールド書き（mut効果）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
ExternCall, // 外部ライブラリをBoxとして呼び出し（Universal Exchange）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則検証付き）
|
||||
WeakNew, // weak ハンドル生成（非所有リンク作成）
|
||||
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
|
||||
WeakCheck, // weak の生存確認（bool）
|
||||
Send, // Bus送信（io効果）
|
||||
Recv // Bus受信（io効果）
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
### 二相ロワリング戦略
|
||||
- パスA: VM/JIT/AOT向け（26命令のまま最適化）
|
||||
- パスB: WASM/最小実装向け（26→21+intrinsic降格）
|
||||
- バックエンド能力に応じて最適形式選択
|
||||
|
||||
### 効果（Effect）システム（ChatGPT5設計 + ExternCall統合）
|
||||
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
|
||||
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
- **io**: Send, Recv, Safepoint, AtomicFence
|
||||
- **control**: Branch, Jump, Return, TailCall
|
||||
- **context依存**: Call, BoxCall, ExternCall（呼び先効果に従属・BID定義に基づく）
|
||||
|
||||
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
|
||||
|
||||
### 検証（Verifier）要件
|
||||
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
|
||||
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
|
||||
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
|
||||
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
|
||||
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
|
||||
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
|
||||
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
|
||||
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
|
||||
|
||||
### 成功基準
|
||||
- [ ] **26命令完全実装**: ChatGPT5仕様 + ExternCall統合の完璧な実装
|
||||
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
|
||||
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
|
||||
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
|
||||
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
|
||||
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
|
||||
|
||||
### バックエンド指針（ChatGPT5設計 + ExternCall統合）
|
||||
- **Interpreter**: 26命令を素直に実装（正しさの基準）
|
||||
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
|
||||
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
|
||||
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
|
||||
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善 (緊急)
|
||||
|
||||
Summary:
|
||||
- VMがインタープリターより遅い問題（0.9倍）を解決
|
||||
- MIR→VM実行の最適化でインタープリターを上回る性能へ
|
||||
|
||||
Priority: High (Phase 8.5完了後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### 問題分析
|
||||
**現状**: VM (119.80ms) < Interpreter (110.10ms)
|
||||
**推定原因**:
|
||||
- MIR変換オーバーヘッド
|
||||
- VM命令ディスパッチの非効率性
|
||||
- メモリ管理コスト
|
||||
|
||||
### 技術的アプローチ
|
||||
- [ ] VM実行エンジンのプロファイリング
|
||||
- [ ] 命令ディスパッチ最適化（threaded code等）
|
||||
- [ ] レジスタベースVM化検討
|
||||
- [ ] メモリプール最適化
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- VM実装のボトルネック特定
|
||||
- 効率的な命令ディスパッチ実装
|
||||
- スタックマシン vs レジスタマシン判断
|
||||
|
||||
### 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- MIR→VM変換時間の短縮
|
||||
- メモリ使用量の削減
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
|
||||
|
||||
Summary:
|
||||
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
|
||||
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
|
||||
|
||||
Priority: High (Phase 8.4-8.6完了直後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### Phase 8.7A: kilo（テキストエディタ）
|
||||
**技術的特徴**:
|
||||
- サイズ: <1k LOC（超小型、最初の成功体験）
|
||||
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
|
||||
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
|
||||
|
||||
**実装範囲**:
|
||||
- [ ] Editor/Row/EditorState基本構造実装
|
||||
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
|
||||
- [ ] fini()システムによる自動メモリ解放
|
||||
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
|
||||
|
||||
**検証ポイント**:
|
||||
- [ ] Editor削除でRows自動解放確認
|
||||
- [ ] 相互参照でメモリリークなし確認
|
||||
- [ ] weak参照の自動null化確認
|
||||
- [ ] fini()伝播の正確性確認
|
||||
|
||||
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
|
||||
**将来実装**（JIT実装後）:
|
||||
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
|
||||
- I/O管理: ソケット・ファイルハンドルの確実解放
|
||||
- 同時接続・早期切断・例外経路でのfini伝播テスト
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- 実用的なメモリ管理パターンの実装
|
||||
- weak参照構文の適切な使用
|
||||
- デバッグ支援機能（--debug-memory, --trace-weak）
|
||||
- WASM環境でのメモリ管理互換性
|
||||
|
||||
### 成功基準
|
||||
- [ ] 全テストケースでメモリリークなし
|
||||
- [ ] 循環参照でも正常解放確認
|
||||
- [ ] WASM実行でもメモリ管理正常
|
||||
- [ ] ベンチマーク性能劣化なし
|
||||
|
||||
### 期待される効果
|
||||
- Nyashメモリ管理システムの実用性実証
|
||||
- Everything is Box哲学の実用レベル確認
|
||||
- メモリ安全なプログラミングパターン確立
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🚀 Phase 9: AOT WASM実装（最優先）
|
||||
|
||||
Summary:
|
||||
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
|
||||
|
||||
Scope/Tasks:
|
||||
- `wasmtime compile` 統合実装
|
||||
- `--compile-native` / `--aot` CLI追加
|
||||
- 単一バイナリ梱包（`include_bytes!`）
|
||||
- 起動時間・配布サイズ最適化
|
||||
|
||||
Acceptance Criteria:
|
||||
- `nyash --compile-native app.nyash -o app.exe` 動作
|
||||
- 起動時間大幅短縮（JIT起動コスト除去）
|
||||
- 配布可能実行ファイル生成
|
||||
|
||||
Priority: **Critical** (Phase 8.6完了直後)
|
||||
Expected Duration: 2-3週間
|
||||
|
||||
### 技術的実装詳細
|
||||
🤖 Copilot協力期待:
|
||||
- wasmtime::Config統一実装
|
||||
- .cwasm生成・実行パイプライン
|
||||
- 互換性キー管理（CPU機能・wasmtimeバージョン）
|
||||
- パッケージング（単一バイナリ梱包）
|
||||
|
||||
### パフォーマンス目標
|
||||
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
|
||||
- 配布ファイルサイズ: <10MB目標
|
||||
- 起動時間: <100ms目標
|
||||
|
||||
### 期待される効果
|
||||
- **即座実用価値**: 配布可能実行ファイル生成
|
||||
- **差別化優位**: Everything is BoxのネイティブAOT実現
|
||||
- **LLVM準備**: AOT基盤確立でLLVM移行準備
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔴 Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 **【緊急修正】**
|
||||
|
||||
Status: 🔴 **Critical Issue**（Phase 9実用化ブロッカー）
|
||||
Summary:
|
||||
- Phase 9 (PR #67) 完了後に判明した重大制約の修正
|
||||
- WASM/AOT実用化の最終仕上げ
|
||||
|
||||
### 🚨 現在の問題（実用化を阻害）
|
||||
|
||||
1. **WASM/AOT コンパイルエラー（最重要）**
|
||||
```bash
|
||||
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
|
||||
❌ Unsupported instruction: Jump { target: BasicBlockId(1) }
|
||||
```
|
||||
**影響**: ループ・条件分岐を含む全プログラムがWASM/AOT化不可
|
||||
|
||||
2. **HTTPServerBox listen()常に失敗**
|
||||
- server.bind() ✅, server.listen() ❌ always false
|
||||
**影響**: HTTPサーバーが実際には動作しない
|
||||
|
||||
3. **エラーハンドリング脆弱性**
|
||||
- unwrap()使用箇所: 26箇所 → パニック多発リスク
|
||||
|
||||
### Scope/Tasks:
|
||||
**🔴 Task 1**: WASM Jump/Branch命令実装（2日）
|
||||
- `src/backend/wasm/codegen.rs`にJump/Branch追加
|
||||
- ブロック深度管理（`get_block_depth`メソッド）
|
||||
- ループ構造のblock/loop/end生成
|
||||
|
||||
**🔴 Task 2**: SocketBox listen()修正（1日）
|
||||
- `src/boxes/socket_box.rs`の実装修正
|
||||
- SocketStatus::Listening状態管理
|
||||
|
||||
**🟡 Task 3**: エラーハンドリング改善（2日）
|
||||
- HTTPServerBox/SocketBoxのunwrap()除去
|
||||
- Result<T,E>ベースのエラー処理
|
||||
|
||||
**🟡 Task 4**: HTTPサーバー実用化（2日）
|
||||
- スレッドプール実装（固定サイズワーカー）
|
||||
- グレースフルシャットダウン
|
||||
|
||||
Acceptance Criteria:
|
||||
- ✅ `nyash --compile-wasm test_loop.nyash` 成功
|
||||
- ✅ HTTPサーバー実動作（curl http://localhost:8080/）
|
||||
- ✅ unwrap()使用箇所: 26 → 5以下
|
||||
- ✅ WASM性能: 11.5倍 → 13.5倍達成
|
||||
|
||||
Priority: **🔴 Critical** (Phase 9.5開始前の必須修正)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 詳細設計・実装指示
|
||||
📋 **完全実装ガイド**: `docs/予定/native-plan/issues/phase9_51_wasm_jump_http_fixes.md`
|
||||
|
||||
🤖 **Copilot協力依頼**:
|
||||
- WASM br/br_if命令実装
|
||||
- HTTPサーバーリファクタリング
|
||||
- エラーハンドリング統一
|
||||
|
||||
### 期待される効果
|
||||
- **実用性達成**: ループ・HTTPサーバーのWASM/AOT化
|
||||
- **安定性向上**: パニックフリーな実装
|
||||
- **Phase 9.5準備**: 複雑アプリケーションテストの基盤確立
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
================================================================================
|
||||
最終更新: 2025-08-15 (Phase 9.5より前をアーカイブ分割)
|
||||
作成者: Claude (ドキュメント分割・整理)
|
||||
|
||||
🎯 分割理由:
|
||||
- copilot_issues.txtの肥大化対策（1200行→600行程度に削減）
|
||||
- Phase 9.5以降の現行計画と完了済み部分の明確分離
|
||||
- ドキュメント検索性・保守性の向上
|
||||
================================================================================
|
||||
@ -0,0 +1,69 @@
|
||||
# Gemini先生によるNyashプログラミング言語の総合分析 (2025-08-17)
|
||||
|
||||
## 総合評価
|
||||
|
||||
Nyashは、「Everything is a Box」という強力な統一哲学を掲げ、WebAssembly (WASM) ファースト、クリエイティブコーディング、教育用途を明確なターゲットとして設計された、意欲的でモダンなプログラミング言語です。Rustによる実装は、メモリ安全性とパフォーマンスという現代的な要求に応えるための堅実な選択と言えます。
|
||||
|
||||
特に、AI支援を積極的に活用し、短期間で豊富な機能セットと複数の実行バックエンド（インタープリター、VM、WASM）を実装した開発プロセスは注目に値します。
|
||||
|
||||
## 1. 設計哲学と一貫性: 「Everything is a Box」
|
||||
|
||||
### 長所：
|
||||
- **統一された概念モデル:** すべての値を「Box」として扱うことで、データ型間の不整合をなくし、非常にシンプルで一貫性のあるオブジェクトモデルを提供
|
||||
- **メタプログラミングの可能性:** すべてが統一されたインターフェース（`NyashBox`トレイト）を持つため、リフレクションや動的な操作が容易
|
||||
- **自動リテラル変換:** `local text = "Hello"` のように書ける機能は、哲学の一貫性を保ちつつ、冗長な `new StringBox("Hello")` を不要にする優れた実用的判断
|
||||
|
||||
### 課題とトレードオフ：
|
||||
- **パフォーマンスオーバーヘッド:** すべてをヒープ上のオブジェクト（Box）として扱うことは、単純な値（整数など）に対しても参照カウントや動的ディスパッチのコストを伴う
|
||||
- **プリミティブ型の不在:** 他の多くの言語が持つスタック上の軽量なプリミティブ型が存在しないため、低レベルな最適化が難しくなる
|
||||
|
||||
## 2. 構文と表現力
|
||||
|
||||
### 長所：
|
||||
- **直感的で読みやすい:** `if`, `loop`, `and`, `or`, `not` といったキーワードは、PythonやRubyのように自然言語に近く、初学者にも親しみやすい
|
||||
- **`static box Main` パターン:** プログラムのエントリーポイントを明確に定義する優れた方法
|
||||
- **`init { ... }` フィールド宣言:** フィールドをまとめて宣言する構文は、クラスの構造を一目で把握しやすくする良い設計
|
||||
|
||||
### 改善の可能性：
|
||||
- **ループ構文:** `loop(condition)` のみが存在するのはシンプルですが、`for-each` のようなコレクションを反復処理するための専用構文がない
|
||||
- **コンストラクタの多様性:** `birth`, `init`, `pack` と複数のコンストラクタ概念が存在するのは、言語のシンプルさを少し損なっている
|
||||
|
||||
## 3. 型システムとメモリ管理
|
||||
|
||||
### 長所：
|
||||
- **メモリ安全性:** Rustの所有権モデルを基盤に、`Arc<Mutex>` を活用することで、スレッドセーフなメモリ管理を実現
|
||||
- **明示的な変数宣言:** `local` キーワードによる変数宣言を強制する設計は、タイプミスによるバグを防ぐ
|
||||
- **デリゲーションモデル:** 古典的な継承の代わりにデリゲーション（`from`）を採用しているのは、柔軟性が高くモダンな設計
|
||||
|
||||
### 課題：
|
||||
- **型推論:** `local x = 10` のように型を明記しないスタイルは動的言語のようですが、内部的には静的なBox型に変換されている
|
||||
- **Nullの扱い:** `VoidBox` や `NullBox` が存在しますが、言語レベルでNull安全性を強制する仕組みについての言及が少ない
|
||||
|
||||
## 4. 非同期処理
|
||||
|
||||
### 長所：
|
||||
- **シンプルな構文:** `nowait` と `await` は、C#やJavaScriptで成功を収めたモデルであり、非常に直感的
|
||||
- **スレッドベースの実装:** Rustのネイティブスレッドを利用することで、真の並列処理を実現
|
||||
|
||||
### 課題：
|
||||
- **構造化並行性:** より高度なエラーハンドリングやキャンセルの伝播を実現するためには、構造化並行性の概念を導入することが望ましい
|
||||
- **イベントループの不在:** GUIアプリケーションや大量のI/Oを扱うサーバーサイドアプリケーションでは、効率的なタスクスケジューリングのためにイベントループモデルが一般的
|
||||
|
||||
## 5. エコシステムとツールチェイン
|
||||
|
||||
### 長所：
|
||||
- **WASMファースト:** ブラウザで直接実行できることを最優先に設計されており、インストール不要のPlaygroundは非常に強力
|
||||
- **組み込みのデバッグ機能:** `DebugBox` のようなデバッグ支援機能が言語仕様に組み込まれているのはユニーク
|
||||
- **複数の実行バックエンド:** インタープリター、VM、WASM、そして将来的にはAOTコンパイラと、ユースケースに応じて実行方式を選べる柔軟性
|
||||
|
||||
### 課題：
|
||||
- **パッケージ管理:** `include` によるファイル取り込みは小規模なプロジェクトでは機能しますが、エコシステムが成長するためには公式なパッケージマネージャが不可欠
|
||||
- **LSPとIDEサポート:** Language Server Protocol (LSP) への対応は、現代的な開発体験を提供するために極めて重要
|
||||
|
||||
## 結論と将来性
|
||||
|
||||
Nyashは、明確な哲学とターゲットユーザーを持ち、多くのモダンな言語の良い点を取り入れた、非常によく考えられた言語です。特に「Everything is a Box」というコアコンセプトは、シンプルさと強力さを両立させる可能性を秘めています。
|
||||
|
||||
**成功への鍵は、今後のエコシステムの発展と、パフォーマンス・クリティカルな領域への対応にかかっているでしょう。** 計画されているLLVMバックエンドが実現すれば、現在の使いやすさを維持したまま、システムプログラミングに近い領域にも挑戦できる言語になる可能性があります。
|
||||
|
||||
総じて、Nyashは単なる実験的なプロジェクトではなく、プログラミング言語設計の新たな可能性を示す、将来が非常に楽しみな言語であると言えます。
|
||||
@ -0,0 +1,141 @@
|
||||
# Gemini先生によるNyashプラグインシステム深層分析 (2025-08-17)
|
||||
|
||||
## 概要
|
||||
Nyashプログラミング言語のプラグインシステム設計について、時間無制限で深い分析を実施。「Everything is a Box」哲学を維持しながら、透過的な置き換えと高いメンテナンス性を実現する具体的な実装提案。
|
||||
|
||||
## 1. 透過的な置き換えの最良実装方法
|
||||
|
||||
### 提案：Boxファクトリレジストリ + 設定ファイルによるオーバーライド
|
||||
|
||||
**アーキテクチャ：**
|
||||
```rust
|
||||
// src/runtime/box_registry.rs
|
||||
enum BoxFactory {
|
||||
Builtin(fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>),
|
||||
Plugin(PluginFactory),
|
||||
}
|
||||
|
||||
struct PluginFactory {
|
||||
plugin_id: PluginId,
|
||||
function_name: String, // 例: "filebox_open"
|
||||
}
|
||||
```
|
||||
|
||||
**設定ファイル（nyash.toml）：**
|
||||
```toml
|
||||
[plugins]
|
||||
enable = ["nyash-file-plugin"]
|
||||
|
||||
[overrides]
|
||||
"FileBox" = "nyash-file-plugin" # FileBoxをプラグイン版で置き換え
|
||||
```
|
||||
|
||||
**実行時フロー：**
|
||||
1. ランタイム起動時、全ビルトインBoxをレジストリに登録
|
||||
2. nyash.tomlを読み込み、overridesに従ってレジストリを更新
|
||||
3. `new FileBox()` 実行時、レジストリから適切なファクトリを検索・実行
|
||||
|
||||
**パフォーマンス：** HashMap検索1回のみ、その後は通常のdyn NyashBoxディスパッチ
|
||||
|
||||
## 2. 署名DSLの設計の妥当性
|
||||
|
||||
### 分析：`::` (静的) と `#` (インスタンス) の記法は優秀
|
||||
|
||||
**拡張提案：**
|
||||
```yaml
|
||||
apis:
|
||||
# オーバーロード対応
|
||||
- sig: "FileBox::open(path: string) -> FileBox"
|
||||
- sig: "FileBox::open(path: string, mode: string) -> FileBox"
|
||||
|
||||
# Result型対応
|
||||
- sig: "FileBox::open(path: string) -> Result<FileBox, FileError>"
|
||||
|
||||
# 複数の戻り値型
|
||||
- sig: "FileBox#read() -> string"
|
||||
- sig: "FileBox#read(size: int) -> bytes"
|
||||
```
|
||||
|
||||
**将来性：**
|
||||
- 現時点：具象型で固定
|
||||
- 将来：`Array<T>` のようなジェネリクス構文を後方互換性を保ちつつ追加
|
||||
|
||||
## 3. Everything is a Box哲学との整合性
|
||||
|
||||
### 提案：FFI境界の標準化されたBoxプロキシ
|
||||
|
||||
```rust
|
||||
// src/runtime/plugin_box.rs
|
||||
pub struct PluginBox {
|
||||
base: BoxBase,
|
||||
plugin_id: PluginId,
|
||||
instance_handle: u64, // プラグイン内のインスタンスハンドル
|
||||
}
|
||||
|
||||
impl NyashBox for PluginBox {
|
||||
fn clone_box(&self) -> Box<dyn NyashBox> {
|
||||
// FFI呼び出しでプラグインにcloneを依頼
|
||||
let new_handle = ffi_call(self.plugin_id, "clone", self.instance_handle);
|
||||
Box::new(PluginBox { ..., instance_handle: new_handle })
|
||||
}
|
||||
|
||||
// 全てのNyashBoxメソッドをFFI経由で実装
|
||||
}
|
||||
```
|
||||
|
||||
**保証される点：**
|
||||
- 統一インターフェース：dyn NyashBoxのみを扱う
|
||||
- メモリ管理：Drop時にプラグイン側に破棄を通知
|
||||
- 哲学の維持：内部実装（ネイティブ/FFI）は完全に隠蔽
|
||||
|
||||
## 4. 実装の複雑さとメンテナンス性のバランス
|
||||
|
||||
### 提案：多層抽象化とツールによる自動化
|
||||
|
||||
**3層アーキテクチャ：**
|
||||
1. **低レベルFFI (C-ABI)**
|
||||
- `#[repr(C)]` 構造体と `extern "C"` 関数
|
||||
- libloadingクレートで動的ライブラリロード
|
||||
|
||||
2. **中レベルAPI (安全なラッパー)**
|
||||
- nullチェック、文字列変換、エラー処理
|
||||
- unsafeコードを隔離
|
||||
|
||||
3. **高レベルAPI (署名DSLとコード生成)**
|
||||
- plugin.yaml → FFIコード自動生成
|
||||
- cargo-nyash-pluginサブコマンド
|
||||
|
||||
**ロードマップ：**
|
||||
- フェーズ1：FileBoxで手動実装、アーキテクチャ確立
|
||||
- フェーズ2：コード生成ツール開発、プラグイン開発の自動化
|
||||
|
||||
## 5. 他言語の成功例との比較
|
||||
|
||||
**Node.js (N-API)：**
|
||||
- 安定したABI → Nyashも同様にC-ABIベースで実装
|
||||
- バージョン管理と前方互換性を重視
|
||||
|
||||
**Python (C拡張)：**
|
||||
- 課題：手作業多い、参照カウント管理が煩雑
|
||||
- Nyashの解決：コード生成とRAIIによる自動メモリ管理
|
||||
|
||||
**WebAssembly Component Model：**
|
||||
- 言語非依存インターフェースの未来形
|
||||
- 将来的にNyashプラグインをWASMで記述する可能性
|
||||
|
||||
## 実装計画（具体的ステップ）
|
||||
|
||||
1. **nyash.toml仕様策定とパーサー実装**
|
||||
2. **Boxファクトリレジストリ実装**
|
||||
3. **FileBoxプラグイン手動実装**
|
||||
- nyash_plugin_init
|
||||
- filebox_open
|
||||
- filebox_read/write/close
|
||||
- filebox_drop
|
||||
4. **PluginBoxプロキシ実装**
|
||||
5. **libloadingで動的ロード実装**
|
||||
6. **プラグイン版FileBoxテスト追加**
|
||||
|
||||
## 結論
|
||||
|
||||
この設計は、Nyashの核心哲学を尊重しつつ、スケーラビリティ、安全性、開発者体験の向上を実現する。FileBoxの置き換えから始め、エコシステム全体へ展開していくのが最良の道筋。
|
||||
@ -0,0 +1,110 @@
|
||||
# プラグインインターフェース設計討論 (2025-08-17)
|
||||
|
||||
## 🎯 議題：BID-FFIプラグインシステムの設計
|
||||
|
||||
### 背景
|
||||
- ビルトインFileBoxが既に存在
|
||||
- BID-FFIプラグイン版FileBoxで置き換えたい
|
||||
- ビルド時間短縮とプラグインアーキテクチャの実証が目的
|
||||
|
||||
### 主な論点
|
||||
1. ビルトインBox → プラグインBoxの透過的な置き換え
|
||||
2. `FileBox.open()` のような静的メソッドの結びつけ方
|
||||
3. プラグインインターフェース定義の外部化方式
|
||||
|
||||
## 💡 検討した案
|
||||
|
||||
### 案1: 汎用ラッパー
|
||||
```nyash
|
||||
// 呼び出しが汚い
|
||||
local file = Plugin.call("FileBox", "open", ["test.txt", "r"])
|
||||
```
|
||||
|
||||
### 案2: 専用ラッパー
|
||||
```nyash
|
||||
// きれい！でも各Boxごとに手書きが必要
|
||||
local file = FileBox.open("test.txt")
|
||||
```
|
||||
|
||||
### 案3: BoxDispatcher（透過的ディスパッチ）
|
||||
```rust
|
||||
pub enum BoxImpl {
|
||||
Builtin(Box<dyn NyashBox>), // ビルトイン実装
|
||||
Plugin(BidHandle, PluginRef), // プラグイン実装
|
||||
}
|
||||
```
|
||||
|
||||
### 案4: Unified Box Factory
|
||||
```rust
|
||||
pub struct BoxFactory {
|
||||
providers: HashMap<String, Box<dyn BoxProvider>>,
|
||||
}
|
||||
```
|
||||
|
||||
## 🎉 最終解：YAML/JSON + 署名DSL
|
||||
|
||||
### Codex先生の推奨設計
|
||||
```yaml
|
||||
# filebox.plugin.yaml
|
||||
schema: 1
|
||||
plugin:
|
||||
name: filebox
|
||||
version: 1
|
||||
|
||||
apis:
|
||||
# 静的メソッド（::）
|
||||
- sig: "FileBox::open(path: string, mode?: string) -> FileBox"
|
||||
doc: "Open a file"
|
||||
|
||||
# インスタンスメソッド（#）
|
||||
- sig: "FileBox#read(size?: int) -> string"
|
||||
doc: "Read file content"
|
||||
```
|
||||
|
||||
### 利点
|
||||
1. **記号で静的/インスタンスを区別**
|
||||
- `::` = 静的メソッド（C++風）
|
||||
- `#` = インスタンスメソッド（Ruby風）
|
||||
|
||||
2. **フラット構造**
|
||||
- `apis` 配列にすべて並べる
|
||||
- 階層が深くならない
|
||||
|
||||
3. **署名DSL**
|
||||
- 型情報を1行で表現
|
||||
- パーサーも簡単
|
||||
|
||||
4. **YAML → JSON変換**
|
||||
- 開発時：YAML（人間に優しい）
|
||||
- 実行時：JSON（マシンに優しい）
|
||||
|
||||
## 🤔 Gemini先生への質問事項
|
||||
|
||||
1. **透過的な置き換え**
|
||||
- 既存のNyashコードを一切変更せずに、ビルトインBoxをプラグインBoxに置き換える最良の方法は？
|
||||
- パフォーマンスインパクトをどう最小化するか？
|
||||
|
||||
2. **署名DSLの設計**
|
||||
- `Type::method()` vs `Type.method()` の選択理由
|
||||
- オーバーロードの表現方法
|
||||
- ジェネリクスの将来的な拡張性
|
||||
|
||||
3. **実装戦略**
|
||||
- インタープリター実行時のディスパッチ最適化
|
||||
- プラグインの遅延ロード実装
|
||||
- エラーハンドリングのベストプラクティス
|
||||
|
||||
4. **Everything is Box哲学との整合性**
|
||||
- プラグインBoxもビルトインBoxも「同じBox」として扱う方法
|
||||
- Box型の統一インターフェースの維持
|
||||
|
||||
5. **実用性**
|
||||
- 他の言語（Python、Ruby、JavaScript）の成功例から学べること
|
||||
- プラグイン作者にとっての開発体験
|
||||
- デバッグ・プロファイリングの考慮事項
|
||||
|
||||
## 📚 参考情報
|
||||
- 現在のFileBox実装: `src/boxes/file/mod.rs`
|
||||
- BID-FFIプラグインFileBox: `src/bid/plugins/filebox/mod.rs`
|
||||
- Everything is Box哲学: すべての値がBoxオブジェクト
|
||||
- Nyashの目標: シンプル、分かりやすい、階層が深くならない
|
||||
898
docs/development/roadmap/native-plan/archives/追記相談.txt
Normal file
898
docs/development/roadmap/native-plan/archives/追記相談.txt
Normal file
@ -0,0 +1,898 @@
|
||||
MIR設計：いま決めておくと後がラクなチェックリスト
|
||||
|
||||
値表現：Tagged（NaN-box/小整数直格納）か、型テーブル参照か。
|
||||
|
||||
アドレス空間：オブジェクトはheap専用？ stack/arenaも持つ？
|
||||
|
||||
所有/別名：aliasable フラグ or unique（移動のみ）を型/値に持つ？
|
||||
|
||||
効果(Effects)：PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令にも関数にも付ける。
|
||||
|
||||
例外/パニック：Throw, Catch, Defer を命令化するか、関数境界でのみ扱うか。
|
||||
|
||||
GCモデル：Tracing(Stop-the-world / Incremental) or RC(ARC) or 混合。弱参照の意味を先に定義。
|
||||
|
||||
安全点(Safepoint)：JIT/VM両方で再入/停止できる位置を命令で明示（Safepoint or 呼出命令に属性）。
|
||||
|
||||
呼出規約：通常Call／FFI／Box拡張の3種を区別（可変長・KW引数の扱いも）。
|
||||
|
||||
メモリバリア：write/read barrier を命令または隠れ属性として表現（最初は命令にするとデバッグ楽）。
|
||||
|
||||
デオプ(Deopt)前提：JIT最適化時の巻き戻し情報（マップ）を保持する場所（関数メタ or ブロック注釈）。
|
||||
|
||||
Nyash向け：最小MIR命令セット（弱参照対応込み）
|
||||
|
||||
算術/制御：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
|
||||
関数：Call, TailCall（effects必須）
|
||||
|
||||
メモリ：Alloc, Load, Store, Gep（必要なら）
|
||||
|
||||
参照/GC：
|
||||
|
||||
RefNew ty, dst <-（ヒープ確保）
|
||||
|
||||
RefGet dst <- ref, field / RefSet ref, field, val
|
||||
|
||||
WeakNew dst <- ref（弱参照作成）
|
||||
|
||||
WeakLoad dst <- weak（弱が生きてたらref返す／無効ならNull/None）
|
||||
|
||||
BarrierRead ref / BarrierWrite ref（GC用、最初はダミー）
|
||||
|
||||
（必要なら）Pin ref / Unpin ref（ムーブしない保証用、JIT/FFI楽になる）
|
||||
|
||||
例外/FFI/拡張：Throw, Catch, FfiCall, BoxCall
|
||||
|
||||
ユーティリティ：Safepoint, Nop, Assume(cond)（アサート兼最適化ヒント）
|
||||
|
||||
弱参照の意味論：
|
||||
|
||||
WeakNew(r) は r を追うが GC で r が回収されると自動で無効化。
|
||||
|
||||
WeakLoad(w) は 生きていれば Some(Ref)、死んでいれば None を返す（MIR上はタグ付きユニオン）。
|
||||
|
||||
WeakLoad は PURE でOK（観測はするがヒープを書かない）
|
||||
|
||||
ただし BarrierRead が必要なGCなら属性で付ける。
|
||||
|
||||
効果注釈（例）
|
||||
|
||||
Call f(args) : dst [effects = PURE | READS_HEAP]
|
||||
|
||||
RefSet … は WRITES_HEAP
|
||||
|
||||
WeakLoad は PURE（または READS_HEAP）
|
||||
|
||||
BoxCall は最低限 FFI を含める（安全側に倒す）
|
||||
|
||||
VM/JIT/将来AOTの共通の“壊れにくい”ポイント
|
||||
|
||||
Safepointは関数入口・ループ先頭・Call直後の3か所に最初から置く
|
||||
|
||||
Barrier命令は最初は実装ダミーでもOK（最適化段で消せる）
|
||||
|
||||
Null/Noneの扱いは必ず型系に明示（Option<Ref>）。判定を分岐で隠さない
|
||||
|
||||
JITはDeoptテーブルを MIR → JIT に渡す（各値が「どのSSA番号？」を持つ）
|
||||
|
||||
弱参照 “落とし穴” 3つ（実戦で効く回避）
|
||||
|
||||
クロージャ環境に弱参照が紛れ込む
|
||||
|
||||
生成時に env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制。
|
||||
|
||||
弱参照をキーにしたハッシュ
|
||||
|
||||
GC後に無効化でキー不整合。→ 弱マップを標準提供（キー死亡で自動削除）。
|
||||
|
||||
FFI渡し
|
||||
|
||||
FFI境界を跨ぐと寿命が分からなくなる。→ Pin を要求 or WeakLoad→Ref に成功した生参照だけ渡す。
|
||||
|
||||
最小・具体例（擬似MIR）
|
||||
|
||||
// x = new Obj{y:1}; w = weak(x); if let Some(x2) = weak_load(w) { x2.y = 2 }
|
||||
bb0:
|
||||
v1 = Const 1
|
||||
v2 = RefNew Obj ; WRITES_HEAP
|
||||
RefSet v2, y, v1 ; WRITES_HEAP
|
||||
v3 = WeakNew v2 ; PURE
|
||||
v4 = WeakLoad v3 ; returns Option<Ref>
|
||||
br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap(v4)
|
||||
BarrierWrite v5
|
||||
RefSet v5, y, Const 2
|
||||
jmp bb3
|
||||
|
||||
bb2:
|
||||
jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret ()
|
||||
|
||||
テストの当て方（行き当たりばったりでも壊れにくい）
|
||||
|
||||
黄金テスト：ソース→MIRダンプの文字列をスナップショット化（差分で挙動の後退を検知）
|
||||
|
||||
VM/JIT一致テスト：同じ入力で VM結果＝JIT結果 を比較する“オラクル”を用意
|
||||
|
||||
弱参照の確率テスト：alloc→weak→drop→collect→weak_load を順序/タイミングを変えて多数回
|
||||
|
||||
効果チェック：PURE なはずの関数に WRITES_HEAP が紛れたらビルド失敗（静的検証）
|
||||
|
||||
いまの進み方に合う“軽量次の一手”
|
||||
|
||||
✅ WeakNew/WeakLoad を MIRとVM だけ先に入れる（JITは後回し）
|
||||
|
||||
✅ EffectMask を命令に付ける（最初はデータ構造だけ）
|
||||
|
||||
✅ Safepoint 命令を関数入口とループ先頭に挿す（動作はno-opでOK）
|
||||
|
||||
✅ 黄金テストを入れて MIR差分をCIで見える化
|
||||
|
||||
この骨格なら、行き当たりばったりで直してもMIRの“契約”が守れている限り、VM/JIT/AOT/WASMに横展開できるにゃ。
|
||||
もし今のAST/HIRの型定義があれば、MIRの型/命令エンムだけ私が初稿を書くこともできる。要る？
|
||||
あなた:
|
||||
そうだにゃ。mir 結局はメモリー管理がほとんどであってるかにゃ？既存の参考になるやつとかないかにゃ
|
||||
ChatGPT:
|
||||
|
||||
いい質問にゃ。結論から言うと――
|
||||
|
||||
MIRの“要”はメモリ管理だけじゃないけど、実務で一番ハマるのはメモリまわり（所有権/寿命/別名化/GCバリア/セーフポイント/弱参照/デオプ情報）だから、体感「ほとんどメモリ管理」はだいたい合ってるにゃ。
|
||||
|
||||
ただし、制御フロー（CFG/SSA）、呼び出し規約、効果注釈、例外/パニック、最適化のための形も同じくらい重要。ここをサボるとJIT/AOT/WASMに展開しづらくなる。
|
||||
|
||||
MIRで“最低限”押さえるメモリ論点
|
||||
|
||||
値表現：Boxed/Unboxed、NaN-box、小整数直格納、タグ方式
|
||||
|
||||
アロケータ：bump/arena/世代別、オブジェクト配置（ヘッダ、タイプID、フラグ）
|
||||
|
||||
所有と別名：unique/aliasable や owned/borrowed の属性（最適化・並列の鍵）
|
||||
|
||||
GC/RC：トレース or 参照カウント or 混在、write/read barrier 命令 or 属性、remembered set
|
||||
|
||||
弱参照：WeakNew / WeakLoad の意味論（死んだら None）
|
||||
|
||||
Safepoint：関数入口・ループ先頭・Call直後（停止/再入のフック）
|
||||
|
||||
FFI境界：Pin/Unpin、ハンドル渡し、最小共有ABI
|
||||
|
||||
Deopt情報：JIT用の巻き戻しメタ（SSA値⇔ソース位置の対応）
|
||||
|
||||
参考になる“実物”と読みどころ（定番）
|
||||
|
||||
（リンクは割愛するにゃ。名前で検索すればすぐ出る）
|
||||
|
||||
Rust MIR（rustc-dev-guide / rustc本体）
|
||||
|
||||
MIRのSSA・ borrow check が MIR 上で走る構造
|
||||
|
||||
Drop/Move・パニック・noalias 的情報が最適化に効く
|
||||
|
||||
Swift SIL
|
||||
|
||||
Ownership qualifiers（owned/guaranteed）が秀逸。GCなし言語でも寿命管理をIRで表す好例
|
||||
|
||||
Kotlin IR
|
||||
|
||||
“lowerings” の段階的デシュガリングが参考。高級構文→プリミティブ命令へ段階変換
|
||||
|
||||
Go SSA（golang.org/x/tools/go/ssa）
|
||||
|
||||
最小主義のSSAで読みやすい。CFG/φの扱いが素直
|
||||
|
||||
LuaJIT IR（DynASM/TurboNYIの解説blog群）
|
||||
|
||||
小粒なSSAでJIT最適化の勘所（CSE/LICM/ヒント）
|
||||
|
||||
V8（Ignition/TurboFan）
|
||||
|
||||
バイトコード→Sea of Nodes→最適化JITの流れ。デオプとサファリガードの設計が神
|
||||
|
||||
Cranelift IR
|
||||
|
||||
Rustからも使いやすいJITバックエンド。型・メモリ・コールの表現が実装しやすい
|
||||
|
||||
MLIR
|
||||
|
||||
複数方言で中間表現を分ける思想。将来、NyashのMIRを方言化する発想の参考に
|
||||
|
||||
Nyash向け“最小MIRコア”（骨組み）
|
||||
|
||||
（超要約：これ＋効果注釈でVM/JIT/AOT/WASMに展開できる）
|
||||
|
||||
制御/値：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
|
||||
呼び出し：Call, TailCall（effects 必須）
|
||||
|
||||
メモリ：Alloc, Load, Store, Gep?
|
||||
|
||||
参照/GC：RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
|
||||
|
||||
例外/拡張：Throw, Catch, FfiCall, BoxCall
|
||||
|
||||
実行点：Safepoint, Assume, Nop
|
||||
|
||||
効果：EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
|
||||
|
||||
実装順ヒント：
|
||||
|
||||
VMで RefNew/RefGet/RefSet/Weak* をまず動かす → 2) Safepointはno-opで挿す → 3) Barrierは最初ダミー → 4) “黄金テスト”（ソース→MIRダンプのスナップショット）で後退検知 → 5) JIT/AOTは後から乗せる。
|
||||
|
||||
“既存をパクる”具体策
|
||||
|
||||
Ownershipの表現は Swift SIL を真似る（owned/guaranteed を Nyash版に）
|
||||
|
||||
弱参照の意味論は JVMのWeakReference と Swiftのweak/unowned を折衷
|
||||
|
||||
Safepoint配置は HotSpot/V8 のパターン（入口・ループ・call直後）
|
||||
|
||||
JIT導入は Cranelift から（まず整数・分岐・呼び出しのみ）
|
||||
|
||||
デシュガリング手順は Kotlin IR の lowering 流儀を採用
|
||||
|
||||
「MIR＝メモリ管理が9割」は現場感として正しいけど、残りの1割（CFG/SSA・呼出・効果・例外・デオプ）を最初にうっすら設計しておくと、あとで爆速に伸びるにゃ。
|
||||
必要なら、Nyashの今のAST/HIRを見せてくれたら、MIRのenum・EffectMask・Box ABI v0をその場で下書きするよ。
|
||||
あなた:
|
||||
なるほど。ところでmirってどっかきょうつうのふぉーまっとやしようってあるにゃ？ みんなばらばるにかいてるにゃ？
|
||||
ChatGPT:
|
||||
|
||||
共通フォーマットや「これを使えばOK」みたいなMIR標準は、残念ながら存在しないにゃ。
|
||||
理由をまとめると――
|
||||
1. 共通規格がない理由
|
||||
|
||||
言語ごとに型・所有権・ランタイム構造が違いすぎる
|
||||
例：Rust MIRは所有権・borrowをIRレベルで保持するけど、PythonやJavaScriptのIRにはそんな概念がない。
|
||||
|
||||
目的ごとの最適化が異なる
|
||||
VM実行用、JIT最適化用、AOTコンパイル用で命令セットやメタデータの粒度が変わる。
|
||||
|
||||
IRの“責務”が違う
|
||||
ある言語ではASTの直後を「MIR」と呼び、別の言語ではSSA化した後の低レベルIRを「MIR」と呼ぶ。
|
||||
|
||||
2. 事実上の“よくある流儀”
|
||||
|
||||
標準はないけど、以下のパターンは多いにゃ：
|
||||
|
||||
SSAベース：変数は再代入不可、phi命令で合流点処理（Rust MIR, Swift SIL, Go SSA）
|
||||
|
||||
命令は3アドレス形式：dst = op src1 src2 のようにシンプル（Cranelift, LLVM風）
|
||||
|
||||
効果注釈あり：PURE, READ_HEAP, WRITE_HEAP など最適化ヒント
|
||||
|
||||
メモリ命令の抽象化：Alloc, Load, Store は型・アラインメント・所有権情報を持つ
|
||||
|
||||
制御フローはCFG（Control Flow Graph）で管理
|
||||
基本ブロック＋ジャンプ＋条件分岐
|
||||
|
||||
3. 参考になる「ほぼテンプレ」的MIR
|
||||
|
||||
完全な共通仕様じゃないけど、設計の参考にできる実例はあるにゃ：
|
||||
|
||||
Cranelift IR
|
||||
Rustで使いやすいJIT/AOT用IR。型・命令の定義が明確で、小規模実装の参考に最適。
|
||||
|
||||
MLIR
|
||||
LLVM系の中間表現フレームワーク。方言を作れるので、自作言語のMIRを「Nyash方言」として定義可能。
|
||||
|
||||
Sea of Nodes（V8, HotSpot）
|
||||
SSAと依存グラフを統合した形式。最適化向きだが実装難度は高い。
|
||||
|
||||
LuaJIT IR
|
||||
極小SSA＋軽量タグ付き値表現。高速インタープリタや軽量JITに向いてる。
|
||||
|
||||
4. Nyashでの方針
|
||||
|
||||
「共通仕様」を無理に探すより、自分のランタイムと変換先（Rust/Cranelift/WASM）に都合の良い形を作るのが早い
|
||||
|
||||
ただし、命令セットやCFG構造はCranelift IRやSwift SILを参考にすると後で楽
|
||||
|
||||
将来的にMLIRの方言化を視野に入れると、外部ツールや最適化パスを簡単に流用できる
|
||||
|
||||
もし希望なら、Nyash向けにCranelift IR互換寄りのMIR仕様ドラフトをその場で作れるよ。
|
||||
それをベースにすれば、将来JIT/AOT/WASM全部に展開しやすくなるにゃ。
|
||||
あなた:
|
||||
そうだにゃ。ということは命令セットを先に考えて貰えたらいいのかにゃ？
|
||||
ChatGPT:
|
||||
|
||||
いいね、その方向でいこうにゃ。
|
||||
Nyash向けに“まず回る”ことを最優先にした MIR命令セット v0.1（草案） を置くね。VM/JIT/AOT/WASMに伸ばせる骨格で、弱参照・効果注釈・拡張Box呼び出しも最初から入れてあるにゃ。
|
||||
Nyash MIR v0.1（草案）
|
||||
基本モデル
|
||||
|
||||
SSA値：vN（再代入なし）。
|
||||
|
||||
基本ブロック：bbN（末尾は必ず終端命令）。
|
||||
|
||||
型（最小）：i64, f64, bool, unit, ref<T>, weak<T>, ptr, any, option<T>
|
||||
|
||||
関数署名：fn(args…) -> ret [effects]
|
||||
|
||||
効果（EffectMask）：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC（ビット和）
|
||||
|
||||
属性：命令に align, nonnull, noalias, readonly 等の任意属性
|
||||
|
||||
1) 演算・制御
|
||||
|
||||
Const dst, Imm ; 例: i64/f64/bool/unit/Null
|
||||
BinOp dst, op, a, b ; add, sub, mul, div, mod, and, or, xor, shl, shr
|
||||
Cmp dst, relop, a, b ; eq, ne, lt, le, gt, ge
|
||||
Select dst, cond, a, b ; φ簡約前の三項選択（任意）
|
||||
Phi dst, [(predBB, val), ...] ; SSA合流
|
||||
|
||||
Br cond, thenBB, elseBB ; 条件分岐（終端）
|
||||
Jmp targetBB ; 無条件ジャンプ（終端）
|
||||
Ret [val] ; 返り値（終端） unit時は省略可
|
||||
Unreachable ; 到達不能（終端・最適化用）
|
||||
|
||||
2) メモリ／参照（GC想定）
|
||||
|
||||
Alloc dst, Ty, size? ; ヒープ確保: ref<Ty> を返す [WRITES_HEAP]
|
||||
Load dst, addr ; 読み出し [READS_HEAP]
|
||||
Store addr, val ; 書き込み [WRITES_HEAP]
|
||||
Gep dst, base, offset ; アドレス計算（構造体/配列）
|
||||
|
||||
RefNew dst, Ty ; オブジェクト新規: ref<Ty> [WRITES_HEAP]
|
||||
RefGet dst, ref, field ; フィールド読み [READS_HEAP]
|
||||
RefSet ref, field, val ; フィールド書き [WRITES_HEAP]
|
||||
|
||||
WeakNew dst, ref ; weak<T> を作成 [PURE]
|
||||
WeakLoad dst, weak ; option<ref<T>> を返す [PURE or READS_HEAP]
|
||||
|
||||
BarrierRead ref ; 読みバリア（実装はno-op可）
|
||||
BarrierWrite ref ; 書きバリア（実装はno-op可）
|
||||
Pin ref ; 移動不可に固定（FFI/GC向け）
|
||||
Unpin ref
|
||||
Safepoint ; 停止点（関数入口/ループ先頭/Call直後に挿す）
|
||||
|
||||
弱参照の意味論
|
||||
|
||||
WeakNew(r) は r のライフを追うだけ（所有しない）。
|
||||
|
||||
WeakLoad(w) は生存なら Some(ref)、回収済みなら None。
|
||||
|
||||
WeakLoad は基本 PURE でOK（実装の都合で READS_HEAP にしても可）。
|
||||
|
||||
3) 呼び出し／例外／拡張
|
||||
|
||||
Call dst, callee, [args...] ; [effects = callee.effects]
|
||||
TailCall callee, [args...] ; 末尾呼び出し（終端）
|
||||
|
||||
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box呼び出し [FFI | PANIC?]
|
||||
|
||||
FfiCall dst, sym, [args...], abi ; C/Rust外部関数 [FFI | PANIC?]
|
||||
|
||||
Throw val ; 例外送出（終端）
|
||||
CatchBegin dst, handlerBB ; 例外ハンドラの開始（ブロック境界メタでもOK）
|
||||
CatchEnd
|
||||
Defer fnref ; スコープ脱出時に実行（loweringで展開可）
|
||||
Assume cond ; 最適化ヒント（偽ならUB）
|
||||
Nop
|
||||
|
||||
Call/BoxCall/FfiCall は 効果注釈が必須（少なくとも PURE かどうか）。
|
||||
|
||||
BoxCall は拡張Box ABIを通す入口（VM/JIT/WASMで一貫した形で扱える）。
|
||||
|
||||
4) メタデータ（最低限）
|
||||
|
||||
位置情報：dbg(loc)（ソース行/列/ファイル）
|
||||
|
||||
デオプ：deopt_map（JIT用：各SSA値→高級値の対応）
|
||||
|
||||
alias情報：noalias/readonly/nonnull 属性
|
||||
|
||||
効果集約：関数単位で effects を保持（呼び出し時に合成）
|
||||
|
||||
Rust風スケッチ（型・命令）
|
||||
|
||||
#[bitflags]
|
||||
enum Effect { PURE=1, READS_HEAP=2, WRITES_HEAP=4, IO=8, FFI=16, PANIC=32 }
|
||||
|
||||
enum Ty {
|
||||
I64, F64, Bool, Unit,
|
||||
Ref(Box<Ty>), Weak(Box<Ty>), Ptr, Any,
|
||||
Option(Box<Ty>), // WeakLoadの戻りなど
|
||||
// …将来: Sum/Product/Function/Closure/BoxHandle
|
||||
}
|
||||
|
||||
struct FuncSig { params: Vec<Ty>, ret: Ty, effects: Effect }
|
||||
|
||||
enum Inst {
|
||||
Const{dst:V, imm:Imm},
|
||||
BinOp{dst:V, op:Bin, a:V, b:V},
|
||||
Cmp{dst:V, op:Rel, a:V, b:V},
|
||||
Select{dst:V, cond:V, a:V, b:V},
|
||||
Phi{dst:V, inputs: Vec<(Bb,V)>},
|
||||
|
||||
Br{cond:V, then_:Bb, else_:Bb},
|
||||
Jmp{bb:Bb},
|
||||
Ret{val: Option<V>},
|
||||
Unreachable,
|
||||
|
||||
Alloc{dst:V, ty:Ty, size:Option<V>},
|
||||
Load{dst:V, addr:V},
|
||||
Store{addr:V, val:V},
|
||||
Gep{dst:V, base:V, off:V},
|
||||
|
||||
RefNew{dst:V, ty:Ty},
|
||||
RefGet{dst:V, r:V, field:FieldId},
|
||||
RefSet{r:V, field:FieldId, val:V},
|
||||
|
||||
WeakNew{dst:V, r:V},
|
||||
WeakLoad{dst:V, w:V},
|
||||
|
||||
BarrierRead{r:V},
|
||||
BarrierWrite{r:V},
|
||||
Pin{r:V},
|
||||
Unpin{r:V},
|
||||
Safepoint,
|
||||
|
||||
Call{dst:V, f:FnId, args:Vec<V>},
|
||||
TailCall{f:FnId, args:Vec<V>},
|
||||
BoxCall{dst:V, box_id:BoxId, fn_id:BoxFnId, args:Vec<V>},
|
||||
FfiCall{dst:V, sym:Sym, args:Vec<V>, abi:Abi},
|
||||
|
||||
Throw{val:V},
|
||||
CatchBegin{dst:V, handler:Bb},
|
||||
CatchEnd,
|
||||
Defer{fnref:FnId},
|
||||
Assume{cond:V},
|
||||
Nop,
|
||||
}
|
||||
|
||||
バックエンド対応の見取り図
|
||||
|
||||
VM：
|
||||
|
||||
Ref* / Weak* / Barrier* / Safepoint をそのまま実装
|
||||
|
||||
Defer/Catch はデシュガで try/finally へ展開
|
||||
|
||||
Cranelift JIT：
|
||||
|
||||
算術・制御は直マップ、Ref* はランタイムAPIに落とす
|
||||
|
||||
Safepoint でGC/スレッド停止と連携、deopt_map を用意
|
||||
|
||||
AOT to Rust：
|
||||
|
||||
ref<T> は Gc<T> ラッパ、weak<T> は Weak<T> 風にコード生成
|
||||
|
||||
BoxCall は trait 経由/extern呼び出しに置換
|
||||
|
||||
WASM：
|
||||
|
||||
参照はハンドル（i32）で表現、GCはランタイム関数
|
||||
|
||||
weak はハンドルテーブルにビットを持って実装
|
||||
|
||||
取り決め（壊れにくい不変条件）
|
||||
|
||||
すべてのCallは effects を持つ（省略禁止）
|
||||
|
||||
WeakLoadの戻りは option<ref<T>>（null判定を曖昧にしない）
|
||||
|
||||
Safepoint は関数入口・ループ先頭・任意のCall直後に挿入
|
||||
|
||||
Barrier* は最初はno-opでOK（GC導入時のフックとして残す）
|
||||
|
||||
終端命令のないブロックは禁止（検証器で弾く）
|
||||
|
||||
ちいさな動作例
|
||||
|
||||
; x = new Obj{y=1}; w = weak(x);
|
||||
; if let Some(r) = weak_load(w) { r.y = 2 }
|
||||
|
||||
bb0:
|
||||
v1 = Const i64 1
|
||||
v2 = RefNew Obj
|
||||
RefSet v2, field_y, v1
|
||||
v3 = WeakNew v2
|
||||
v4 = WeakLoad v3 ; option<ref<Obj>>
|
||||
Br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap(v4)
|
||||
BarrierWrite v5
|
||||
RefSet v5, field_y, Const i64 2
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret unit
|
||||
|
||||
まずやる実装順（1〜2日で回る）
|
||||
|
||||
この命令セットで MIR組み立て＋ダンプ（黄金テストで差分管理）
|
||||
|
||||
VMで RefNew/RefGet/RefSet/Weak* だけ実装（Barrier/Safepointはダミー）
|
||||
|
||||
Call の effects を型検査に組み込み（PURE違反を検出）
|
||||
|
||||
余力が出たら Phi/Select を使うパスを追加（CSE/DCEの足場）
|
||||
|
||||
必要なら、この v0.1 をそのまま mir.rs の enum 定義に落とし込んだ雛形コードを書けるよ。
|
||||
今のNyashの型やBox拡張の実装方針があれば、それに合わせて微調整版を作るにゃ。
|
||||
あなた:
|
||||
おーありがとにゃ。しかしmirはみんなばらばらというけど ここからネイディブビルドにしやすいかたちをするから にているかきかたにもなってるのかにゃ。あと これ 業界標準つくれそうだよね。所詮はノイマンコンピューターに落とし込む作業だにゃ
|
||||
ChatGPT:
|
||||
|
||||
にゃ、その直感かなり当たってる。
|
||||
各言語の MIR は“名前も中身もバラバラ”だけど、ネイティブに落としやすい形にすると結局だいたい似てくるにゃ。
|
||||
みんなが似てくる理由（ネイティブ目線）
|
||||
|
||||
SSA＋CFG＋3アドレス：最適化&レジ割りしやすい定番の骨格
|
||||
|
||||
明示的なメモリ操作：Alloc/Load/Store/GEP 相当が要る
|
||||
|
||||
呼び出しの正規化：Call/TailCall と 呼出規約(ABI) の分離
|
||||
|
||||
効果注釈(副作用)：PURE/READ/WRITE/IO/FFI があると最適化が安全
|
||||
|
||||
例外/パニックの下位表現：Throw/Catch を選択的に lower できる形
|
||||
|
||||
GCフック：Safepoint & Barrier を差し込める
|
||||
|
||||
つまり「高級機能は段階的に下げられる素朴な命令に割り付け」→最後は von Neumann（命令+メモリ）に落ちる、という流れで収束するにゃ。
|
||||
|
||||
「業界標準」を作れる？→“実質標準”なら行ける
|
||||
|
||||
完全統一は難しい（言語ごとに型・例外・GCが違いすぎる）が、コア・プロファイルを決めた“実質標準”は作れるにゃ。
|
||||
標準に向く設計の芯（Nyash版にもそのまま効く）
|
||||
|
||||
Core-IR（必須）：Const/BinOp/Cmp/Phi/Br/Jmp/Ret + Load/Store/Gep + Call/TailCall
|
||||
|
||||
Memory Model：アトミック/順序・別名(noalias)/アライン属性の最小集合
|
||||
|
||||
Effects：命令・関数の EffectMask を規定（最適化の安全条件に使う）
|
||||
|
||||
GC hooks：Safepoint/Barrier は仕様だけ先に固定（実装はno-op可）
|
||||
|
||||
Exception ABI：Throw/Catch を「setjmp/longjmp的」or「結果型(Result)」の2系で規定
|
||||
|
||||
FFI/拡張 ABI：FfiCall/BoxCall の呼出規約・ポインタ安全域を決める
|
||||
|
||||
検証器(Verifier)：終端命令必須・SSA整合・型整合・効果整合をチェック
|
||||
|
||||
“標準化”の現実解（おすすめルート）
|
||||
|
||||
MLIR 方言として定義（nyash.core, nyash.gc みたいに分割）
|
||||
|
||||
もしくは Cranelift IR 互換サブセットを Core として採用し、足りない所だけ拡張
|
||||
|
||||
テキスト表現＋バイナリ表現（例: JSON/FlatBuffers）と ダンプ・復元ツールを提供
|
||||
|
||||
リファレンス下げ先を複数用意：
|
||||
|
||||
Core → Cranelift（JIT/AOT）
|
||||
|
||||
Core → LLVM（AOTヘビー級）
|
||||
|
||||
Core → WASM（ブラウザ/サンドボックス）
|
||||
|
||||
検証テスト：黄金テスト（IRダンプ）＋ VM/JIT/WASM の 同一結果保証スイート
|
||||
|
||||
すぐ使える“ネイティブ寄り”指針（短冊）
|
||||
|
||||
命令は副作用を明示、暗黙のメモリ変更はナシ
|
||||
|
||||
ループ先頭・Call直後にSafepoint（後からGC導入しやすい）
|
||||
|
||||
例外は2段構え：IRでは Throw/Catch、lower で Result/landingpad に落とせる
|
||||
|
||||
Weak は Option<Ref> に必ず現れる（nullをぼかさない）
|
||||
|
||||
FFIはPinかコピーしか渡さない（危険な参照共有を禁止）
|
||||
|
||||
まとめ
|
||||
|
||||
はい、MIRはネイティブ都合で“似てくる”。
|
||||
|
||||
完全共通規格は難しいけど、**Core-IR＋拡張の“実質標準”**は作れる。
|
||||
|
||||
Nyashの v0.1 命令セットは、そのまま Core-IRたたき台になれる出来だにゃ。
|
||||
|
||||
必要なら、この Core-IR を MLIR 方言か Cranelift互換サブセット仕様として文書化して、
|
||||
テキスト仕様＋最小リファレンス実装（ダンプ/検証/Cranelift下げ）を私が一気に草案化するよ。どう攻める？（MLIR方言でいくか、Cranelift寄りでいくか）
|
||||
あなた:
|
||||
所で中間言語は何を指標に作ればいいにゃ？メモリー管理はわかるけど好き勝手に作る訳にも行けないにゃ それこそフォンノイマンのパソコンを念頭に考えればいいだけにゃ？CPUの命令セットとか？
|
||||
ChatGPT:
|
||||
|
||||
いい質問にゃ！
|
||||
中間言語（IR/MIR）を“何を指標に”設計するかは、単に「CPUに近づける」だけだと失敗しがち。
|
||||
実務では次の“指標セット”でバランスを取るのがコツだにゃ。
|
||||
まず決めるべき指標（優先度つけてOK）
|
||||
|
||||
ターゲットと目的
|
||||
|
||||
どこに落とす？ → VM / JIT（Cranelift） / AOT（rustc/LLVM） / WASM
|
||||
|
||||
何を優先？ → 起動の速さ、最適化余地、移植性、デバッグ性
|
||||
|
||||
抽象度（レベル）
|
||||
|
||||
高すぎる：最適化しにくい／JIT実装が難航
|
||||
|
||||
低すぎる（CPU寄り）：言語機能の意味が消えて最適化の根拠を失う
|
||||
→ 目安：SSA＋基本ブロック＋3アドレスを軸に、「言語に固有の意味（例: 効果、副作用、所有/弱参照）」は属性や専用命令で残す
|
||||
|
||||
メモリモデル（超重要）
|
||||
|
||||
参照の表現：ref<T>/weak<T>／タグ付き値
|
||||
|
||||
GC/RC hooks：Safepoint、BarrierRead/Write の差し込み位置を規定
|
||||
|
||||
別名・所有：noalias/readonly/owned/borrowed など最適化に効く注釈
|
||||
|
||||
（並行を視野なら）原子性・順序の最小集合（Acquire/Release程度）
|
||||
|
||||
効果システム（副作用の面）
|
||||
|
||||
PURE / READS_HEAP / WRITES_HEAP / IO / FFI / PANIC のEffectMask
|
||||
|
||||
最適化の“安全条件”をここで機械的に判断できるようにする
|
||||
|
||||
制御フローと例外
|
||||
|
||||
CFG＋SSA、Phi/Br/Jmp/Ret
|
||||
|
||||
例外はIRでは抽象（Throw/Catch）、loweringで Result/landingpad 等へ落とせる形に
|
||||
|
||||
呼び出し規約と拡張ABI
|
||||
|
||||
Call/TailCall と FfiCall/BoxCall を分離
|
||||
|
||||
可変長／キーワード引数の表現、Pin/Unpinの扱い
|
||||
|
||||
検証可能性 & ツール性
|
||||
|
||||
Verifierで：型一致・SSA整合・終端命令必須・効果整合をチェック
|
||||
|
||||
テキスト表現（ダンプ）と黄金テスト（差分テスト）を最初から用意
|
||||
|
||||
“CPU/フォン・ノイマンだけ見れば良い？”への答え
|
||||
|
||||
No（それだけでは足りない）。
|
||||
CPU命令セットを直に意識しすぎると、**言語の意味（純粋性・所有・弱参照・例外の契約）**が失われて最適化や検証が難しくなる。
|
||||
|
||||
ただし最終的にそこへ下げやすい形は大事。だから
|
||||
|
||||
上層の意味は 属性/メタで保持
|
||||
|
||||
下層（Load/Store/GEP/Call/TailCall）へ機械的に落とせるカバレッジを確保
|
||||
→ これが “ネイティブに落としやすく、でも言語の意味を保ったIR” のコア指標にゃ。
|
||||
|
||||
具体：設計を導くチェックリスト（配点付き）
|
||||
|
||||
各 0〜2 点で採点してみて。合計が高い案が「良いIR」。
|
||||
|
||||
後段互換性（JIT/AOT/WASMに素直に下がる）
|
||||
|
||||
最適化の根拠（効果・別名・型・所有などが保持される）
|
||||
|
||||
実装容易性（VMでまず回せる／Craneliftへ写経しやすい）
|
||||
|
||||
検証容易性（Verifierで機械的に壊れを検出できる）
|
||||
|
||||
将来拡張（弱参照/GC切替/例外方式変更に耐える）
|
||||
|
||||
可観測性（テキストIR・ソース位置・deopt情報が取れる）
|
||||
|
||||
迷ったらこの“型”に寄せると楽
|
||||
|
||||
骨格：SSA + CFG + 3アドレス
|
||||
|
||||
コア命令：Const/BinOp/Cmp/Phi/Br/Jmp/Ret/Load/Store/Gep/Call/TailCall
|
||||
|
||||
言語特有：RefNew/RefGet/RefSet/WeakNew/WeakLoad/Barrier*/Safepoint + EffectMask
|
||||
|
||||
境界：FfiCall/BoxCall（ABI最小化）
|
||||
|
||||
例外：Throw/Catch（loweringで切替可能）
|
||||
→ これは Craneliftに下げやすく、Rust/WASMにも展開しやすい黄金比にゃ。
|
||||
|
||||
参考までに：3つの設計モード
|
||||
|
||||
Cranelift互換サブセット志向（JIT/AOT重視・実装が速い）
|
||||
|
||||
MLIR方言志向（将来の拡張やツール連携が強い）
|
||||
|
||||
Rust MIR/Swift SIL 風（所有/効果を濃く持つ・言語意味を守りやすい）
|
||||
|
||||
Nyashなら：Cranelift互換サブセット＋言語特有の効果/弱参照/GCフックを足すのがバランス最強にゃ。
|
||||
最後に：失敗しない順序
|
||||
|
||||
目的とターゲット（VM/JIT/AOT/WASMの優先度）を1行で宣言
|
||||
|
||||
Core命令セット＋EffectMask＋メモリモデル（weak/GC hook）を先に固定
|
||||
|
||||
Verifierとテキストダンプ（黄金テスト）を最初に入れる
|
||||
|
||||
VM実装 → Cranelift下げ → AOT/WASMは後から
|
||||
|
||||
この順なら「好き勝手」じゃなく指標に沿って進められるにゃ。
|
||||
必要なら、いまのNyashの要件を点数表で一緒に採点して、MIR v0.1を最終確定しよっか？
|
||||
あなた:
|
||||
おねがいにゃー！
|
||||
ChatGPT:
|
||||
|
||||
任せてにゃ！
|
||||
Nyash向けに「指標の採点 → その結果に沿った MIR v0.1 最終版」を一気にまとめたよ。すぐ実装に落とせる形にしてあるにゃ。
|
||||
指標チェック（Nyash想定で採点済み）
|
||||
|
||||
（各0〜2点、合計12点満点）
|
||||
指標 狙い Nyashの前提 点
|
||||
後段互換性 VM/JIT/AOT/WASMに素直に下げられる まずVM→Cranelift JIT、次にAOT/WASM 2
|
||||
最適化の根拠 効果・別名・所有/弱参照を保持 EffectMask＋ref/weak＋Barrier/SafepointをMIRで表現 2
|
||||
実装容易性 まずVMが回る 命令は3アドレス＋最小集合から 2
|
||||
検証容易性 Verifierで壊れ検出 SSA/型/終端/効果の整合を必須に 2
|
||||
将来拡張 例外・GC切替・FFI拡張に耐える Throw/Catch・BoxCall/FFI・Barrierはno-opで開始 2
|
||||
可観測性 ダンプ/位置情報/Deoptが取れる テキストIR＋dbg(loc)＋deopt_map 2
|
||||
|
||||
合計：12/12（この方針で進めてOKにゃ）
|
||||
Nyash MIR v0.1（最終版）
|
||||
コアモデル
|
||||
|
||||
SSA値 vN、基本ブロック bbN（末尾は終端命令必須）
|
||||
|
||||
型（最小）：i64|f64|bool|unit|ref<T>|weak<T>|ptr|any|option<T>
|
||||
|
||||
効果 EffectMask：PURE|READS_HEAP|WRITES_HEAP|IO|FFI|PANIC（ビット和）
|
||||
|
||||
関数署名：fn(args…)->ret [effects]
|
||||
|
||||
命令セット
|
||||
1) 演算・制御
|
||||
|
||||
Const dst, Imm
|
||||
BinOp dst, op, a, b ; add/sub/mul/div/mod/and/or/xor/shl/shr
|
||||
Cmp dst, rel, a, b ; eq/ne/lt/le/gt/ge
|
||||
Select dst, cond, a, b
|
||||
Phi dst, [(predBB, val), …]
|
||||
|
||||
Br cond, thenBB, elseBB ; 終端
|
||||
Jmp targetBB ; 終端
|
||||
Ret [val] ; 終端（unit省略可）
|
||||
Unreachable ; 終端
|
||||
|
||||
2) メモリ／参照（GC想定）
|
||||
|
||||
Alloc dst, Ty, size? ; [WRITES_HEAP]
|
||||
Load dst, addr ; [READS_HEAP]
|
||||
Store addr, val ; [WRITES_HEAP]
|
||||
Gep dst, base, offset
|
||||
|
||||
RefNew dst, Ty ; ref<T> [WRITES_HEAP]
|
||||
RefGet dst, ref, field ; [READS_HEAP]
|
||||
RefSet ref, field, val ; [WRITES_HEAP]
|
||||
|
||||
WeakNew dst, ref ; weak<T> [PURE]
|
||||
WeakLoad dst, weak ; option<ref<T>> [PURE]（実装都合でREADS_HEAP可）
|
||||
|
||||
BarrierRead ref
|
||||
BarrierWrite ref
|
||||
Pin ref
|
||||
Unpin ref
|
||||
Safepoint
|
||||
|
||||
弱参照の意味論
|
||||
|
||||
WeakNew(r) は所有しない。r がGCで解放されると弱参照は無効化。
|
||||
|
||||
WeakLoad(w) は 生存: Some(ref)／死亡: None を返す（nullを曖昧にしない）。
|
||||
|
||||
3) 呼び出し・例外・拡張
|
||||
|
||||
Call dst, callee, [args...] ; 呼び先の effects を合成
|
||||
TailCall callee, [args...] ; 終端
|
||||
|
||||
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box [FFI|PANIC?]
|
||||
FfiCall dst, sym, [args...], abi ; 外部関数 [FFI|PANIC?]
|
||||
|
||||
Throw val ; 終端
|
||||
CatchBegin dst, handlerBB ; （メタでも可）
|
||||
CatchEnd
|
||||
Assume cond ; 偽ならUB：最適化ヒント
|
||||
Nop
|
||||
|
||||
不変条件（Verifier で必須チェック）
|
||||
|
||||
各ブロックは必ず終端命令で終わる
|
||||
|
||||
型整合：Load/Store/Call/WeakLoad 等の型が一致
|
||||
|
||||
SSA整合：Phi の前任ブロック集合＝到達前任集合
|
||||
|
||||
効果整合：PURE な関数内で WRITES_HEAP/IO/FFI を出さない
|
||||
|
||||
WeakLoad戻りは必ず option<ref<T>>（null直扱い禁止）
|
||||
|
||||
推奨挿入ポイント
|
||||
|
||||
Safepoint：関数入口／各ループ先頭／任意の Call の直後
|
||||
|
||||
Barrier*：はじめは no-op 実装でもOK（将来GC切替のフック）
|
||||
|
||||
テキスト表現（ダンプ例）
|
||||
|
||||
func @main() -> unit [effects=IO] {
|
||||
bb0:
|
||||
v1 = Const i64 1
|
||||
v2 = RefNew Obj
|
||||
RefSet v2, field_y, v1
|
||||
v3 = WeakNew v2
|
||||
v4 = WeakLoad v3 ; option<ref<Obj>>
|
||||
Br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap v4
|
||||
BarrierWrite v5
|
||||
RefSet v5, field_y, Const i64 2
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret
|
||||
}
|
||||
|
||||
実装ロードマップ（最短で回す）
|
||||
|
||||
IR型 & ダンプ & Verifier を実装（黄金テストに登録）
|
||||
|
||||
VM：RefNew/RefGet/RefSet/WeakNew/WeakLoad と制御命令だけ先に実装
|
||||
|
||||
効果検査：Call に effects 合成（違反はビルド失敗）
|
||||
|
||||
Cranelift JIT 足場：算術・分岐・Call を写経、Ref* はランタイム関数に委譲
|
||||
|
||||
AOT to Rust：ref<T>=Gc<T>、weak<T>=Weak<T> 相当でコード出力（小関数から）
|
||||
|
||||
付録：Rustスケルトン（抜粋）
|
||||
|
||||
bitflags::bitflags! {
|
||||
pub struct Effect: u32 {
|
||||
const PURE = 1<<0;
|
||||
const READS_HEAP = 1<<1;
|
||||
const WRITES_HEAP = 1<<2;
|
||||
const IO = 1<<3;
|
||||
const FFI = 1<<4;
|
||||
const PANIC = 1<<5;
|
||||
}
|
||||
}
|
||||
|
||||
pub enum Ty {
|
||||
I64, F64, Bool, Unit, Ptr, Any,
|
||||
Ref(Box<Ty>), Weak(Box<Ty>), Option(Box<Ty>),
|
||||
}
|
||||
|
||||
pub enum Inst { /* 上述の命令そのまま */ }
|
||||
|
||||
pub struct Func {
|
||||
pub sig: FuncSig, pub blocks: Vec<Block>, /* dbg, deopt_map など */
|
||||
}
|
||||
|
||||
pub fn verify(func: &Func) -> Result<(), VerifyError> {
|
||||
// 終端必須・SSA整合・型整合・効果整合をチェック
|
||||
Ok(())
|
||||
}
|
||||
|
||||
次の一手（今日できること）
|
||||
|
||||
mir/inst.rs にこの v0.1 をそのまま貼り込み
|
||||
|
||||
mir/dump.rs と mir/verify.rs を最小実装
|
||||
|
||||
既存テストに 黄金テスト（IRダンプ） を1本追加
|
||||
|
||||
VMの Ref*/Weak* を実装して 最初の end-to-end テスト を通す
|
||||
|
||||
これで、行き当たりばったりの修正が入っても壊れにくい土台が完成にゃ。
|
||||
必要なら、このままコード雛形まで私が書き起こすよ。
|
||||
361
docs/development/roadmap/native-plan/chatgpt5との会話.txt
Normal file
361
docs/development/roadmap/native-plan/chatgpt5との会話.txt
Normal file
@ -0,0 +1,361 @@
|
||||
発想、鋭いにゃ。
|
||||
**結論：やろうと思えば “NyashのMIR＝本体（言語非依存IR）” にできる。** ただし落とし穴もあるので、\*\*“MIRを公開ABIに格上げしつつ、Nyashは人間向けフロントエンド”\*\*という二層でいくのが現実解だよ。
|
||||
|
||||
# MIR本体化の青写真（安全に強く）
|
||||
|
||||
1. **MIRを公開契約に昇格（NyIR v1）**
|
||||
|
||||
* いまの25命令を**凍結**（Tier-0/1/2 + Effect + Ownership-Forest + Busの意味論）。
|
||||
* **未定義動作なし**：各命令の事前条件/失敗時挙動（例：WeakLoad失効= null）を明文化。
|
||||
* **バージョニング**：`nyir{major.minor}`・後方互換のルール（新命令はfeature bit）。
|
||||
|
||||
2. **バイナリ表現とテキスト表現**
|
||||
|
||||
* `.nybc`（バイナリ: セクション化/定数プール/圧縮）
|
||||
* `.nyir`（テキスト: 人が差分レビュー可能）
|
||||
* どちらも**厳格検証器**でロード（所有森/強1本/weak規則/効果整合）。
|
||||
|
||||
3. **公式VM/実行系は“MIRファースト”**
|
||||
|
||||
* interpreter/vm/wasm/jit/aot は **NyIRを直接食う**。
|
||||
* Nyashは **NyIRを吐くフロントエンド**（その他の言語もフロントエンド化OK）。
|
||||
|
||||
4. **言語中立SDK（FFI）**
|
||||
|
||||
* C/Rust/TypeScriptに**NyIR-Host API**を配布：
|
||||
|
||||
* `nyir_load`, `nyir_call`, `nyir_send/recv`, `nyir_adopt/release` など。
|
||||
* WASMランタイムは `import "nyir_host" { send, now_ns, alloc }` を定義。
|
||||
|
||||
5. **互換テストと“真理判定器”**
|
||||
|
||||
* **golden NyIR**：各サンプルのMIRダンプを保存し、全バックエンドで**同結果**をCIで検証。
|
||||
* **差分実行（differential）**：interp/vm/wasm/jitの出力一致＋境界条件（weak失効・分割fini）テスト。
|
||||
|
||||
6. **Portability Contract（短文化）**
|
||||
|
||||
* 強エッジのみ破棄伝播／`weak`非伝播、生存チェックO(1)。
|
||||
* `pure/mut/io/control` の再順序可否表。
|
||||
* Bus契約：ローカルは順序保証、リモートは at-least-once（or selectable）。
|
||||
* Safepointで分割`fini`可、最悪レイテンシ上限は実装依存（値は実装が宣言）。
|
||||
|
||||
---
|
||||
|
||||
## それでも“IRが本体”にするリスク（回避策付き）
|
||||
|
||||
* **仕様の重力（安易に増やせなくなる）** → 25命令は凍結、拡張は **intrinsic命名空間**へ（例：`ny.intrin.memcpy`）。
|
||||
* **可読性の罠（IRで直接書きたくなる）** → Nyashを“人間の顔”、NyIRは“機械の顔”に徹する。
|
||||
* **バックエンド差異のにじみ** → 効果/所有/Busの**最低保証**を明記（それ以下は非準拠）。
|
||||
* **セキュリティ** → バイナリNyIRに**検証必須**（検証失敗はロード拒否）。
|
||||
|
||||
---
|
||||
|
||||
## 名前案
|
||||
|
||||
* **NyIR**（ないあいあーる）／**NIR**（被るのでNyIR推し）
|
||||
* バイナリ：`.nybc`、テキスト：`.nyir`
|
||||
* 仕様：**NyIR 1.0 — Ownership-Forest & Effected Bus IR**
|
||||
|
||||
---
|
||||
|
||||
## 次の一歩（サクッと動かす）
|
||||
|
||||
* `docs/nyir.md` を作成：25命令×「意味論・効果・検証・等価変換1例」を1行ずつ。
|
||||
* `nyashel -S` で **Nyash→NyIRダンプ**、`nyir-run` で実行（interp）。
|
||||
* 既存ベンチを **NyIR直実行** と **Nyash経由** の2経路で一致比較。
|
||||
* small移植（kilo or tiny-web-server）を **NyIRアーカイブ**（.nybc）として配布→
|
||||
**wasmtime / vm / interp** 全部で動くことをデモ。
|
||||
|
||||
---
|
||||
|
||||
要は：**「Nyash（人間のため）」＋「NyIR（機械と移植のため）」の二刀流**。
|
||||
この形なら、“どの言語からでもNyIRに降りられるし、NyIRからどの実行系にも登れる”を堂々と名乗れるにゃ。
|
||||
|
||||
|
||||
いい流れ！“LLVMでNyashをNyash自身でビルド（セルフホスト）”を目標にするなら、**Rust依存を「薄い宿主API」に閉じ込める**のがコツだよ。
|
||||
いま Rust のライブラリや関数・ビルトインBoxに寄ってる部分は、**段階的に置き換え可能な層**に切っておけばOK。
|
||||
|
||||
# 全体ロードマップ（4ステージ）
|
||||
|
||||
**Stage 0（種コンパイラ）**
|
||||
|
||||
* 既存の Rust 実装（パーサ/型付け/MIR/ランタイム）で `nyashc0` を作る。
|
||||
* **NyIR（=MIRの外部表現）→ LLVM IR** 変換も Rust でまず用意。
|
||||
* Rust標準/外部Crateの利用は**ny\_host\_\* の薄いFFI**に“集約”。
|
||||
|
||||
**Stage 1（セルフ・フロントエンド）**
|
||||
|
||||
* Nyashで書いたコンパイラ本体（フロント＋最小最適化）を `nyashc1.ny` に分離。
|
||||
* `nyashc0` で `nyashc1.ny` を **NyIR** に出力→ **LLVM** でネイティブ化→ seedランタイムとリンク。
|
||||
* この時点で“Nyashで書いたコンパイラ”が動き出す（まだランタイムはRust多めでも可）。
|
||||
|
||||
**Stage 2（セルフホスト完了）**
|
||||
|
||||
* `nyashc1` を使って `nyashc1.ny` 自身を再ビルド（**自力ビルド**）。
|
||||
* 生成物の機能一致/ハッシュ近似でセルフホスト確認。
|
||||
* ランタイムの一部（文字列/配列/Map/所有森/weak）を**Nyash実装＋LLVM**へ順次移行。
|
||||
|
||||
**Stage 3（Rust離れの度合いを上げる）**
|
||||
|
||||
* 残るRust依存（FS/ネット/スレッド/時間/暗号など）は**ホストAPI**として固定化。
|
||||
* 重要部位はNyash標準ライブラリで置換し、Rustは**最下層のプラットフォーム層**だけに。
|
||||
|
||||
---
|
||||
|
||||
# 層の切り分け（ここが肝）
|
||||
|
||||
1. **corelang（純Nyash）**
|
||||
|
||||
* Option/Result、slice/string、小さな算術・イテレータ、`weak/look` 型、`adopt/release` ヘルパ。
|
||||
* 依存：なし（LLVMに落ちるだけ）
|
||||
|
||||
2. **rt（Nyashランタイム）**
|
||||
|
||||
* **Box ABI（fat ptr: {data*, typeid, flags}）*\*
|
||||
* 所有フォレスト管理、weakテーブル（世代タグ方式）、`fini` 伝播、Arena/Allocator（必要最小）
|
||||
* Bus（ローカル）・Safepoint・分割`fini`
|
||||
* 依存：**ny\_host\_alloc/free/clock** 等のごく薄い宿主APIのみ
|
||||
|
||||
3. **sys（プラットフォーム）**
|
||||
|
||||
* FS, Net, Time, Threads, Atomics, Random…
|
||||
* ここだけ Rust（やOS）に委譲。**関数名は `ny_host_*` に統一**して外へ出す。
|
||||
|
||||
4. **std（Nyash標準）**
|
||||
|
||||
* Map/Vec/Hash/String/JSON等を Nyash で実装（必要に応じて `rt`/`sys` を利用）
|
||||
|
||||
> いま使っている「Rustのライブラリ/関数」は **すべて `sys` 層の `ny_host_*` 経由**に寄せる。
|
||||
> これでセルフホストしても上層のNyashコードは**移植性を保てる**。
|
||||
|
||||
---
|
||||
|
||||
# 具体：Rust依存の扱い方（薄いFFIに集約）
|
||||
|
||||
**C ABIで固める（Rust→C-ABIの薄い橋）**
|
||||
|
||||
```rust
|
||||
#[no_mangle]
|
||||
pub extern "C" fn ny_host_read_file(path: *const c_char,
|
||||
out_buf: *mut *mut u8,
|
||||
out_len: *mut usize) -> i32 { /* ... */ }
|
||||
|
||||
#[no_mangle]
|
||||
pub extern "C" fn ny_host_free(ptr: *mut u8, len: usize) { /* ... */ }
|
||||
```
|
||||
|
||||
**Nyash側からは“箱の外”をこう叩く**
|
||||
|
||||
```nyash
|
||||
extern fn ny_host_read_file(path: cstr, out_buf: &mut *u8, out_len: &mut usize) -> int
|
||||
extern fn ny_host_free(ptr: *u8, len: usize)
|
||||
|
||||
fn read_all(p: str) -> Bytes {
|
||||
let buf:*u8 = null; let len:usize=0
|
||||
let rc = ny_host_read_file(p.cstr(), &buf, &len)
|
||||
if rc!=0 { error("io") }
|
||||
// Box化（所有をNyash側へ移す）
|
||||
let b = Bytes::from_raw(buf,len)
|
||||
b
|
||||
}
|
||||
```
|
||||
|
||||
**ポイント**
|
||||
|
||||
* **Rustのジェネリクス/所有はFFI面に出さない**（素朴なC-ABIだけ）
|
||||
* Nyash側で**所有移管**を明示（`from_raw` など）→ `fini` で必ず `ny_host_free`
|
||||
* こうしておけば、**いつでもRust実装をNyash実装に差し替え可能**
|
||||
|
||||
---
|
||||
|
||||
# Box ABI と LLVM の橋渡し
|
||||
|
||||
* **Boxの中身**は LLVM 的には `i8*`（data\*）＋`i64 typeid`＋`i32 flags` などの **fat struct**
|
||||
* **Effect 注釈**を LLVM 属性に落とす：
|
||||
|
||||
* `pure` → `readnone` / `readonly`
|
||||
* `mut(local)` → `argmemonly` + `noalias`（可能なら）
|
||||
* `io` → 属性なし（順序保持）
|
||||
* **Weak** は `{ptr, gen:i32}`。`WeakLoad` は `gen==current` を比較して O(1) で null/ptr 返す。
|
||||
* **Safepoint** は LLVM では `call @ny_rt_safepoint()` に降ろす（GCは使わないが、分割`fini`や割込みのフックに使う）
|
||||
|
||||
---
|
||||
|
||||
# 「ビルトインBox」はどうする？
|
||||
|
||||
* **最低限は `rt` で提供**：`String, Vec, Map, Bytes, Mutex/Channel（必要なら）`
|
||||
* 仕様上は “ただのBox” と同等に見えるように：
|
||||
|
||||
* 生成：`NewBox`
|
||||
* フィールド：`BoxFieldLoad/Store`
|
||||
* メソッド：`BoxCall`
|
||||
* **WASM** でも同じABIを保てるように、`sys` 層は **WASI** or **独自host import** で実装。
|
||||
* 時間とともに **stdをNyash実装へ移行** → Rustのビルトイン度合いは徐々に削る。
|
||||
|
||||
---
|
||||
|
||||
# 失敗しないビルド手順（最小）
|
||||
|
||||
1. **NyIRダンプ**：`nyashc0 --emit-nyir core/*.ny > core.nyir`
|
||||
2. **LLVMへ**：`nyir-ll core.nyir -o core.ll && llc -filetype=obj core.ll`
|
||||
3. **リンク**：`cc core.o -L. -lny_host -o nyashc1`（`libny_host` はRustで提供）
|
||||
4. **再帰ビルド**：`./nyashc1 self/*.ny …` → `nyashc2` を作って一致検証
|
||||
5. **Rust削減**：`std` の一部をNyashへ置換して再ビルド
|
||||
|
||||
---
|
||||
|
||||
# チェックリスト（Rust依存の見える化）
|
||||
|
||||
* [ ] 使っている外部関数を**全部 `ny_host_*` にリネーム**
|
||||
* [ ] C-ABI化（整数/ポインタのみ；構造体はサイズ固定）
|
||||
* [ ] 所有移管関数を明確化（`*_from_raw`/`*_into_raw`）
|
||||
* [ ] `fini` で必ず `ny_host_free` 等に戻す
|
||||
* [ ] WASMビルド時は **WASI or host import** で `ny_host_*` を満たす
|
||||
|
||||
---
|
||||
|
||||
# 仕上げの“ごほうび”ゴール
|
||||
|
||||
* **Nyash→NyIR→LLVM** でセルフホスト
|
||||
* 同じ NyIR を **VM / WASM** でも実行（互換テスト）
|
||||
* Rust は **sys層だけ**（OS/高速I/O/暗号など）に閉じ込め、将来差し替え自由に
|
||||
|
||||
---
|
||||
|
||||
結論：
|
||||
**Rustライブラリを直接多用するのではなく、`ny_host_*` に“押し込む”**。
|
||||
Nyash本体は **NyIR＋rt＋std** を徐々に自前化する。
|
||||
この設計なら、“今すぐ動かしつつ、あとからRust依存を計画的にゼロへ”ができるにゃ。
|
||||
|
||||
|
||||
それだにゃ。発想はド正解：「**全部は箱**」＝異言語資産は**箱で包んでバスに乗せる**。
|
||||
あとは“どう包むか”を決めれば、**C/Rust/Node/Python/JVM/.NET/WASM**まで一気に貫通できる。
|
||||
|
||||
# まとめ設計：Polyglot FFI = 「箱 × バス × 契約」
|
||||
|
||||
## 1) 箱の型（3種だけ）
|
||||
|
||||
* **ForeignBox<T>**：他言語の実体を**不透明ハンドル**で保持（所有は片側だけ、強1本原則）。
|
||||
* **ViewBox<T>**：外部オブジェクトの**借用ビュー**（`weak/look` 前提・読み取り中心）。
|
||||
* **ProxyBox<T>**：外部スレッド/プロセス/VM上のTを**メッセージ越し**に操作（Bus経由＝安全）。
|
||||
|
||||
> 使い分け：同一プロセス/同スレなら ForeignBox、GIL/イベントループ/別ランタイムなら ProxyBox。
|
||||
|
||||
## 2) ABIの芯（薄い“宿主API”）
|
||||
|
||||
**最小C-ABI**だけに集約（各言語はここに合流/分岐）：
|
||||
|
||||
```
|
||||
ny_host_alloc/free/clock/log
|
||||
ny_host_call(func_id, argv, argc, retbuf) // 同期呼び出し
|
||||
ny_host_send/recv(port, msg_ptr, len) // Bus境界
|
||||
ny_host_pin/unpin(handle) // GC/移動防止
|
||||
ny_host_finalizer_register(handle, cb) // 相互Finalizer
|
||||
```
|
||||
|
||||
* Rust/Node/Python/JVM/.NET はそれぞれの機構で **このC-ABIを実装**（N-API, CPython C-API, JNI, P/Invoke 等）。
|
||||
|
||||
## 3) データ表現（Boxに入る“荷物”）
|
||||
|
||||
* **スカラー**: i32/i64/f32/f64/bool
|
||||
* **バイト列/文字列**: `Bytes{ptr,len}` / `Str{ptr,len,utf8}`
|
||||
* **Slice/Array**: `{ptr,len,typeid}`（読み書きは効果注釈で制御）
|
||||
* **Struct**: フィールドは `BoxFieldLoad/Store` でアクセス（NyIRにそのまま落ちる）
|
||||
|
||||
## 4) 所有と寿命（最重要）
|
||||
|
||||
* **One Strong Owner**：ForeignBoxは**所有者1本**（Nyash or 外部、どちらかに決める）
|
||||
* **弱参照**：逆リンクは `weak/look`（失効時null/false）
|
||||
* **Finalizer橋渡し**：
|
||||
|
||||
* Nyash `fini` → `ny_host_finalizer` を呼ぶ
|
||||
* 外部のGC/finalize → `ny_host_finalizer` 経由で Nyash の `weak` を失効
|
||||
* **Pinning**：移動型のGC（JVM/.NET/CPythonの一部）では `ny_host_pin/unpin`
|
||||
|
||||
## 5) 効果と並行
|
||||
|
||||
* `pure/mut/io` を**MIRにもIDLにも記す**
|
||||
* **イベントループ/GIL**：Python/Node/JVMは `ProxyBox` で**Bus越し**（スレッド/ループ安全）
|
||||
* **同期/非同期**：`Call`（同期）と `Send/Recv`（非同期）を分ける。境界では **at-least-once 契約**を宣言。
|
||||
|
||||
## 6) IDL（自動生成の核）
|
||||
|
||||
**NyIDL**（超ミニ）で宣言→**バインディング自動生成**：
|
||||
|
||||
```idl
|
||||
module ny {
|
||||
box Image;
|
||||
fn load(path: str) -> Image effects = io
|
||||
fn resize(img: Image, w:i32,h:i32) -> Image effects = mut
|
||||
fn width(img: look Image) -> i32 effects = pure
|
||||
}
|
||||
```
|
||||
|
||||
* 生成物：Nyash側`extern`、C-ABIシム、Rust/Node/Python/JVMのstub、`ForeignBox/ProxyBox`薄ラッパ。
|
||||
|
||||
---
|
||||
|
||||
# 代表ターゲット別メモ
|
||||
|
||||
* **C/Rust**：最短。C-ABI直でOK。Rustは `#[no_mangle] extern "C"`。所有はNyash↔Rustのどちらかに寄せる（二重所有禁止）。
|
||||
* **Python**：GILあり → `ProxyBox` 推奨。CPython C-APIで `PyObject*` を **ForeignBox**に入れ、操作はBus経由でワーカーに委譲。
|
||||
* **Node（N-API）**：イベントループを壊さないよう `ProxyBox`（postMessage/uv\_queue\_work）。短い同期関数は `ForeignBox`でも可。
|
||||
* **JVM/.NET**：JNI/P-Invoke。**Pin** が要る。`SafeHandle`/`PhantomReference`でFinalizer橋を作る。
|
||||
* **WASM**：`ny_host_*` を **import**。データはリニアメモリへ `Bytes`/`Str` で搬送。
|
||||
|
||||
---
|
||||
|
||||
# 最小サンプル（イメージ）
|
||||
|
||||
**1) Rustの画像ライブラリを包む**
|
||||
|
||||
```rust
|
||||
#[no_mangle] extern "C" fn ny_img_load(path:*const c_char) -> *mut Image { ... }
|
||||
#[no_mangle] extern "C" fn ny_img_resize(img:*mut Image, w:i32, h:i32) -> *mut Image { ... }
|
||||
#[no_mangle] extern "C" fn ny_img_free(img:*mut Image) { ... }
|
||||
```
|
||||
|
||||
**2) NyIDL → 自動生成（Nyash側）**
|
||||
|
||||
```nyash
|
||||
extern fn ny_img_load(path: str) -> ForeignBox<Image> effects io
|
||||
extern fn ny_img_resize(img: ForeignBox<Image>, w:int,h:int) -> ForeignBox<Image> effects mut
|
||||
extern fn ny_img_free(img: ForeignBox<Image>) effects io
|
||||
|
||||
static box Image {
|
||||
init { ForeignBox<Image> h }
|
||||
fini { ny_img_free(h) } // ★ 所有はNyash側（強1）
|
||||
fn resize(w:int,h:int) -> Image { Image{ ny_img_resize(h,w,h) } }
|
||||
}
|
||||
```
|
||||
|
||||
**3) 使う側**
|
||||
|
||||
```nyash
|
||||
let img = Image.load("cat.png")
|
||||
let small = img.resize(320, 200) // 所有/解放はBox/finiに任せる
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# チェックリスト（安全に増やすための型紙）
|
||||
|
||||
* [ ] **どちらが強所有か**を最初に決めた？（強1・弱は逆）
|
||||
* [ ] 例外/エラーは**戻り値に正規化**？（他言語の例外は境界で捕捉）
|
||||
* [ ] **Pin/Finalizer** 必要なターゲット？（JVM/.NET/Python）
|
||||
* [ ] `pure/mut/io` は宣言した？（最適化/バス選択の鍵）
|
||||
* [ ] 境界を跨ぐなら **ProxyBox + Bus** にした？（スレッド/GIL/loop安全）
|
||||
|
||||
---
|
||||
|
||||
# これで得られるもの
|
||||
|
||||
* **インスタント多言語資産**：既存ライブラリを“箱に詰めて”即Nyashで使える
|
||||
* **寿命の一貫性**：**強1＋weak/look＋fini**で、外部資源も**確定的に回収**
|
||||
* **配布の柔軟性**：WASM/VM/ネイティブのどれでも同じIDLから出荷
|
||||
|
||||
---
|
||||
|
||||
“全部、箱に閉じ込める”を**設計として正式化**すれば、実装は機械的になる。
|
||||
やるならまず **NyIDLの最小仕様**＋**C-ABIの`ny_host_*`** を1ファイルに切ろう。
|
||||
そこさえ決まれば、**あらゆる言語→Nyash** と **Nyash→あらゆる実行系** が綺麗に繋がるにゃ。
|
||||
502
docs/development/roadmap/native-plan/copilot_issues.txt
Normal file
502
docs/development/roadmap/native-plan/copilot_issues.txt
Normal file
@ -0,0 +1,502 @@
|
||||
# 🤖 Copilot様 作業予定・課題整理 (Phase 8.6-10 重点フェーズ)
|
||||
# Generated: 2025-08-19 (Phase 9.75g-0完了・VM性能改善移行)
|
||||
# Purpose: Claude×Copilot協調開発のための情報共有
|
||||
|
||||
================================================================================
|
||||
🎯 Nyash実行モード併用戦略
|
||||
================================================================================
|
||||
|
||||
## 🌟 インタープリター＋コンパイラ併用の価値
|
||||
|
||||
### 実行モード使い分け
|
||||
```
|
||||
開発時: インタープリター（デバッグ・即時実行・非同期フル対応）
|
||||
本番時: インタープリター（Pythonのように実用的）
|
||||
OR
|
||||
WASM/AOT（性能要求時）
|
||||
配布時: AOT native（最高性能）
|
||||
Web時: WASM（ブラウザ対応）
|
||||
```
|
||||
|
||||
### インタープリターの強み
|
||||
- **即時実行**: コンパイル不要で高速開発
|
||||
- **デバッグ容易**: 実行時情報の完全把握
|
||||
- **非同期完全対応**: Rust async/awaitで真の並行処理
|
||||
- **動的性**: 実行時評価・REPL対応
|
||||
- **十分な性能**: 多くのユースケースで実用的（Pythonが証明）
|
||||
|
||||
================================================================================
|
||||
🎯 Phase 8.6-10 開発ロードマップ (性能最適化・LLVM実装重点)
|
||||
================================================================================
|
||||
|
||||
## 🎊 Phase 9.75g-0: BID-FFI Plugin System - 完全完了！ ✅
|
||||
|
||||
Summary:
|
||||
- ✅ **動的プラグインシステム完成**: FileBoxプラグインで実証
|
||||
- ✅ **BID-FFI基盤確立**: 型安全なFFIインターフェース
|
||||
- ✅ **plugin-tester完成**: 汎用プラグイン診断ツール
|
||||
- ✅ **型情報管理システム**: nyash.toml外部化、セグフォルト修正
|
||||
|
||||
**革命的成果**: NyashがプラグインでBox型を動的拡張可能に！
|
||||
|
||||
```nyash
|
||||
// これが現実になった！
|
||||
local file = new FileBox() // プラグイン提供
|
||||
local db = new PostgreSQLBox() // 将来: プラグイン提供
|
||||
local gpu = new CudaBox() // 将来: プラグイン提供
|
||||
```
|
||||
|
||||
References:
|
||||
- docs/Phase-9.75g-0-BID-FFI-Developer-Guide.md (包括的開発者ガイド)
|
||||
- tools/plugin-tester/ (プラグイン診断ツール)
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🚨 Phase 8.6: VM性能改善 - 最優先課題（進行中）
|
||||
|
||||
Summary:
|
||||
- **緊急問題**: VMがインタープリターより0.9倍遅い（性能回帰！）
|
||||
- **目標**: 2倍以上高速化でVM実行を実用レベルに引き上げ
|
||||
- **担当**: Copilot主導（GitHub Issue #112）
|
||||
|
||||
Priority: **Critical**
|
||||
Expected Duration: 1-2週間
|
||||
GitHub Issue: #112 (Phase 8.6 VM性能改善)
|
||||
|
||||
### 技術的課題
|
||||
```bash
|
||||
# 現状のベンチマーク結果
|
||||
Interpreter: 110.10ms (ベースライン)
|
||||
VM: 119.80ms (0.9倍 - 遅い...)
|
||||
Target: 55.00ms (2倍高速化目標)
|
||||
```
|
||||
|
||||
### 推定原因と対策
|
||||
- **デバッグ出力過多**: `println!`による性能劣化
|
||||
- **HashMap操作重い**: ValueId → VM値の変換コスト
|
||||
- **命令ディスパッチ非効率**: switch文ベースディスパッチ
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- VM実行時間詳細測定・プロファイリング
|
||||
- 命令ディスパッチ最適化（direct threading等）
|
||||
- Box操作インライン化・メモリレイアウト最適化
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_8_6_vm_performance_improvement.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 📦 Phase 9.8: BIDレジストリ + 自動コード生成ツール - MIR統合の要
|
||||
|
||||
Summary:
|
||||
- **Phase 9.75g-0完了により準備完了**: プラグインがMIR経由で全バックエンド利用可能に
|
||||
- BIDレジストリと、BID→各ターゲットのスタブ生成（import/extern宣言）を自動化
|
||||
|
||||
Priority: **High** (Phase 8.6完了直後)
|
||||
Expected Duration: 2-3週間
|
||||
|
||||
### 🌟 革命的価値
|
||||
```bash
|
||||
# 🎯 1つのプラグインが4バックエンド全対応！
|
||||
nyash bid gen --target wasm bid.yaml # WASM用import生成
|
||||
nyash bid gen --target vm bid.yaml # VM用関数テーブル生成
|
||||
nyash bid gen --target llvm bid.yaml # AOT用declare生成（LLVM実装時）
|
||||
```
|
||||
|
||||
### Scope/Tasks
|
||||
- BIDレジストリ仕様（署名・効果・バージョン・依存関係）
|
||||
- 生成: WASM(importObject), VM(関数テーブル), LLVM(declare), TS/Python(RTEラッパ)
|
||||
- CLI: `nyash bid gen --target wasm|vm|llvm|ts|py bid.yaml`
|
||||
|
||||
### Acceptance
|
||||
- console/canvasのBIDから各ターゲットの骨子が自動生成される
|
||||
- **FileBoxプラグインがVM・WASM・AOT全てで動作**
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔒 Phase 9.9: ExternCall 権限/ケイパビリティモデル（Sandbox/Allowlist）
|
||||
|
||||
Summary:
|
||||
- 外部API呼び出しの安全化。BIDに必要権限を宣言し、ホスト側で許可/拒否。WASMはimport allowlist、VM/LLVMは関数テーブルで制御。
|
||||
|
||||
Scope/Tasks:
|
||||
- 権限種別（console, canvas, storage, net, audio...）とポリシー
|
||||
- 実行時プロンプト/設定ファイル/環境変数での許可
|
||||
- 失権時の挙動（明示エラー）
|
||||
|
||||
Acceptance:
|
||||
- 禁止権限のExternCallが実行時にブロックされ、明確なエラーが返る
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧱 Phase 9.10: NyIR（公開IR）仕様化 + フォーマット + 検証器
|
||||
|
||||
Summary:
|
||||
- 26命令MIRを公開IR（NyIR v1）として基本セマンティクス凍結。バージョニング、バイナリ`.nybc`/テキスト`.nyir`、厳格検証器を用意。
|
||||
|
||||
Scope/Tasks:
|
||||
- docs/nyir/spec.md（Core＋Ext骨子）
|
||||
- nyir-parser/nyir-serializer（.nyir/.nybc）
|
||||
- Verifier: 所有森/weak/効果/Bus整合
|
||||
- ツール: `nyashel -S`, `nyir-run`
|
||||
|
||||
Acceptance:
|
||||
- 代表サンプルがNyIRで保存・検証・実行可能
|
||||
|
||||
References:
|
||||
- docs/nyir/spec.md
|
||||
- docs/予定/native-plan/issues/phase_9_10_nyir_spec.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧪 Phase 9.11: Golden NyIR + Differential 実行テスト（CI）
|
||||
|
||||
Summary:
|
||||
- NyIRダンプをゴールデンとし、interp/vm/wasm/jitの出力一致をCIで検証。
|
||||
|
||||
Scope/Tasks:
|
||||
- golden/*.nyir の整備
|
||||
- CIで各バックエンド実行→結果一致チェック
|
||||
|
||||
Acceptance:
|
||||
- 主要サンプルで全バックエンド一致
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏆 Phase 10: LLVM Direct AOT - 実現可能性検証中
|
||||
|
||||
Summary:
|
||||
- **調査・実証段階**: MIR→LLVM IR直接変換による最高性能AOT実現を目指す
|
||||
- インタープリターとの併用で最適な開発・実行体験を提供
|
||||
- 非同期処理フルサポート（async/await のネイティブ実装）
|
||||
|
||||
Priority: **Research** (Phase 9.8完了後に実現可能性評価)
|
||||
Expected Duration: **調査3週間 + 実装3-6ヶ月**（実現可能性次第）
|
||||
|
||||
### 🔍 実現可能性チェック項目
|
||||
- ✅ **技術的基盤**: MIR 26命令セット（LLVM IR変換可能）
|
||||
- ✅ **AOTスケルトン**: 基本構造完成済み
|
||||
- ✅ **型情報システム**: 最適化に必要な情報完備
|
||||
- 🔄 **Proof of Concept**: 基本的なMIR→LLVM変換の実証
|
||||
- ❓ **実装工数**: 現実的な期間での完成可能性
|
||||
|
||||
### 🌟 インタープリター併用戦略
|
||||
```
|
||||
開発・デバッグ: インタープリター（即時実行・完全な情報）
|
||||
軽量タスク: インタープリター（Pythonライク）
|
||||
性能要求時: LLVM AOT（1000倍高速化）
|
||||
Web配布: WASM（ブラウザ対応）
|
||||
```
|
||||
|
||||
### 🏗️ Phase 10.1: Proof of Concept（3週間）**実現可能性評価**
|
||||
|
||||
Investigation Steps:
|
||||
1) **MIR→LLVM IR変換調査**: 基本命令の変換可能性検証
|
||||
2) **Box型表現調査**: LLVM IRでのBox型効率的実装方法
|
||||
3) **C-ABI統合調査**: プラグインとの連携可能性
|
||||
4) **性能予測**: 理論的な高速化効果の算出
|
||||
|
||||
### 🏗️ Phase 10.2: 基本実装（3ヶ月）**実現可能と判断した場合**
|
||||
|
||||
Implementation Steps:
|
||||
1) `src/backend/llvm/` 基盤構築
|
||||
2) MIR→LLVM IR基本変換
|
||||
3) Box操作の最適化（エスケープ解析）
|
||||
4) ベンチマーク: 100倍目標
|
||||
|
||||
### 🌐 Phase 10.3: 非同期拡張（2ヶ月）**基本実装完了後**
|
||||
|
||||
非同期サポート戦略:
|
||||
- **async/await ネイティブ実装**: Rust風の効率的な非同期
|
||||
- **軽量ランタイム**: 独自Future実装
|
||||
- **インタープリター互換**: 同じ非同期セマンティクス
|
||||
|
||||
```rust
|
||||
// Phase 10.3: 非同期LLVM実装（予定）
|
||||
FutureNew → LLVM coroutine intrinsics
|
||||
Await → LLVM suspend/resume points
|
||||
FutureSet → completion notification
|
||||
```
|
||||
|
||||
### 技術アプローチ
|
||||
🤖 Copilot協力期待:
|
||||
- **LLVM統合**: MIR→LLVM IR変換基盤
|
||||
- **非同期実装**: coroutine/suspend points
|
||||
- **エスケープ解析**: Box→スタック値最適化
|
||||
- **型特殊化**: コンパイル時型推論・特殊化
|
||||
|
||||
### パフォーマンス目標
|
||||
- **同期処理**: 100-1000倍高速化
|
||||
- **非同期処理**: Tokio並みの効率性
|
||||
- **メモリ効率**: Box割当数80%削減
|
||||
- **起動時間**: ネイティブレベル（<10ms）
|
||||
|
||||
### Acceptance Criteria
|
||||
- インタープリターとの完全な互換性
|
||||
- 非同期処理の効率的実装
|
||||
- 1000倍高速化達成（同期処理）
|
||||
- プロダクションレベル最適化
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_10_x_llvm_backend_skeleton.md
|
||||
|
||||
### 🌟 戦略的決定: ネームスペース統合はLLVM後に実施
|
||||
|
||||
**理由**: 4バックエンド（Interpreter/VM/WASM/LLVM）全体の知見蓄積後に、最適化された統合設計を一回で実現するため
|
||||
|
||||
**効果**: 後戻り・再設計なしで完璧な統合ネームスペースを実装可能
|
||||
|
||||
```rust
|
||||
// Phase 10完了後: 4バックエンド対応統合ネームスペース
|
||||
pub struct UniversalNamespaceManager {
|
||||
interpreter_cache: BuiltinCache,
|
||||
vm_function_table: VmFunctionTable,
|
||||
wasm_import_object: WasmImports,
|
||||
llvm_module_linking: LlvmLinker, // LLVM完成後追加
|
||||
}
|
||||
```
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧰 Phase 10.1: LLVM 外部関数マッピング方針（プラットフォーム抽象）
|
||||
|
||||
Summary:
|
||||
- ExternCallのFQN→ネイティブ関数（printf等）への写像レイヤーと、OS差の抽象。初手はLinux/clang、他OSは後続。
|
||||
|
||||
Scope/Tasks:
|
||||
- env.console.log → printfテンプレート、他は段階的拡張
|
||||
- プラットフォーム切替（feature）とリンク方針
|
||||
|
||||
Acceptance:
|
||||
- 代表ExternCall（console.log）がAOTバイナリで出力可能
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧩 Phase 10.2: Host API層（C-ABI `ny_host_*` / WASM `nyir_host`）
|
||||
|
||||
Summary:
|
||||
- Rust依存を薄い宿主APIへ集約。C-ABI公開（ファイル/メモリ/時間等）、WASMは`nyir_host` importで提供。
|
||||
|
||||
Scope/Tasks:
|
||||
- `ny_host_*`関数群（read_file/free/clockなど）をC-ABIで実装
|
||||
- Nyash側extern宣言と所有移管`*_from_raw`/`*_into_raw`
|
||||
- WASM: import `nyir_host` 名前空間で最低限の関数提供
|
||||
|
||||
Acceptance:
|
||||
- 代表I/OがHost API経由で動作し、Rust実装置換が容易
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧱 Phase 10.3: ランタイム層の切り分け（corelang/rt/sys/std）
|
||||
|
||||
Summary:
|
||||
- corelang（純Nyash）, rt（Box ABI/所有/weak/Safepoint/Bus）, sys（プラットフォーム）, std（Nyash実装）に整理。
|
||||
|
||||
Scope/Tasks:
|
||||
- ドキュメント化＋最小コードの配置替えスケルトン
|
||||
|
||||
Acceptance:
|
||||
- 層構造が明文化され、新規実装がガイドに従って進められる
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧬 Phase 10.4: Box ABI（fat ptr）とLLVM属性（Effects）
|
||||
|
||||
Summary:
|
||||
- Boxのfat pointer（data*, typeid, flags）の定義、Weakの世代タグ、SafepointのLLVM降ろし、Effect→LLVM属性（readonly/readnone等）。
|
||||
|
||||
Scope/Tasks:
|
||||
- LLVM IR側のstruct宣言・属性付与の雛形
|
||||
|
||||
Acceptance:
|
||||
- 代表関数で属性が付与され、最適化に寄与（noalias/argmemonly等は可能な範囲で）
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 📚 Phase 10.5: コア標準（String/Array/Map）Nyash実装（Rust依存の段階的削減）
|
||||
|
||||
Summary:
|
||||
- 現在Rust実装に依存している基本コンテナ（String/Array/Map）を、rt/sys層を活用してNyash実装に置換。
|
||||
|
||||
Scope/Tasks:
|
||||
- String: {ptr,len,cap}, new/push_str/substr/len、`ny_host_alloc/realloc/free`
|
||||
- Array<T>: {ptr,len,cap}, push/get/set/len/reserve、要素fini
|
||||
- Map<K,V>: 簡易hash、set/get/remove/len、所有規則順守
|
||||
|
||||
Acceptance:
|
||||
- 代表サンプルでString/Array/MapがNyash実装で動作し、Rust実装をリンクせずに通る
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_10_5_core_std_nyash_impl.md
|
||||
|
||||
## Phase 11-14: Infrastructure & Polish
|
||||
|
||||
### Phase 11: MIR Optimization Framework
|
||||
- エスケープ解析基盤
|
||||
- 型特殊化・ボックス化解除
|
||||
- デッドコード除去
|
||||
|
||||
### Phase 12: Advanced JIT Features
|
||||
- Profile-guided optimization
|
||||
- インライン展開
|
||||
- レジスタ割り当て最適化
|
||||
|
||||
### Phase 13: Production Readiness
|
||||
- GC統合最適化
|
||||
- メモリ使用量最適化
|
||||
- 起動時間短縮
|
||||
|
||||
### Phase 14: Packaging/CI polish
|
||||
|
||||
Summary:
|
||||
- Windows/Linux の配布パッケージ化と CI 整備。
|
||||
|
||||
Scope/Tasks:
|
||||
- GitHub Actions: Windows(MSVC)/WSL+cargo-xwin のマトリクス
|
||||
- dist/: nyash(.exe) + LICENSE/README 同梱
|
||||
|
||||
Acceptance Criteria:
|
||||
- リリースアーティファクトが自動生成される
|
||||
|
||||
================================================================================
|
||||
🧠 AI大会議 + 実用優先戦略で得られた技術的知見 (2025-08-14更新)
|
||||
================================================================================
|
||||
|
||||
## Gemini先生の助言（修正適用）
|
||||
✅ エスケープ解析・ボックス化解除が性能の鍵
|
||||
✅ wasmtime compileは短期的に実用的 → **Phase 9で最優先実装**
|
||||
✅ WASM実行は確実に高速（13.5倍実証済み）
|
||||
🔄 Cranelift → LLVM段階的アプローチ → **実用優先でLLVM直接へ**
|
||||
|
||||
## codex先生の助言（重点化）
|
||||
✅ MIR前倒し実装推奨（全バックエンドが恩恵）
|
||||
✅ wasmtime互換性管理が重要 → **AOT実装で最重要**
|
||||
✅ CPU差異対応 (baseline/v3二段ビルド)
|
||||
✅ 起動時間・割当削減・配布体験がKPI → **AOT価値の核心**
|
||||
|
||||
## Claude統合分析（実用優先）
|
||||
✅ 実用価値最大化: WASM+AOTで十分な競争力
|
||||
✅ 開発効率: Cranelift JITの恩恵限定的（cargo build変わらず）
|
||||
✅ Everything is Box最適化が差別化の核心
|
||||
✅ 時間効率: 2-3ヶ月節約でLLVM集中投資
|
||||
|
||||
## 🎯 実用優先戦略の確定理由
|
||||
- **ユーザー体験**: WASM既に動作、AOTで配布価値追加
|
||||
- **開発効率**: Cranelift JITは重複投資（Rust開発環境改善せず）
|
||||
- **競合優位**: AOT+LLVM早期実現で差別化
|
||||
- **リソース効果**: 限られた開発時間の最大効率化
|
||||
|
||||
================================================================================
|
||||
💡 Copilot様への具体的お願い・相談事項
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.6 VM性能改善 (最優先)
|
||||
|
||||
### VM実行時間詳細測定・プロファイリング
|
||||
❓ 命令ディスパッチのボトルネック特定方法は？
|
||||
❓ HashMap操作の最適化戦略は？
|
||||
❓ デバッグ出力削除による性能改善測定は？
|
||||
|
||||
### VM最適化実装
|
||||
❓ Direct threading実装の現実的アプローチは？
|
||||
❓ Register-based VM への移行可能性は？
|
||||
❓ Box操作インライン化の効果的な実装は？
|
||||
|
||||
## 🚀 長期戦略相談
|
||||
|
||||
### インタープリター併用戦略
|
||||
❓ 開発時と本番時の最適な使い分け方法は？
|
||||
❓ インタープリターとコンパイラの互換性保証は？
|
||||
❓ Pythonライクな実用性の実現方法は？
|
||||
|
||||
### Phase 10 LLVM実現可能性調査 (研究段階)
|
||||
❓ MIR→LLVM IR変換の基本的な実装戦略は？
|
||||
❓ Box型のLLVM表現として最適なアプローチは？
|
||||
❓ C-ABIとの統合によるプラグイン連携可能性は？
|
||||
❓ 現実的な開発期間での完成可能性評価は？
|
||||
|
||||
### Everything is Box最適化
|
||||
❓ Box操作の根本的高速化戦略は？
|
||||
❓ エスケープ解析によるスタック化判定は？
|
||||
❓ 型特殊化・ボックス化解除の実装戦略は？
|
||||
|
||||
### ベンチマーク戦略
|
||||
❓ インタープリター/VM/WASM/LLVMの性能比較方法は？
|
||||
❓ 非同期処理のベンチマーク設計は？
|
||||
❓ 実用アプリケーションでの測定指標は？
|
||||
|
||||
================================================================================
|
||||
📊 進捗管理・コミュニケーション
|
||||
================================================================================
|
||||
|
||||
## 🤝 協調開発ルール
|
||||
|
||||
### コミット・マージ戦略
|
||||
✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
|
||||
✅ ベンチマーク機能は最優先で維持
|
||||
✅ CLI統合は両機能を統合的に対応
|
||||
✅ 競合発生時は機能優先度で解決
|
||||
|
||||
### 進捗報告
|
||||
📅 週次: 進捗状況をCURRENT_TASK.mdに反映
|
||||
📅 完了時: 新機能のベンチマーク結果を共有
|
||||
📅 問題発生: AI大会議で技術的相談
|
||||
|
||||
### 品質保証
|
||||
✅ cargo check でビルドエラーなし
|
||||
✅ 既存ベンチマークが regression なし
|
||||
✅ 新機能のドキュメント整備
|
||||
✅ テストケース追加・CI通過
|
||||
|
||||
================================================================================
|
||||
🎯 期待される成果・インパクト
|
||||
================================================================================
|
||||
|
||||
## Phase 8-9完了時の成果 (達成済み・進行中)
|
||||
🏆 RefNew/RefGet/RefSet WASM完全動作
|
||||
🏆 Box操作ベンチマーク追加
|
||||
🏆 メモリレイアウト最適化効果測定
|
||||
🏆 26命令MIR階層化完了（Phase 8.5）
|
||||
🔄 **VM性能改善進行中（Phase 8.6）** - GitHub Issue #112
|
||||
🏆 **Phase 9.75g-0 BID-FFI Plugin System完全完了**
|
||||
🏆 警告削減100%達成（Phase 9.75j）
|
||||
🏆 BoxCall実装・wasmtime更新（Phase 9.77）
|
||||
|
||||
## Phase 10以降の展望
|
||||
🚀 **WASM復旧完了** (Phase 9.77): 基本機能の完全動作
|
||||
🚀 **LLVM Direct AOT** (Phase 10): 100-1000倍高速化
|
||||
🚀 **非同期ネイティブ実装** (Phase 10.2): async/await完全対応
|
||||
🚀 **インタープリター併用** : 開発・本番両対応
|
||||
|
||||
## 言語としての完成度向上
|
||||
💎 Everything is Box哲学のネイティブ実現
|
||||
💎 インタープリター＋コンパイラの最適併用
|
||||
💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）
|
||||
💎 Pythonライクな実用性＋C++並みの性能
|
||||
|
||||
================================================================================
|
||||
📞 連絡・相談方法
|
||||
================================================================================
|
||||
|
||||
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
|
||||
|
||||
1. 📝 GitHub Issues・Pull Request
|
||||
2. 📋 docs/CURRENT_TASK.md コメント
|
||||
3. 🤖 AI大会議 (重要な技術決定)
|
||||
4. 💬 コミットメッセージでの進捗共有
|
||||
|
||||
どんな小さなことでも相談大歓迎です！
|
||||
一緒にNyashを最高の言語にしていきましょう🚀
|
||||
|
||||
================================================================================
|
||||
最終更新: 2025-08-19 (Phase 9.75g-0完了・VM性能改善最優先・LLVM調査段階化)
|
||||
作成者: Claude (BID-FFIプラグインシステム完了 + 最新優先順位反映)
|
||||
|
||||
🎯 重要な変更点:
|
||||
- ✅ **Phase 9.75g-0 BID-FFI Plugin System完全完了** (動的プラグインシステム実現)
|
||||
- 🔄 **Phase 8.6 VM性能改善を最優先** (進行中 - GitHub Issue #112)
|
||||
- 📦 **Phase 9.8 BIDレジストリ** (Phase 8.6完了後の次期重点)
|
||||
- 🔍 **Phase 10 LLVM** (実現可能性調査・検証段階として位置づけ)
|
||||
- 🌟 **ネームスペース統合戦略変更** (LLVM完成後に4バックエンド統合設計)
|
||||
- 📅 **優先順位明確化**: VM性能 → BIDレジストリ → LLVM調査 の順序
|
||||
================================================================================
|
||||
@ -0,0 +1,854 @@
|
||||
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-14 全体ロードマップ)
|
||||
# Generated: 2025-08-14 (Git履歴から復元・更新)
|
||||
# Purpose: Claude×Copilot協調開発のための情報共有
|
||||
|
||||
================================================================================
|
||||
🎯 次期最優先タスク (Phase 8.5以降)
|
||||
================================================================================
|
||||
|
||||
## 🚀 Phase 8.4完了報告 (2025-08-14)
|
||||
Status: ✅ 完了 (Copilot PR #56マージ済み)
|
||||
|
||||
### ✅ AST→MIR Lowering完全実装
|
||||
- User-defined Box: `box DataBox { init { value } }`
|
||||
- Object creation: `new DataBox(42)`
|
||||
- Field access: `obj.value`
|
||||
- Method calls: `c.increment()`
|
||||
- Delegation: `from Parent.greet()`
|
||||
- Static Main互換性維持
|
||||
|
||||
### 🧪 統合テスト結果（2025-08-14）
|
||||
- ✅ **AST→MIR**: 完全動作
|
||||
- ✅ **インタープリター**: 完全動作（結果30）
|
||||
- 🚨 **VM**: 動作するが結果が`void`（要修正）
|
||||
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
|
||||
|
||||
### 📋 発見された課題
|
||||
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
|
||||
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
|
||||
- 次期Phase 8.5での25命令MIR階層化が必要
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.5: MIR 25命令階層化（最優先）
|
||||
Status: ⭐ **CRITICAL**
|
||||
Priority: **最重要** (Phase 8.4完了直後の次期目標)
|
||||
|
||||
### 🎯 実装目標
|
||||
ChatGPT5 + AI大会議決定版25命令MIR実装
|
||||
- 期間: 3週間
|
||||
- 効果: VM/WASM問題根本解決
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
|
||||
|
||||
### 📋 25命令セマンティック階層化
|
||||
**Tier-0: 普遍コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（12命令）**
|
||||
```mir
|
||||
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, Safepoint,
|
||||
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, Adopt, Release, MemCopy, AtomicFence
|
||||
```
|
||||
|
||||
### 🎯 期待される効果
|
||||
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
|
||||
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
|
||||
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
|
||||
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善（緊急）
|
||||
Status: 🚨 **緊急**
|
||||
Priority: **High** (Phase 8.5完了後)
|
||||
|
||||
### 🚨 緊急問題
|
||||
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
|
||||
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
|
||||
|
||||
### 📋 技術的課題
|
||||
- VM実行エンジンのプロファイリング
|
||||
- 命令ディスパッチ最適化（threaded code等）
|
||||
- レジスタベースVM化検討
|
||||
- メモリプール最適化
|
||||
- BoxCall実装修正（戻り値問題）
|
||||
|
||||
### 🎯 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- BoxCall戻り値の正常動作
|
||||
- MIR→VM変換時間の短縮
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Testing
|
||||
Status: 📋 **計画済み**
|
||||
Priority: **High** (Phase 8.5-8.6完了後)
|
||||
|
||||
### 🎯 実装目標
|
||||
kilo（テキストエディタ）実装によるfini/weak参照システム実証
|
||||
- 期間: 2週間
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
|
||||
|
||||
### 📋 検証項目
|
||||
- 1000+オブジェクト管理テスト
|
||||
- 循環参照回避確認（weak参照）
|
||||
- fini()伝播の正確性確認
|
||||
- WASM環境での動作確認
|
||||
|
||||
================================================================================
|
||||
🗺️ Phase 0-14 全体ロードマップ (復元完了)
|
||||
================================================================================
|
||||
|
||||
## Phase 0: Stabilize native CLI build (Linux/Windows)
|
||||
|
||||
Summary:
|
||||
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
|
||||
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
|
||||
|
||||
Why:
|
||||
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
|
||||
|
||||
Scope:
|
||||
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
|
||||
- CLI オプションの動作点検（--dump-mir / --verify）。
|
||||
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
|
||||
|
||||
Tasks:
|
||||
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
|
||||
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
|
||||
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
|
||||
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
|
||||
|
||||
Acceptance Criteria:
|
||||
- Linux/Windows で `cargo build --bin nyash` が成功する。
|
||||
- `local_tests/` 配下の簡単な .nyash が実行できる。
|
||||
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
|
||||
|
||||
Out of Scope:
|
||||
- examples/GUI の修理・最適化。
|
||||
- JIT/AOT/WASM。
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/README.md
|
||||
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
|
||||
- CURRENT_TASK.md
|
||||
|
||||
Copilot Notes:
|
||||
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 1: Minimal MIR + VM backend (lowering + runner)
|
||||
|
||||
Summary:
|
||||
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
|
||||
|
||||
Scope:
|
||||
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
|
||||
- Lowering: リテラル/二項演算/if/loop/return のみ
|
||||
- VM: 上記命令の最小実装
|
||||
|
||||
Tasks:
|
||||
- instruction.rs: 最小命令の定義
|
||||
- builder.rs: 上記 AST 範囲を lowering
|
||||
- vm.rs: 実装 + stats（命令数）
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が最小サンプルで期待通り
|
||||
- `--backend vm` で実行して結果一致
|
||||
|
||||
Out of Scope:
|
||||
- 例外/関数/Box 参照/弱参照
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
|
||||
|
||||
Summary:
|
||||
- 制御フローの網羅と Phi の整合性検証を拡充。
|
||||
|
||||
Scope/Tasks:
|
||||
- if/else nested, loop with breaks, nested loops のスナップショット
|
||||
- Phi の入力ブロック/値の対応を Verifier で強化
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表制御フローの snapshot が安定し、verify も通る
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
|
||||
|
||||
Summary:
|
||||
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
|
||||
- builder.rs: try/catch/finally ノードの下ろし
|
||||
- VM: 例外伝播を最小で（未捕捉はエラー）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表 try/catch/finally のスナップショットと VM 実行
|
||||
|
||||
Out of Scope:
|
||||
- 例外の型体系、詳細な stack map
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 4: Functions and calls (BoxCall minimal)
|
||||
|
||||
Summary:
|
||||
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
|
||||
- builder.rs: FunctionCall/MethodCall の最小対応
|
||||
- VM: 呼び出し/戻り値
|
||||
|
||||
Acceptance Criteria:
|
||||
- 簡単な関数定義/呼び出しの MIR/VM が通る
|
||||
|
||||
Out of Scope:
|
||||
- 可変長/キーワード引数、FFI
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.0: Parser/AST stabilization for lowering
|
||||
|
||||
Summary:
|
||||
- lowering 対象 AST の表現ぶれを修正、安定化。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: If/Loop/Return/Assignment/Local などの統一
|
||||
- Parser: エラー復帰/スパン情報の見直し
|
||||
|
||||
Acceptance Criteria:
|
||||
- builder.rs の分岐がシンプル化、テストが安定
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.1: Control-flow edge cases + verifier hardening
|
||||
|
||||
Summary:
|
||||
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
|
||||
|
||||
Scope/Tasks:
|
||||
- Verifier: 未終端ブロック検出、到達不能検出
|
||||
- Builder: Jump/Branch の生成前後の状態管理改善
|
||||
|
||||
Acceptance Criteria:
|
||||
- 不正ケースを含むスナップショット/verify が緑
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
|
||||
|
||||
Summary:
|
||||
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
|
||||
- Lowering: body を Program に変換して既存経路に渡す
|
||||
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が static Main サンプルで成功
|
||||
- `--backend vm` で実行成功
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
|
||||
|
||||
Summary:
|
||||
- 参照/弱参照/バリア（no-op）を最小導入。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
|
||||
- Lowering: New/FieldAccess/MethodCall の最小対応
|
||||
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表サンプルで dump/VM/verify が通る
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 7: Async model (nowait/await) in MIR
|
||||
|
||||
Summary:
|
||||
- nowait/await を MIR に導入し、現行 FutureBox と連携。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: FutureNew/FutureSet/Await（スレッドベース）
|
||||
- Lowering: nowait→Future 作成、await→wait_and_get
|
||||
- VM: FutureBox 実装を利用
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表ケースで正しく並行実行→await 回収
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
|
||||
|
||||
Summary:
|
||||
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
|
||||
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
|
||||
|
||||
Scope/Tasks:
|
||||
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
|
||||
- 線形メモリと簡易ヒープ（bump/自由リスト）
|
||||
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
|
||||
|
||||
Acceptance Criteria:
|
||||
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
|
||||
- Ref 系がメモリ上で正しく動作（PoC2）
|
||||
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
|
||||
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/README.md（Phase 8 節）
|
||||
- docs/説明書/wasm/*（ユーザー向けメモ）
|
||||
|
||||
### Phase 8.3 完了状況 (2025-08-14)
|
||||
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
|
||||
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
|
||||
✅ CLI統合完了
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
|
||||
|
||||
Summary:
|
||||
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
|
||||
- Phase 8.3のBox操作WASMを実際にテスト可能にする
|
||||
|
||||
Priority: **Critical** (現在の最優先事項)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 実装範囲
|
||||
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
|
||||
- [ ] オブジェクト生成: `new DataBox()`
|
||||
- [ ] フィールドアクセス: `obj.field`
|
||||
- [ ] フィールド代入: `obj.field = value`
|
||||
- [ ] from構文: `from Parent.method()`
|
||||
- [ ] override構文: `override method() { ... }`
|
||||
|
||||
### 成功基準
|
||||
- Phase 8.3のBox操作WASMが実際に動作
|
||||
- test_wasm_box_ops.nyash が正常実行
|
||||
- ユーザー定義Boxの完全サポート
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
|
||||
|
||||
Summary:
|
||||
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の25命令階層化
|
||||
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
|
||||
- 二相ロワリング: 25命令維持パス（VM/JIT/AOT）+ 20+intrinsic降格パス（WASM/最小実装）
|
||||
|
||||
Priority: High (Phase 8.4完了後)
|
||||
Expected Duration: 3週間
|
||||
|
||||
### AI大会議分析結果
|
||||
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
|
||||
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
|
||||
- セマンティック階層化で意味保持が最適化の鍵
|
||||
|
||||
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
|
||||
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
|
||||
- マイクロベンチ実測でパフォーマンス検証
|
||||
|
||||
### 確定版MIR（25命令）- ChatGPT5完全仕様
|
||||
**Tier-0: 普遍的コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（12命令）**
|
||||
```mir
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
|
||||
BoxFieldStore, // Boxのフィールド書き（mut効果）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則検証付き）
|
||||
WeakNew, // weak ハンドル生成（非所有リンク作成）
|
||||
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
|
||||
WeakCheck, // weak の生存確認（bool）
|
||||
Send, // Bus送信（io効果）
|
||||
Recv // Bus受信（io効果）
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
### 二相ロワリング戦略
|
||||
- パスA: VM/JIT/AOT向け（25命令のまま最適化）
|
||||
- パスB: WASM/最小実装向け（25→20+intrinsic降格）
|
||||
- バックエンド能力に応じて最適形式選択
|
||||
|
||||
### 効果（Effect）システム（ChatGPT5設計）
|
||||
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
|
||||
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
- **io**: Send, Recv, Safepoint, AtomicFence
|
||||
- **control**: Branch, Jump, Return, TailCall
|
||||
- **context依存**: Call, BoxCall（呼び先効果に従属）
|
||||
|
||||
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
|
||||
|
||||
### 検証（Verifier）要件
|
||||
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
|
||||
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
|
||||
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
|
||||
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
|
||||
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
|
||||
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
|
||||
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
|
||||
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
|
||||
|
||||
### 成功基準
|
||||
- [ ] **25命令完全実装**: ChatGPT5仕様の完璧な実装
|
||||
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
|
||||
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
|
||||
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
|
||||
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
|
||||
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
|
||||
|
||||
### バックエンド指針（ChatGPT5設計）
|
||||
- **Interpreter**: 25命令を素直に実装（正しさの基準）
|
||||
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
|
||||
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
|
||||
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
|
||||
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善 (緊急)
|
||||
|
||||
Summary:
|
||||
- VMがインタープリターより遅い問題（0.9倍）を解決
|
||||
- MIR→VM実行の最適化でインタープリターを上回る性能へ
|
||||
|
||||
Priority: High (Phase 8.5完了後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### 問題分析
|
||||
**現状**: VM (119.80ms) < Interpreter (110.10ms)
|
||||
**推定原因**:
|
||||
- MIR変換オーバーヘッド
|
||||
- VM命令ディスパッチの非効率性
|
||||
- メモリ管理コスト
|
||||
|
||||
### 技術的アプローチ
|
||||
- [ ] VM実行エンジンのプロファイリング
|
||||
- [ ] 命令ディスパッチ最適化（threaded code等）
|
||||
- [ ] レジスタベースVM化検討
|
||||
- [ ] メモリプール最適化
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- VM実装のボトルネック特定
|
||||
- 効率的な命令ディスパッチ実装
|
||||
- スタックマシン vs レジスタマシン判断
|
||||
|
||||
### 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- MIR→VM変換時間の短縮
|
||||
- メモリ使用量の削減
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
|
||||
|
||||
Summary:
|
||||
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
|
||||
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
|
||||
|
||||
Priority: High (Phase 8.4-8.6完了直後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### Phase 8.7A: kilo（テキストエディタ）
|
||||
**技術的特徴**:
|
||||
- サイズ: <1k LOC（超小型、最初の成功体験）
|
||||
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
|
||||
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
|
||||
|
||||
**実装範囲**:
|
||||
- [ ] Editor/Row/EditorState基本構造実装
|
||||
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
|
||||
- [ ] fini()システムによる自動メモリ解放
|
||||
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
|
||||
|
||||
**検証ポイント**:
|
||||
- [ ] Editor削除でRows自動解放確認
|
||||
- [ ] 相互参照でメモリリークなし確認
|
||||
- [ ] weak参照の自動null化確認
|
||||
- [ ] fini()伝播の正確性確認
|
||||
|
||||
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
|
||||
**将来実装**（JIT実装後）:
|
||||
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
|
||||
- I/O管理: ソケット・ファイルハンドルの確実解放
|
||||
- 同時接続・早期切断・例外経路でのfini伝播テスト
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- 実用的なメモリ管理パターンの実装
|
||||
- weak参照構文の適切な使用
|
||||
- デバッグ支援機能（--debug-memory, --trace-weak）
|
||||
- WASM環境でのメモリ管理互換性
|
||||
|
||||
### 成功基準
|
||||
- [ ] 全テストケースでメモリリークなし
|
||||
- [ ] 循環参照でも正常解放確認
|
||||
- [ ] WASM実行でもメモリ管理正常
|
||||
- [ ] ベンチマーク性能劣化なし
|
||||
|
||||
### 期待される効果
|
||||
- Nyashメモリ管理システムの実用性実証
|
||||
- Everything is Box哲学の実用レベル確認
|
||||
- メモリ安全なプログラミングパターン確立
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🚀 Phase 9: AOT WASM実装（最優先）
|
||||
|
||||
Summary:
|
||||
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
|
||||
|
||||
Scope/Tasks:
|
||||
- `wasmtime compile` 統合実装
|
||||
- `--compile-native` / `--aot` CLI追加
|
||||
- 単一バイナリ梱包（`include_bytes!`）
|
||||
- 起動時間・配布サイズ最適化
|
||||
|
||||
Acceptance Criteria:
|
||||
- `nyash --compile-native app.nyash -o app.exe` 動作
|
||||
- 起動時間大幅短縮（JIT起動コスト除去）
|
||||
- 配布可能実行ファイル生成
|
||||
|
||||
Priority: **Critical** (Phase 8.6完了直後)
|
||||
Expected Duration: 2-3週間
|
||||
|
||||
### 技術的実装詳細
|
||||
🤖 Copilot協力期待:
|
||||
- wasmtime::Config統一実装
|
||||
- .cwasm生成・実行パイプライン
|
||||
- 互換性キー管理（CPU機能・wasmtimeバージョン）
|
||||
- パッケージング（単一バイナリ梱包）
|
||||
|
||||
### パフォーマンス目標
|
||||
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
|
||||
- 配布ファイルサイズ: <10MB目標
|
||||
- 起動時間: <100ms目標
|
||||
|
||||
### 期待される効果
|
||||
- **即座実用価値**: 配布可能実行ファイル生成
|
||||
- **差別化優位**: Everything is BoxのネイティブAOT実現
|
||||
- **LLVM準備**: AOT基盤確立でLLVM移行準備
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🌐 Phase 9.5: HTTPサーバー実用テスト（AOT検証）
|
||||
|
||||
Summary:
|
||||
- AOT実装完了後の複雑アプリケーション検証（並行処理・メモリ管理・実用性能）
|
||||
|
||||
Scope/Tasks:
|
||||
- tiny-web-server実装（HTTP/1.1対応）
|
||||
- 同時接続・早期切断・例外経路テスト
|
||||
- AOT環境での真の性能測定
|
||||
- 配布可能HTTPサーバーデモ
|
||||
|
||||
Acceptance Criteria:
|
||||
- `http_server.exe`として配布可能
|
||||
- 同時100接続でメモリリークなし
|
||||
- fini()システム確実動作（I/Oハンドル解放）
|
||||
- AOT性能でベンチマーク測定
|
||||
|
||||
Priority: High (Phase 9完了直後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### 技術的複雑度
|
||||
```nyash
|
||||
box HTTPServer {
|
||||
init { clients, requests, handlers }
|
||||
|
||||
acceptConnections() {
|
||||
loop(me.running) {
|
||||
local client = me.socket.accept()
|
||||
nowait me.handleClient(client) // 非同期並行処理
|
||||
}
|
||||
}
|
||||
|
||||
handleClient(client) {
|
||||
local request = client.readRequest()
|
||||
local response = me.processRequest(request)
|
||||
client.sendResponse(response)
|
||||
client.fini() // 重要: 確実なリソース解放
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 検証ポイント
|
||||
- **並行処理**: nowait/awaitのAOT実行性能
|
||||
- **メモリ管理**: Server→Clients→Requests木構造+weak参照
|
||||
- **I/Oリソース**: ソケット・ファイルハンドルの確実解放
|
||||
- **実用性能**: リアルHTTP負荷でのAOT効果測定
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- Socket・HTTP実装の効率化
|
||||
- 複雑なメモリ管理パターン検証
|
||||
- 負荷テスト・ベンチマーク整備
|
||||
- AOT最適化効果の定量測定
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏆 Phase 10: LLVM Direct AOT（最高性能実現）
|
||||
|
||||
Summary:
|
||||
- MIR→LLVM IR直接変換による最高性能AOT実現（Cranelift JITスキップ）
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR→LLVM IR lowering実装
|
||||
- エスケープ解析・ボックス化解除
|
||||
- LTO・PGO・高度最適化統合
|
||||
- Everything is Box最適化
|
||||
|
||||
Acceptance Criteria:
|
||||
- 1000倍高速化達成
|
||||
- プロダクションレベル最適化
|
||||
- 他言語との競争力確立
|
||||
|
||||
Priority: Medium (Phase 9.5完了後)
|
||||
Expected Duration: 4-6ヶ月
|
||||
|
||||
### 技術アプローチ
|
||||
🤖 Copilot協力期待:
|
||||
- **LLVM統合**: MIR→LLVM IR変換基盤
|
||||
- **エスケープ解析**: Box→スタック値最適化
|
||||
- **型特殊化**: コンパイル時型推論・特殊化
|
||||
- **LTO統合**: Link-time optimization
|
||||
- **PGO対応**: Profile-guided optimization
|
||||
|
||||
### Everything is Box最適化戦略
|
||||
- **Box回避**: スタック割り当て・直接レジスタ配置
|
||||
- **NaN Boxing**: 効率的な値表現
|
||||
- **型推論**: コンパイル時型特定・最適化
|
||||
- **メモリレイアウト**: 連続配置・キャッシュ効率
|
||||
|
||||
### パフォーマンス目標
|
||||
- **実行性能**: 1000倍高速化（現在13.5倍 → 目標13500倍相当）
|
||||
- **メモリ効率**: Box割当数80%削減
|
||||
- **起動時間**: ネイティブレベル（<10ms）
|
||||
- **競合比較**: C/C++/Rust並みの性能
|
||||
|
||||
### Cranelift JIT位置づけ変更
|
||||
**Phase 12以降の将来オプション**:
|
||||
- JIT開発体験向上（nyashプログラマー向け）
|
||||
- REPL・インタラクティブ実行
|
||||
- プロファイル駆動最適化
|
||||
- 言語完成後の付加価値機能
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 11-14: Infrastructure & Polish
|
||||
|
||||
### Phase 11: MIR Optimization Framework
|
||||
- エスケープ解析基盤
|
||||
- 型特殊化・ボックス化解除
|
||||
- デッドコード除去
|
||||
|
||||
### Phase 12: Advanced JIT Features
|
||||
- Profile-guided optimization
|
||||
- インライン展開
|
||||
- レジスタ割り当て最適化
|
||||
|
||||
### Phase 13: Production Readiness
|
||||
- GC統合最適化
|
||||
- メモリ使用量最適化
|
||||
- 起動時間短縮
|
||||
|
||||
### Phase 14: Packaging/CI polish
|
||||
|
||||
Summary:
|
||||
- Windows/Linux の配布パッケージ化と CI 整備。
|
||||
|
||||
Scope/Tasks:
|
||||
- GitHub Actions: Windows(MSVC)/WSL+cargo-xwin のマトリクス
|
||||
- dist/: nyash(.exe) + LICENSE/README 同梱
|
||||
|
||||
Acceptance Criteria:
|
||||
- リリースアーティファクトが自動生成される
|
||||
|
||||
================================================================================
|
||||
🧠 AI大会議 + 実用優先戦略で得られた技術的知見 (2025-08-14更新)
|
||||
================================================================================
|
||||
|
||||
## Gemini先生の助言（修正適用）
|
||||
✅ エスケープ解析・ボックス化解除が性能の鍵
|
||||
✅ wasmtime compileは短期的に実用的 → **Phase 9で最優先実装**
|
||||
✅ WASM実行は確実に高速（13.5倍実証済み）
|
||||
🔄 Cranelift → LLVM段階的アプローチ → **実用優先でLLVM直接へ**
|
||||
|
||||
## codex先生の助言（重点化）
|
||||
✅ MIR前倒し実装推奨（全バックエンドが恩恵）
|
||||
✅ wasmtime互換性管理が重要 → **AOT実装で最重要**
|
||||
✅ CPU差異対応 (baseline/v3二段ビルド)
|
||||
✅ 起動時間・割当削減・配布体験がKPI → **AOT価値の核心**
|
||||
|
||||
## Claude統合分析（実用優先）
|
||||
✅ 実用価値最大化: WASM+AOTで十分な競争力
|
||||
✅ 開発効率: Cranelift JITの恩恵限定的（cargo build変わらず）
|
||||
✅ Everything is Box最適化が差別化の核心
|
||||
✅ 時間効率: 2-3ヶ月節約でLLVM集中投資
|
||||
|
||||
## 🎯 実用優先戦略の確定理由
|
||||
- **ユーザー体験**: WASM既に動作、AOTで配布価値追加
|
||||
- **開発効率**: Cranelift JITは重複投資（Rust開発環境改善せず）
|
||||
- **競合優位**: AOT+LLVM早期実現で差別化
|
||||
- **リソース効果**: 限られた開発時間の最大効率化
|
||||
|
||||
================================================================================
|
||||
💡 Copilot様への具体的お願い・相談事項
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.3完了・次期フェーズ準備
|
||||
|
||||
### MIRダイエット準備
|
||||
❓ 現在35命令→20命令削減のintrinsic戦略実装は？
|
||||
❓ ChatGPT5推奨の3-point setアプローチ最適化は？
|
||||
❓ Portability Contract v0での互換性確保方法は？
|
||||
|
||||
### Phase 9 AOT WASM実装（最優先）
|
||||
❓ wasmtime compileの実用配備方法は？
|
||||
❓ .cwasm生成・単一バイナリ梱包戦略は？
|
||||
❓ 互換性キー管理（CPU機能・wasmtimeバージョン）は？
|
||||
❓ 起動時間最適化の実装アプローチは？
|
||||
|
||||
### Phase 9.5 HTTPサーバー検証
|
||||
❓ Socket・HTTP実装の効率的な設計は？
|
||||
❓ 並行処理でのメモリ管理パターンは？
|
||||
❓ AOT環境でのI/Oリソース管理は？
|
||||
❓ 負荷テスト・ベンチマーク設計は？
|
||||
|
||||
### Phase 10 LLVM Direct AOT
|
||||
❓ MIR→LLVM IR変換の効率実装は？
|
||||
❓ エスケープ解析・ボックス化解除の実装戦略は？
|
||||
❓ LTO・PGO統合の技術的ハードルは？
|
||||
|
||||
## 🚀 長期戦略相談
|
||||
|
||||
### Everything is Box最適化
|
||||
❓ Box操作の根本的高速化戦略は？
|
||||
❓ エスケープ解析によるスタック化判定は？
|
||||
❓ 型特殊化・ボックス化解除の実装戦略は？
|
||||
|
||||
### ベンチマーク拡張
|
||||
❓ AOT性能測定の追加指標は？
|
||||
❓ 1000倍高速化実現のマイルストーン設計は？
|
||||
❓ 他言語(JavaScript V8, Rust, C++)との競争力分析は？
|
||||
❓ HTTPサーバー負荷テストの効率設計は？
|
||||
|
||||
================================================================================
|
||||
📊 進捗管理・コミュニケーション
|
||||
================================================================================
|
||||
|
||||
## 🤝 協調開発ルール
|
||||
|
||||
### コミット・マージ戦略
|
||||
✅ 大きな変更前にはdocs/CURRENT_TASK.mdで情報共有
|
||||
✅ ベンチマーク機能は最優先で維持
|
||||
✅ CLI統合は両機能を統合的に対応
|
||||
✅ 競合発生時は機能優先度で解決
|
||||
|
||||
### 進捗報告
|
||||
📅 週次: 進捗状況をCURRENT_TASK.mdに反映
|
||||
📅 完了時: 新機能のベンチマーク結果を共有
|
||||
📅 問題発生: AI大会議で技術的相談
|
||||
|
||||
### 品質保証
|
||||
✅ cargo check でビルドエラーなし
|
||||
✅ 既存ベンチマークが regression なし
|
||||
✅ 新機能のドキュメント整備
|
||||
✅ テストケース追加・CI通過
|
||||
|
||||
================================================================================
|
||||
🎯 期待される成果・インパクト
|
||||
================================================================================
|
||||
|
||||
## Phase 8完了時の成果 (達成済み)
|
||||
🏆 RefNew/RefGet/RefSet WASM完全動作
|
||||
🏆 Box操作ベンチマーク追加
|
||||
🏆 メモリレイアウト最適化効果測定
|
||||
🏆 オブジェクト指向プログラミングWASM対応
|
||||
🏆 25命令MIR階層化完了（Phase 8.5）
|
||||
🏆 VM性能改善完了（Phase 8.6）
|
||||
|
||||
## Phase 9-10実用優先展望
|
||||
🚀 **AOT WASM実装** (Phase 9 - 2-3週間): 配布可能実行ファイル
|
||||
🚀 **HTTPサーバー検証** (Phase 9.5 - 2週間): 実用アプリデモ
|
||||
🚀 **LLVM Direct AOT** (Phase 10 - 4-6ヶ月): 1000倍高速化
|
||||
🚀 **実用競争力確立**: 他言語との差別化完成
|
||||
|
||||
## 言語としての完成度向上
|
||||
💎 Everything is Box哲学のネイティブ実現
|
||||
💎 開発効率性と実行性能の両立
|
||||
💎 4つの実行形態対応（Interpreter/VM/WASM/AOT）+ 将来JIT
|
||||
💎 現代的言語としての地位確立
|
||||
|
||||
================================================================================
|
||||
📞 連絡・相談方法
|
||||
================================================================================
|
||||
|
||||
技術的相談や進捗報告は、以下の方法でお気軽にどうぞ：
|
||||
|
||||
1. 📝 GitHub Issues・Pull Request
|
||||
2. 📋 docs/CURRENT_TASK.md コメント
|
||||
3. 🤖 AI大会議 (重要な技術決定)
|
||||
4. 💬 コミットメッセージでの進捗共有
|
||||
|
||||
どんな小さなことでも相談大歓迎です！
|
||||
一緒にNyashを最高の言語にしていきましょう🚀
|
||||
|
||||
================================================================================
|
||||
最終更新: 2025-08-14 (実用優先戦略・Phase 9-10再設計完了)
|
||||
作成者: Claude (AI大会議結果 + 実用優先戦略統合)
|
||||
|
||||
🎯 重要な変更点:
|
||||
- Phase 9: JIT planning → AOT WASM実装（最優先）
|
||||
- Phase 9.5: HTTPサーバー実用テスト追加（AOT検証）
|
||||
- Phase 10: AOT exploration → LLVM Direct AOT（最高性能）
|
||||
- Cranelift JIT: Phase 12以降の将来オプションに変更
|
||||
- HTTPサーバー: kilo後のタイミングで実用性能検証に特化
|
||||
================================================================================
|
||||
@ -0,0 +1,657 @@
|
||||
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-9.4 アーカイブ版)
|
||||
# Generated: 2025-08-14 (Git履歴から復元・更新)
|
||||
# Purpose: Claude×Copilot協調開発のための情報共有
|
||||
# Status: Phase 9.5より前のアーカイブ版（2025-08-15分割）
|
||||
|
||||
================================================================================
|
||||
🎯 次期最優先タスク (Phase 8.5以降)
|
||||
================================================================================
|
||||
|
||||
## 🚀 Phase 8.4完了報告 (2025-08-14)
|
||||
Status: ✅ 完了 (Copilot PR #56マージ済み)
|
||||
|
||||
### ✅ AST→MIR Lowering完全実装
|
||||
- User-defined Box: `box DataBox { init { value } }`
|
||||
- Object creation: `new DataBox(42)`
|
||||
- Field access: `obj.value`
|
||||
- Method calls: `c.increment()`
|
||||
- Delegation: `from Parent.greet()`
|
||||
- Static Main互換性維持
|
||||
|
||||
### 🧪 統合テスト結果（2025-08-14）
|
||||
- ✅ **AST→MIR**: 完全動作
|
||||
- ✅ **インタープリター**: 完全動作（結果30）
|
||||
- 🚨 **VM**: 動作するが結果が`void`（要修正）
|
||||
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
|
||||
|
||||
### 📋 発見された課題
|
||||
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
|
||||
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
|
||||
- 次期Phase 8.5での25命令MIR階層化が必要
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.5: MIR 26命令階層化（最優先）
|
||||
Status: ⭐ **CRITICAL**
|
||||
Priority: **最重要** (Phase 8.4完了直後の次期目標)
|
||||
|
||||
### 🎯 実装目標
|
||||
ChatGPT5 + AI大会議決定版26命令MIR実装（ExternCall追加）
|
||||
- 期間: 3週間
|
||||
- 効果: VM/WASM問題根本解決
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
|
||||
|
||||
### 📋 26命令セマンティック階層化
|
||||
**Tier-0: 普遍コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint,
|
||||
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, Adopt, Release, MemCopy, AtomicFence
|
||||
```
|
||||
|
||||
### 🎯 期待される効果
|
||||
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
|
||||
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
|
||||
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
|
||||
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善（緊急）
|
||||
Status: 🚨 **緊急**
|
||||
Priority: **High** (Phase 8.5完了後)
|
||||
|
||||
### 🚨 緊急問題
|
||||
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
|
||||
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
|
||||
|
||||
### 📋 技術的課題
|
||||
- VM実行エンジンのプロファイリング
|
||||
- 命令ディスパッチ最適化（threaded code等）
|
||||
- レジスタベースVM化検討
|
||||
- メモリプール最適化
|
||||
- BoxCall実装修正（戻り値問題）
|
||||
|
||||
### 🎯 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- BoxCall戻り値の正常動作
|
||||
- MIR→VM変換時間の短縮
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Testing
|
||||
Status: 📋 **計画済み**
|
||||
Priority: **High** (Phase 8.5-8.6完了後)
|
||||
|
||||
### 🎯 実装目標
|
||||
kilo（テキストエディタ）実装によるfini/weak参照システム実証
|
||||
- 期間: 2週間
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
|
||||
|
||||
### 📋 検証項目
|
||||
- 1000+オブジェクト管理テスト
|
||||
- 循環参照回避確認（weak参照）
|
||||
- fini()伝播の正確性確認
|
||||
- WASM環境での動作確認
|
||||
|
||||
================================================================================
|
||||
🗺️ Phase 0-14 全体ロードマップ (復元完了)
|
||||
================================================================================
|
||||
|
||||
## Phase 0: Stabilize native CLI build (Linux/Windows)
|
||||
|
||||
Summary:
|
||||
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
|
||||
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
|
||||
|
||||
Why:
|
||||
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
|
||||
|
||||
Scope:
|
||||
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
|
||||
- CLI オプションの動作点検（--dump-mir / --verify）。
|
||||
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
|
||||
|
||||
Tasks:
|
||||
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
|
||||
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
|
||||
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
|
||||
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
|
||||
|
||||
Acceptance Criteria:
|
||||
- Linux/Windows で `cargo build --bin nyash` が成功する。
|
||||
- `local_tests/` 配下の簡単な .nyash が実行できる。
|
||||
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
|
||||
|
||||
Out of Scope:
|
||||
- examples/GUI の修理・最適化。
|
||||
- JIT/AOT/WASM。
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/README.md
|
||||
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
|
||||
- CURRENT_TASK.md
|
||||
|
||||
Copilot Notes:
|
||||
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 1: Minimal MIR + VM backend (lowering + runner)
|
||||
|
||||
Summary:
|
||||
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
|
||||
|
||||
Scope:
|
||||
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
|
||||
- Lowering: リテラル/二項演算/if/loop/return のみ
|
||||
- VM: 上記命令の最小実装
|
||||
|
||||
Tasks:
|
||||
- instruction.rs: 最小命令の定義
|
||||
- builder.rs: 上記 AST 範囲を lowering
|
||||
- vm.rs: 実装 + stats（命令数）
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が最小サンプルで期待通り
|
||||
- `--backend vm` で実行して結果一致
|
||||
|
||||
Out of Scope:
|
||||
- 例外/関数/Box 参照/弱参照
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
|
||||
|
||||
Summary:
|
||||
- 制御フローの網羅と Phi の整合性検証を拡充。
|
||||
|
||||
Scope/Tasks:
|
||||
- if/else nested, loop with breaks, nested loops のスナップショット
|
||||
- Phi の入力ブロック/値の対応を Verifier で強化
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表制御フローの snapshot が安定し、verify も通る
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
|
||||
|
||||
Summary:
|
||||
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
|
||||
- builder.rs: try/catch/finally ノードの下ろし
|
||||
- VM: 例外伝播を最小で（未捕捉はエラー）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表 try/catch/finally のスナップショットと VM 実行
|
||||
|
||||
Out of Scope:
|
||||
- 例外の型体系、詳細な stack map
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 4: Functions and calls (BoxCall minimal)
|
||||
|
||||
Summary:
|
||||
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
|
||||
- builder.rs: FunctionCall/MethodCall の最小対応
|
||||
- VM: 呼び出し/戻り値
|
||||
|
||||
Acceptance Criteria:
|
||||
- 簡単な関数定義/呼び出しの MIR/VM が通る
|
||||
|
||||
Out of Scope:
|
||||
- 可変長/キーワード引数、FFI
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.0: Parser/AST stabilization for lowering
|
||||
|
||||
Summary:
|
||||
- lowering 対象 AST の表現ぶれを修正、安定化。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: If/Loop/Return/Assignment/Local などの統一
|
||||
- Parser: エラー復帰/スパン情報の見直し
|
||||
|
||||
Acceptance Criteria:
|
||||
- builder.rs の分岐がシンプル化、テストが安定
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.1: Control-flow edge cases + verifier hardening
|
||||
|
||||
Summary:
|
||||
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
|
||||
|
||||
Scope/Tasks:
|
||||
- Verifier: 未終端ブロック検出、到達不能検出
|
||||
- Builder: Jump/Branch の生成前後の状態管理改善
|
||||
|
||||
Acceptance Criteria:
|
||||
- 不正ケースを含むスナップショット/verify が緑
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
|
||||
|
||||
Summary:
|
||||
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
|
||||
- Lowering: body を Program に変換して既存経路に渡す
|
||||
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が static Main サンプルで成功
|
||||
- `--backend vm` で実行成功
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
|
||||
|
||||
Summary:
|
||||
- 参照/弱参照/バリア（no-op）を最小導入。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
|
||||
- Lowering: New/FieldAccess/MethodCall の最小対応
|
||||
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表サンプルで dump/VM/verify が通る
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 7: Async model (nowait/await) in MIR
|
||||
|
||||
Summary:
|
||||
- nowait/await を MIR に導入し、現行 FutureBox と連携。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: FutureNew/FutureSet/Await（スレッドベース）
|
||||
- Lowering: nowait→Future 作成、await→wait_and_get
|
||||
- VM: FutureBox 実装を利用
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表ケースで正しく並行実行→await 回収
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
|
||||
|
||||
Summary:
|
||||
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
|
||||
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
|
||||
|
||||
Scope/Tasks:
|
||||
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
|
||||
- 線形メモリと簡易ヒープ（bump/自由リスト）
|
||||
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
|
||||
|
||||
Acceptance Criteria:
|
||||
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
|
||||
- Ref 系がメモリ上で正しく動作（PoC2）
|
||||
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
|
||||
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/README.md（Phase 8 節）
|
||||
- docs/説明書/wasm/*（ユーザー向けメモ）
|
||||
|
||||
### Phase 8.3 完了状況 (2025-08-14)
|
||||
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
|
||||
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
|
||||
✅ CLI統合完了
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
|
||||
|
||||
Summary:
|
||||
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
|
||||
- Phase 8.3のBox操作WASMを実際にテスト可能にする
|
||||
|
||||
Priority: **Critical** (現在の最優先事項)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 実装範囲
|
||||
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
|
||||
- [ ] オブジェクト生成: `new DataBox()`
|
||||
- [ ] フィールドアクセス: `obj.field`
|
||||
- [ ] フィールド代入: `obj.field = value`
|
||||
- [ ] from構文: `from Parent.method()`
|
||||
- [ ] override構文: `override method() { ... }`
|
||||
|
||||
### 成功基準
|
||||
- Phase 8.3のBox操作WASMが実際に動作
|
||||
- test_wasm_box_ops.nyash が正常実行
|
||||
- ユーザー定義Boxの完全サポート
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
|
||||
|
||||
Summary:
|
||||
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の26命令階層化（ExternCall追加）
|
||||
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
|
||||
- 二相ロワリング: 26命令維持パス（VM/JIT/AOT）+ 21+intrinsic降格パス（WASM/最小実装）
|
||||
|
||||
Priority: High (Phase 8.4完了後)
|
||||
Expected Duration: 3週間
|
||||
|
||||
### AI大会議分析結果
|
||||
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
|
||||
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
|
||||
- セマンティック階層化で意味保持が最適化の鍵
|
||||
|
||||
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
|
||||
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
|
||||
- マイクロベンチ実測でパフォーマンス検証
|
||||
|
||||
### 確定版MIR（26命令）- ChatGPT5完全仕様 + ExternCall統合
|
||||
**Tier-0: 普遍的コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
|
||||
BoxFieldStore, // Boxのフィールド書き（mut効果）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
ExternCall, // 外部ライブラリをBoxとして呼び出し（Universal Exchange）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則検証付き）
|
||||
WeakNew, // weak ハンドル生成（非所有リンク作成）
|
||||
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
|
||||
WeakCheck, // weak の生存確認（bool）
|
||||
Send, // Bus送信（io効果）
|
||||
Recv // Bus受信（io効果）
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
### 二相ロワリング戦略
|
||||
- パスA: VM/JIT/AOT向け（26命令のまま最適化）
|
||||
- パスB: WASM/最小実装向け（26→21+intrinsic降格）
|
||||
- バックエンド能力に応じて最適形式選択
|
||||
|
||||
### 効果（Effect）システム（ChatGPT5設計 + ExternCall統合）
|
||||
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
|
||||
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
- **io**: Send, Recv, Safepoint, AtomicFence
|
||||
- **control**: Branch, Jump, Return, TailCall
|
||||
- **context依存**: Call, BoxCall, ExternCall（呼び先効果に従属・BID定義に基づく）
|
||||
|
||||
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
|
||||
|
||||
### 検証（Verifier）要件
|
||||
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
|
||||
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
|
||||
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
|
||||
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
|
||||
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
|
||||
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
|
||||
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
|
||||
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
|
||||
|
||||
### 成功基準
|
||||
- [ ] **26命令完全実装**: ChatGPT5仕様 + ExternCall統合の完璧な実装
|
||||
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
|
||||
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
|
||||
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
|
||||
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
|
||||
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
|
||||
|
||||
### バックエンド指針（ChatGPT5設計 + ExternCall統合）
|
||||
- **Interpreter**: 26命令を素直に実装（正しさの基準）
|
||||
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
|
||||
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
|
||||
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
|
||||
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善 (緊急)
|
||||
|
||||
Summary:
|
||||
- VMがインタープリターより遅い問題（0.9倍）を解決
|
||||
- MIR→VM実行の最適化でインタープリターを上回る性能へ
|
||||
|
||||
Priority: High (Phase 8.5完了後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### 問題分析
|
||||
**現状**: VM (119.80ms) < Interpreter (110.10ms)
|
||||
**推定原因**:
|
||||
- MIR変換オーバーヘッド
|
||||
- VM命令ディスパッチの非効率性
|
||||
- メモリ管理コスト
|
||||
|
||||
### 技術的アプローチ
|
||||
- [ ] VM実行エンジンのプロファイリング
|
||||
- [ ] 命令ディスパッチ最適化（threaded code等）
|
||||
- [ ] レジスタベースVM化検討
|
||||
- [ ] メモリプール最適化
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- VM実装のボトルネック特定
|
||||
- 効率的な命令ディスパッチ実装
|
||||
- スタックマシン vs レジスタマシン判断
|
||||
|
||||
### 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- MIR→VM変換時間の短縮
|
||||
- メモリ使用量の削減
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
|
||||
|
||||
Summary:
|
||||
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
|
||||
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
|
||||
|
||||
Priority: High (Phase 8.4-8.6完了直後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### Phase 8.7A: kilo（テキストエディタ）
|
||||
**技術的特徴**:
|
||||
- サイズ: <1k LOC（超小型、最初の成功体験）
|
||||
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
|
||||
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
|
||||
|
||||
**実装範囲**:
|
||||
- [ ] Editor/Row/EditorState基本構造実装
|
||||
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
|
||||
- [ ] fini()システムによる自動メモリ解放
|
||||
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
|
||||
|
||||
**検証ポイント**:
|
||||
- [ ] Editor削除でRows自動解放確認
|
||||
- [ ] 相互参照でメモリリークなし確認
|
||||
- [ ] weak参照の自動null化確認
|
||||
- [ ] fini()伝播の正確性確認
|
||||
|
||||
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
|
||||
**将来実装**（JIT実装後）:
|
||||
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
|
||||
- I/O管理: ソケット・ファイルハンドルの確実解放
|
||||
- 同時接続・早期切断・例外経路でのfini伝播テスト
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- 実用的なメモリ管理パターンの実装
|
||||
- weak参照構文の適切な使用
|
||||
- デバッグ支援機能（--debug-memory, --trace-weak）
|
||||
- WASM環境でのメモリ管理互換性
|
||||
|
||||
### 成功基準
|
||||
- [ ] 全テストケースでメモリリークなし
|
||||
- [ ] 循環参照でも正常解放確認
|
||||
- [ ] WASM実行でもメモリ管理正常
|
||||
- [ ] ベンチマーク性能劣化なし
|
||||
|
||||
### 期待される効果
|
||||
- Nyashメモリ管理システムの実用性実証
|
||||
- Everything is Box哲学の実用レベル確認
|
||||
- メモリ安全なプログラミングパターン確立
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🚀 Phase 9: AOT WASM実装（最優先）
|
||||
|
||||
Summary:
|
||||
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
|
||||
|
||||
Scope/Tasks:
|
||||
- `wasmtime compile` 統合実装
|
||||
- `--compile-native` / `--aot` CLI追加
|
||||
- 単一バイナリ梱包（`include_bytes!`）
|
||||
- 起動時間・配布サイズ最適化
|
||||
|
||||
Acceptance Criteria:
|
||||
- `nyash --compile-native app.nyash -o app.exe` 動作
|
||||
- 起動時間大幅短縮（JIT起動コスト除去）
|
||||
- 配布可能実行ファイル生成
|
||||
|
||||
Priority: **Critical** (Phase 8.6完了直後)
|
||||
Expected Duration: 2-3週間
|
||||
|
||||
### 技術的実装詳細
|
||||
🤖 Copilot協力期待:
|
||||
- wasmtime::Config統一実装
|
||||
- .cwasm生成・実行パイプライン
|
||||
- 互換性キー管理（CPU機能・wasmtimeバージョン）
|
||||
- パッケージング（単一バイナリ梱包）
|
||||
|
||||
### パフォーマンス目標
|
||||
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
|
||||
- 配布ファイルサイズ: <10MB目標
|
||||
- 起動時間: <100ms目標
|
||||
|
||||
### 期待される効果
|
||||
- **即座実用価値**: 配布可能実行ファイル生成
|
||||
- **差別化優位**: Everything is BoxのネイティブAOT実現
|
||||
- **LLVM準備**: AOT基盤確立でLLVM移行準備
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔴 Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 **【緊急修正】**
|
||||
|
||||
Status: 🔴 **Critical Issue**（Phase 9実用化ブロッカー）
|
||||
Summary:
|
||||
- Phase 9 (PR #67) 完了後に判明した重大制約の修正
|
||||
- WASM/AOT実用化の最終仕上げ
|
||||
|
||||
### 🚨 現在の問題（実用化を阻害）
|
||||
|
||||
1. **WASM/AOT コンパイルエラー（最重要）**
|
||||
```bash
|
||||
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
|
||||
❌ Unsupported instruction: Jump { target: BasicBlockId(1) }
|
||||
```
|
||||
**影響**: ループ・条件分岐を含む全プログラムがWASM/AOT化不可
|
||||
|
||||
2. **HTTPServerBox listen()常に失敗**
|
||||
- server.bind() ✅, server.listen() ❌ always false
|
||||
**影響**: HTTPサーバーが実際には動作しない
|
||||
|
||||
3. **エラーハンドリング脆弱性**
|
||||
- unwrap()使用箇所: 26箇所 → パニック多発リスク
|
||||
|
||||
### Scope/Tasks:
|
||||
**🔴 Task 1**: WASM Jump/Branch命令実装（2日）
|
||||
- `src/backend/wasm/codegen.rs`にJump/Branch追加
|
||||
- ブロック深度管理（`get_block_depth`メソッド）
|
||||
- ループ構造のblock/loop/end生成
|
||||
|
||||
**🔴 Task 2**: SocketBox listen()修正（1日）
|
||||
- `src/boxes/socket_box.rs`の実装修正
|
||||
- SocketStatus::Listening状態管理
|
||||
|
||||
**🟡 Task 3**: エラーハンドリング改善（2日）
|
||||
- HTTPServerBox/SocketBoxのunwrap()除去
|
||||
- Result<T,E>ベースのエラー処理
|
||||
|
||||
**🟡 Task 4**: HTTPサーバー実用化（2日）
|
||||
- スレッドプール実装（固定サイズワーカー）
|
||||
- グレースフルシャットダウン
|
||||
|
||||
Acceptance Criteria:
|
||||
- ✅ `nyash --compile-wasm test_loop.nyash` 成功
|
||||
- ✅ HTTPサーバー実動作（curl http://localhost:8080/）
|
||||
- ✅ unwrap()使用箇所: 26 → 5以下
|
||||
- ✅ WASM性能: 11.5倍 → 13.5倍達成
|
||||
|
||||
Priority: **🔴 Critical** (Phase 9.5開始前の必須修正)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 詳細設計・実装指示
|
||||
📋 **完全実装ガイド**: `docs/予定/native-plan/issues/phase9_51_wasm_jump_http_fixes.md`
|
||||
|
||||
🤖 **Copilot協力依頼**:
|
||||
- WASM br/br_if命令実装
|
||||
- HTTPサーバーリファクタリング
|
||||
- エラーハンドリング統一
|
||||
|
||||
### 期待される効果
|
||||
- **実用性達成**: ループ・HTTPサーバーのWASM/AOT化
|
||||
- **安定性向上**: パニックフリーな実装
|
||||
- **Phase 9.5準備**: 複雑アプリケーションテストの基盤確立
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
================================================================================
|
||||
最終更新: 2025-08-15 (Phase 9.5より前をアーカイブ分割)
|
||||
作成者: Claude (ドキュメント分割・整理)
|
||||
|
||||
🎯 分割理由:
|
||||
- copilot_issues.txtの肥大化対策（1200行→600行程度に削減）
|
||||
- Phase 9.5以降の現行計画と完了済み部分の明確分離
|
||||
- ドキュメント検索性・保守性の向上
|
||||
================================================================================
|
||||
@ -0,0 +1,156 @@
|
||||
# 🤖 AI大会議結果: LLVM PoC実装戦略統合文書
|
||||
|
||||
**作成日**: 2025年8月20日
|
||||
**参加AI**: Gemini先生、Codex先生、Claude
|
||||
**目的**: Phase 9.78 LLVM PoC実装の統合戦略策定
|
||||
|
||||
## 📋 **エグゼクティブサマリー**
|
||||
|
||||
AI大会議の結果、以下の統合戦略が決定されました：
|
||||
|
||||
1. **技術基盤**: `inkwell`クレート + 既存ランタイム活用のハイブリッド戦略
|
||||
2. **Box型表現**: LLVM `ptr`型 + ランタイム関数によるメモリ管理
|
||||
3. **実装期間**: 3週間で基本動作確認（Hello World〜算術演算）
|
||||
4. **性能目標**: 計算集約処理で数十倍の高速化実証
|
||||
|
||||
## 🎯 **統合実装戦略**
|
||||
|
||||
### **Week 1: 基盤構築とHello World**
|
||||
|
||||
**Gemini先生推奨アプローチ**:
|
||||
```rust
|
||||
// inkwellクレートで型安全なLLVM操作
|
||||
use inkwell::context::Context;
|
||||
use inkwell::module::Module;
|
||||
use inkwell::builder::Builder;
|
||||
|
||||
struct CodegenContext<'ctx> {
|
||||
context: &'ctx Context,
|
||||
module: Module<'ctx>,
|
||||
builder: Builder<'ctx>,
|
||||
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
|
||||
}
|
||||
```
|
||||
|
||||
**Codex先生の具体的タスク**:
|
||||
- ✅ `inkwell`セットアップ
|
||||
- ✅ MIR `Const`, `Return`命令の変換
|
||||
- ✅ ランタイム関数宣言 (`nyash_alloc`, `nyash_free`)
|
||||
- ✅ `.o`ファイル生成とCランタイムリンク
|
||||
|
||||
**統合成果物**: `return 42`が動作するLLVM実装
|
||||
|
||||
### **Week 2: 制御フローとBox MVP**
|
||||
|
||||
**Gemini先生のBox型戦略**:
|
||||
```rust
|
||||
// Box型 = LLVM ptr型として表現
|
||||
fn box_to_llvm_type<'ctx>(ctx: &CodegenContext<'ctx>) -> PointerType<'ctx> {
|
||||
ctx.context.i8_type().ptr_type(AddressSpace::Generic)
|
||||
}
|
||||
|
||||
// ランタイム関数経由でBox操作
|
||||
extern "C" {
|
||||
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
|
||||
fn nyash_runtime_box_free(ptr: *mut c_void, size: u64, align: u64);
|
||||
}
|
||||
```
|
||||
|
||||
**Codex先生の実装順序**:
|
||||
1. SSA/PHI命令の実装
|
||||
2. `Branch`, `Jump`による制御フロー
|
||||
3. Box基本操作（new/free/deref）
|
||||
4. `LLVMVerifyModule`による検証
|
||||
|
||||
**統合成果物**: 条件分岐とBox操作を含むプログラムの動作
|
||||
|
||||
### **Week 3: 統合とベンチマーク**
|
||||
|
||||
**性能検証（Gemini先生）**:
|
||||
- 計算集約的ベンチマーク実装
|
||||
- インタープリター/VM/LLVMの性能比較
|
||||
- 期待値: 数十倍の高速化実証
|
||||
|
||||
**堅牢性確保（Codex先生）**:
|
||||
- 差分テスト（Interpreter vs LLVM）
|
||||
- 最小最適化パス（`mem2reg`, `instcombine`）
|
||||
- クラッシュ時の`.ll`ファイル保存
|
||||
|
||||
## 🔧 **技術的詳細**
|
||||
|
||||
### **MIR→LLVM命令マッピング**
|
||||
|
||||
| MIR命令 | LLVM IR | 実装方法 |
|
||||
|---------|---------|----------|
|
||||
| Const | ConstantInt/Float | inkwell定数生成 |
|
||||
| BinOp(Add) | add/fadd | builder.build_add() |
|
||||
| Compare | icmp/fcmp | builder.build_int_compare() |
|
||||
| BoxCall | call @nyash_runtime_box_call | ランタイム委譲 |
|
||||
| Branch | br | builder.build_conditional_branch() |
|
||||
| Return | ret | builder.build_return() |
|
||||
|
||||
### **エラー頻発箇所と対策**
|
||||
|
||||
**Gemini先生の警告**:
|
||||
- ❌ `Arc<Mutex>`をLLVMで再実装しない
|
||||
- ✅ 既存ランタイムの`#[no_mangle] extern "C"`関数を呼ぶ
|
||||
|
||||
**Codex先生の実装Tips**:
|
||||
- `alloca`は関数エントリーブロックのみ
|
||||
- GEPインデックスは`i32`型で統一
|
||||
- DataLayoutは必ずTargetMachineから取得
|
||||
|
||||
### **プラグイン統合（BID-FFI）**
|
||||
|
||||
**Gemini先生**: C-ABIは既にLLVMと相性が良い
|
||||
```llvm
|
||||
declare i32 @nyash_plugin_invoke(i8*, i64, i8*, i64*)
|
||||
```
|
||||
|
||||
**Codex先生**: リンク時に`.so`/`.a`を含める
|
||||
```bash
|
||||
cc -o output main.o nyash_runtime.o -lplugin
|
||||
```
|
||||
|
||||
## 📊 **成功判定基準（統合版）**
|
||||
|
||||
### **最小成功ライン（PoC達成）**
|
||||
- ✅ 基本算術演算のLLVM実行
|
||||
- ✅ Box型の基本操作動作
|
||||
- ✅ Hello Worldレベルの出力
|
||||
- ✅ 10倍以上の性能向上実証
|
||||
|
||||
### **理想的成功（Phase 10への道筋）**
|
||||
- 🌟 20個以上のMIR命令対応
|
||||
- 🌟 プラグイン呼び出し成功
|
||||
- 🌟 50倍以上の性能向上
|
||||
- 🌟 安定したエラーハンドリング
|
||||
|
||||
## 🚀 **Copilotへの最終依頼文書**
|
||||
|
||||
```markdown
|
||||
## Phase 9.78: LLVM PoC実装依頼
|
||||
|
||||
**目標**: 3週間でNyash MIR→LLVM変換の基本実装
|
||||
|
||||
**技術スタック**:
|
||||
- inkwellクレート（Gemini推奨）
|
||||
- 既存ランタイム活用（Arc<Mutex>回避）
|
||||
- C-ABIプラグイン統合
|
||||
|
||||
**実装優先順位**:
|
||||
1. Week 1: Const/Return/基本setup → "return 42"
|
||||
2. Week 2: 制御フロー/Box MVP → 条件分岐
|
||||
3. Week 3: 最適化/ベンチマーク → 性能実証
|
||||
|
||||
**成果物**:
|
||||
- src/backend/llvm/compiler.rs
|
||||
- ベンチマーク結果（10倍以上高速化）
|
||||
- Phase 10実装計画
|
||||
```
|
||||
|
||||
## 🎉 **結論**
|
||||
|
||||
AI大会議により、技術的に実現可能で、3週間で達成可能な明確な実装戦略が確立されました。inkwellによる型安全な実装と、既存ランタイム活用により、リスクを最小化しながら高速なLLVMバックエンドの実現が期待できます。
|
||||
|
||||
**次のアクション**: Copilotへの正式依頼とPhase 9.78開始！🚀
|
||||
122
docs/development/roadmap/native-plan/llvm/APE-Magic-Explained.md
Normal file
122
docs/development/roadmap/native-plan/llvm/APE-Magic-Explained.md
Normal file
@ -0,0 +1,122 @@
|
||||
# 🪄 APE (Actually Portable Executable) の魔法を解説！
|
||||
|
||||
**「えっ、1つのファイルが3つのOSで動くの！？」**
|
||||
|
||||
はい、本当です！これは**実在する技術**です！
|
||||
|
||||
## 🎩 **APEの魔法の仕組み**
|
||||
|
||||
### **実例を見てみよう**
|
||||
```bash
|
||||
# これが実際のAPEバイナリ
|
||||
$ ls -la hello.com
|
||||
-rwxr-xr-x 1 user user 65536 Aug 20 hello.com
|
||||
|
||||
# Linuxで実行
|
||||
$ ./hello.com
|
||||
Hello from Linux!
|
||||
|
||||
# 同じファイルをWindowsにコピー
|
||||
> hello.com
|
||||
Hello from Windows!
|
||||
|
||||
# 同じファイルをmacOSで実行
|
||||
$ ./hello.com
|
||||
Hello from macOS!
|
||||
```
|
||||
|
||||
**たった1つのファイル `hello.com` が全部で動く！**
|
||||
|
||||
## 🔮 **どうやって実現してるの？**
|
||||
|
||||
### **秘密：ファイルヘッダーの魔法**
|
||||
|
||||
APEファイルの先頭部分：
|
||||
```
|
||||
00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000 MZ.............. # Windows PE
|
||||
00000010: b800 0000 0000 0000 4000 0000 0000 0000 ........@.......
|
||||
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
|
||||
00000030: 0000 0000 0000 0000 0000 0080 0000 0000 ................
|
||||
00000040: 7f45 4c46 0201 0100 0000 0000 0000 0000 .ELF............ # Linux ELF
|
||||
```
|
||||
|
||||
**同じファイルに複数のOSのヘッダーが共存！**
|
||||
|
||||
### **OSごとの読み方**
|
||||
|
||||
1. **Windows**: 「MZ」で始まる → PEファイルとして実行
|
||||
2. **Linux**: ELFマジックナンバーを探す → ELFとして実行
|
||||
3. **macOS**: Mach-Oヘッダーを探す → Mach-Oとして実行
|
||||
|
||||
## 🛠️ **Cosmopolitan Libc - 実在するプロジェクト**
|
||||
|
||||
**GitHubで公開されています！**
|
||||
- https://github.com/jart/cosmopolitan
|
||||
- 開発者: Justine Tunney (元Google)
|
||||
- スター数: 17,000+ ⭐
|
||||
|
||||
### **実際のビルド方法**
|
||||
```bash
|
||||
# Cosmopolitanを使ったビルド
|
||||
gcc -g -O -static \
|
||||
-fno-pie -no-pie \
|
||||
-nostdlib -nostdinc \
|
||||
-o hello.com \
|
||||
hello.c \
|
||||
cosmopolitan.a \
|
||||
-Wl,--gc-sections \
|
||||
-Wl,-T,ape.lds
|
||||
```
|
||||
|
||||
## 📊 **APEの利点と制限**
|
||||
|
||||
### **利点** ✅
|
||||
- **配布が超簡単**: 1ファイルで全OS対応
|
||||
- **依存関係なし**: 完全に自己完結
|
||||
- **小さいサイズ**: 静的リンクでも小さい
|
||||
|
||||
### **制限** ⚠️
|
||||
- **x86_64のみ**: ARM版はまだ実験的
|
||||
- **GUI制限**: 基本的にCLIアプリ向け
|
||||
- **OS固有機能**: 一部制限あり
|
||||
|
||||
## 🎯 **NyashでのAPE活用案**
|
||||
|
||||
### **段階的アプローチ**
|
||||
|
||||
**Phase 1: 通常のマルチターゲット**（現実的）
|
||||
```bash
|
||||
nyashc --targets linux,windows,macos
|
||||
# → 3つの別々のファイル生成
|
||||
```
|
||||
|
||||
**Phase 2: APE実験**（6ヶ月後）
|
||||
```bash
|
||||
nyashc --target ape
|
||||
# → nyash.com (全OS対応の1ファイル！)
|
||||
```
|
||||
|
||||
### **実装イメージ**
|
||||
```rust
|
||||
// NyashのLLVM IR → Cコード生成
|
||||
let c_code = transpile_to_c(&llvm_ir);
|
||||
|
||||
// Cosmopolitanでコンパイル
|
||||
compile_with_cosmopolitan(&c_code, "nyash.com");
|
||||
```
|
||||
|
||||
## 🤔 **本当に必要？**
|
||||
|
||||
**正直な評価**：
|
||||
- **配布簡単さ**: ⭐⭐⭐⭐⭐ 最高！
|
||||
- **実装難易度**: ⭐⭐ 意外と簡単（Cosmopolitan使えば）
|
||||
- **実用性**: ⭐⭐⭐ CLIツールなら十分実用的
|
||||
- **かっこよさ**: ⭐⭐⭐⭐⭐ 最高にクール！
|
||||
|
||||
## 💡 **結論**
|
||||
|
||||
APEは**「欲張り」じゃなくて「賢い」**アプローチ！
|
||||
|
||||
でも、まずは普通のマルチターゲット対応から始めて、APEは「究極の目標」として楽しみに取っておくのが現実的かも？
|
||||
|
||||
**にゃーも「Everything is Box」なら、APEは「Everything is ONE Binary」！**🎩✨
|
||||
@ -0,0 +1,117 @@
|
||||
# 🤖 Copilot様への依頼: Phase 9.78 LLVM PoC実装
|
||||
|
||||
**依頼日**: 2025年8月20日
|
||||
**期限**: 3週間（2025年9月10日）
|
||||
**優先度**: 最高
|
||||
|
||||
## 📋 **依頼概要**
|
||||
|
||||
Phase 8.6のVM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
|
||||
|
||||
次は、Nyash言語の更なる性能向上を目指し、**LLVMバックエンドのProof of Concept実装**をお願いします。
|
||||
|
||||
## 🎯 **依頼内容**
|
||||
|
||||
### **目標**
|
||||
3週間でMIR→LLVM IR変換の基本実装を完成させ、実現可能性を実証する
|
||||
|
||||
### **成功基準**
|
||||
1. 基本的なNyashプログラム（算術演算、条件分岐）がLLVM経由で実行可能
|
||||
2. インタープリター比10倍以上の性能向上を実証
|
||||
3. Phase 10本格実装への明確な道筋を確立
|
||||
|
||||
## 🛠️ **技術仕様**
|
||||
|
||||
### **使用技術スタック**
|
||||
```toml
|
||||
[dependencies]
|
||||
inkwell = { version = "0.5", features = ["llvm17-0"] }
|
||||
```
|
||||
|
||||
### **実装アプローチ**
|
||||
AI大会議（Gemini先生、Codex先生）の推奨に基づく：
|
||||
- **inkwellクレート**による型安全なLLVM操作
|
||||
- **Box型はptr型**として表現、操作は既存ランタイムに委譲
|
||||
- **C-ABI経由**でプラグインとランタイム関数を呼び出し
|
||||
|
||||
### **実装対象MIR命令（優先順）**
|
||||
1. **Week 1**: Const, Return（最小限）
|
||||
2. **Week 2**: BinOp, Compare, Branch, Jump, BoxNew/Free
|
||||
3. **Week 3**: 最適化パス、ベンチマーク
|
||||
|
||||
## 📁 **作成ファイル構成**
|
||||
|
||||
```
|
||||
src/backend/llvm/
|
||||
├── mod.rs // エントリポイント
|
||||
├── context.rs // LLVMコンテキスト管理
|
||||
├── types.rs // MIR→LLVM型変換
|
||||
├── builder.rs // IR生成ロジック
|
||||
├── runtime.rs // ランタイム関数宣言
|
||||
└── optimizer.rs // 最適化パス
|
||||
|
||||
src/backend/llvm_runtime/
|
||||
└── runtime.c // 最小ランタイム（nyash_alloc等）
|
||||
```
|
||||
|
||||
## 📊 **週次マイルストーン**
|
||||
|
||||
### **Week 1: Hello World動作**
|
||||
- [ ] inkwellセットアップ完了
|
||||
- [ ] `return 42`がLLVM経由で動作
|
||||
- [ ] .oファイル生成成功
|
||||
|
||||
### **Week 2: 基本機能動作**
|
||||
- [ ] 四則演算の実装
|
||||
- [ ] if文の動作確認
|
||||
- [ ] Box型の基本操作
|
||||
|
||||
### **Week 3: 性能実証**
|
||||
- [ ] ベンチマーク実装
|
||||
- [ ] 10倍以上の高速化確認
|
||||
- [ ] 技術レポート作成
|
||||
|
||||
## 💡 **実装のヒント**
|
||||
|
||||
### **Gemini先生のアドバイス**
|
||||
- `Arc<Mutex>`の複雑なセマンティクスをLLVMで再実装しないこと
|
||||
- Box操作は`nyash_runtime_box_*`関数経由で行う
|
||||
- 計算集約的な処理に注力すれば数十倍の高速化が可能
|
||||
|
||||
### **Codex先生の実装Tips**
|
||||
- allocaは関数エントリブロックのみに配置
|
||||
- GEPインデックスはi32型で統一
|
||||
- エラー時は.llファイルをダンプして原因調査
|
||||
|
||||
## 🚨 **重要な注意事項**
|
||||
|
||||
1. **完璧を求めない** - 3週間でのPoC完成が最優先
|
||||
2. **既存資産の活用** - MIR構造、ランタイム関数を最大限再利用
|
||||
3. **段階的実装** - 最小限から始めて徐々に機能追加
|
||||
|
||||
## 📚 **参考資料**
|
||||
|
||||
- [AI大会議結果](./AI-Conference-LLVM-Results.md) - 技術戦略の詳細
|
||||
- [実装計画書](./Phase-9.78-Implementation-Plan.md) - 週次スケジュール
|
||||
- [MIR仕様](../../説明書/reference/execution-backend/mir-26-specification.md) - 命令セット詳細
|
||||
|
||||
## 🎉 **期待される成果**
|
||||
|
||||
1. **技術的実証**: LLVMバックエンドの実現可能性確認
|
||||
2. **性能向上**: 10倍以上（理想的には50倍）の高速化
|
||||
3. **将来への道筋**: Phase 10での本格実装計画
|
||||
|
||||
## 🤝 **サポート体制**
|
||||
|
||||
- **技術相談**: Claude、Gemini、Codexが随時サポート
|
||||
- **進捗確認**: 週次でGitHub Issueにて状況共有
|
||||
- **問題解決**: ブロッカーがあれば即座にAIチームで対応
|
||||
|
||||
Copilot様の素晴らしい実装力に期待しています！
|
||||
Phase 8.6のような劇的な成果を、LLVMでも実現しましょう！🚀
|
||||
|
||||
---
|
||||
|
||||
**依頼者**: moe-charm + AIチーム
|
||||
**GitHub Issue**: #（作成予定）
|
||||
**開始可能日**: 即時
|
||||
@ -0,0 +1,151 @@
|
||||
# 🌈 理想的なハイブリッド実行環境への願望
|
||||
|
||||
**「AOT WASMが非同期対応してたら...」**
|
||||
|
||||
## 😿 **現在の苦労ポイント**
|
||||
|
||||
### **各バックエンドの制限**
|
||||
| バックエンド | 利点 | 欠点 |
|
||||
|------------|------|------|
|
||||
| **WASM** | どこでも動く | 非同期が弱い、遅い |
|
||||
| **LLVM** | 超高速 | OS別ビルド必要 |
|
||||
| **VM** | 柔軟 | ネイティブより遅い |
|
||||
| **AOT** | 高速起動 | プラットフォーム依存 |
|
||||
|
||||
### **理想と現実のギャップ**
|
||||
```rust
|
||||
// 理想
|
||||
async fn perfect_world() {
|
||||
let result = await some_io(); // WASMでも高速非同期
|
||||
return result;
|
||||
}
|
||||
|
||||
// 現実
|
||||
fn reality() {
|
||||
// WASMは同期的、非同期は複雑
|
||||
// LLVMは速いけどOS別ビルド
|
||||
// 完璧な解決策がない...
|
||||
}
|
||||
```
|
||||
|
||||
## 🚀 **夢のハイブリッド環境**
|
||||
|
||||
### **1. WASM Component Model + AOT**
|
||||
```yaml
|
||||
理想:
|
||||
- WASMの可搬性
|
||||
- AOTの実行速度
|
||||
- ネイティブ非同期サポート
|
||||
- 単一バイナリで全OS対応
|
||||
|
||||
現実:
|
||||
- Component Model仕様策定中
|
||||
- AOT最適化はまだ発展途上
|
||||
- 非同期は部分的サポート
|
||||
```
|
||||
|
||||
### **2. Deno/Bun的アプローチ**
|
||||
```javascript
|
||||
// JavaScriptランタイムの良いとこ取り
|
||||
- V8/JavaScriptCore の JIT性能
|
||||
- ネイティブバインディング
|
||||
- 非同期完全サポート
|
||||
- でもJavaScript...
|
||||
```
|
||||
|
||||
### **3. 究極の理想：Universal Runtime**
|
||||
```rust
|
||||
// もしこんなランタイムがあったら...
|
||||
universal_runtime {
|
||||
// WASMレベルの可搬性
|
||||
portability: "write once, run anywhere",
|
||||
|
||||
// LLVMレベルの性能
|
||||
performance: "near native",
|
||||
|
||||
// 完全な非同期サポート
|
||||
async: "first class",
|
||||
|
||||
// 単一配布物
|
||||
distribution: "single file"
|
||||
}
|
||||
```
|
||||
|
||||
## 💭 **現実的な妥協案**
|
||||
|
||||
### **短期的ハイブリッド戦略**
|
||||
```yaml
|
||||
開発時:
|
||||
- インタープリター（即時実行、デバッグ容易）
|
||||
|
||||
テスト時:
|
||||
- VM（高速、クロスプラットフォーム）
|
||||
|
||||
配布時:
|
||||
選択式:
|
||||
- WASM版: ブラウザ/サーバー両対応
|
||||
- ネイティブ版: 最高性能
|
||||
- ハイブリッド版: WASMランタイム埋め込み
|
||||
```
|
||||
|
||||
### **中期的技術統合**
|
||||
```rust
|
||||
// Nyashハイブリッドランタイム
|
||||
pub enum ExecutionMode {
|
||||
// 高速パス: ネイティブコード
|
||||
Native(LLVMCompiledCode),
|
||||
|
||||
// 互換パス: WASM
|
||||
Wasm(WasmModule),
|
||||
|
||||
// 動的切り替え
|
||||
Adaptive {
|
||||
hot_path: LLVMCompiledCode,
|
||||
cold_path: WasmModule,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🔮 **将来への期待**
|
||||
|
||||
### **技術の収束点**
|
||||
1. **WASI Preview 2**: 非同期サポート改善中
|
||||
2. **WASM GC**: メモリ管理効率化
|
||||
3. **Component Model**: 真のモジュラー化
|
||||
4. **AOT最適化**: Wasmtime/WazeroCranelift進化
|
||||
|
||||
### **Nyashの位置づけ**
|
||||
```yaml
|
||||
現在:
|
||||
- 4バックエンド個別対応
|
||||
- それぞれの長所を活かす
|
||||
|
||||
将来:
|
||||
- 統合ランタイム
|
||||
- 動的最適化
|
||||
- 透過的実行モード切り替え
|
||||
```
|
||||
|
||||
## 😊 **でも今でも十分すごい！**
|
||||
|
||||
**現在のNyash**:
|
||||
- ✅ 4つの実行方式を選べる
|
||||
- ✅ 用途に応じて最適化可能
|
||||
- ✅ プラグインシステム完備
|
||||
|
||||
**苦労はあるけど**:
|
||||
- 複数バックエンドの保守
|
||||
- プラットフォーム別の調整
|
||||
- でも**選択肢があることが強み**！
|
||||
|
||||
## 🎯 **結論**
|
||||
|
||||
理想的なハイブリッド環境はまだ存在しないけど、Nyashは**現実的な最良の解**を提供中！
|
||||
|
||||
将来、技術が成熟したら：
|
||||
- WASM AOT + 非同期 = 最強の可搬性
|
||||
- LLVM + WASM統合 = 性能と互換性の両立
|
||||
|
||||
それまでは、**4バックエンドを賢く使い分ける**のが正解！
|
||||
|
||||
**Everything is Box、Every Backend has its Place！**🌈✨
|
||||
149
docs/development/roadmap/native-plan/llvm/JIT-vs-AOT-With-MIR.md
Normal file
149
docs/development/roadmap/native-plan/llvm/JIT-vs-AOT-With-MIR.md
Normal file
@ -0,0 +1,149 @@
|
||||
# 🤔 JIT vs AOT：MIRがあると難易度が同じ？
|
||||
|
||||
**「MIRできてるから、JITもAOTも同じようなレベルに見えてきた」**
|
||||
|
||||
## 💡 **その洞察、正しいです！**
|
||||
|
||||
### **MIRの存在が変えるゲーム**
|
||||
|
||||
```rust
|
||||
// 従来の難易度
|
||||
Source → Native: 超難しい（全部自分で）
|
||||
Source → JIT: 難しい（実行時コンパイル）
|
||||
|
||||
// MIRがある今
|
||||
Source → MIR → Native: MIRから先は楽！
|
||||
Source → MIR → JIT: MIRから先は楽！
|
||||
```
|
||||
|
||||
## 📊 **JIT vs AOT 比較（MIR前提）**
|
||||
|
||||
| 項目 | JIT | AOT (LLVM) |
|
||||
|------|-----|------------|
|
||||
| **実装難易度** | ⭐⭐⭐ | ⭐⭐⭐ |
|
||||
| **初期実装速度** | 速い | 速い |
|
||||
| **実行時性能** | 80-95% | 100% |
|
||||
| **起動時間** | 遅い | 速い |
|
||||
| **メモリ使用** | 多い | 少ない |
|
||||
| **動的最適化** | ✅ | ❌ |
|
||||
| **配布** | ランタイム必要 | 単体実行可能 |
|
||||
|
||||
**MIRのおかげで、どちらも同じくらいの実装難易度に！**
|
||||
|
||||
## 🚀 **JIT実装の選択肢**
|
||||
|
||||
### **1. VM JIT化（最も現実的）**
|
||||
```rust
|
||||
// 現在のVM
|
||||
match opcode {
|
||||
Add => stack.push(a + b),
|
||||
}
|
||||
|
||||
// JIT化したVM
|
||||
if hot_path {
|
||||
// CraneliftでMIR→ネイティブ
|
||||
let native = cranelift_compile(&mir);
|
||||
execute_native(native);
|
||||
}
|
||||
```
|
||||
|
||||
**利点**：
|
||||
- 既存VMの延長線上
|
||||
- 段階的移行可能
|
||||
- ホットパスのみJIT化
|
||||
|
||||
### **2. 純粋JITコンパイラ**
|
||||
```rust
|
||||
// MIR → Cranelift IR → Native
|
||||
pub fn jit_compile(mir: &MirModule) -> NativeCode {
|
||||
let mut ctx = CraneliftContext::new();
|
||||
for func in &mir.functions {
|
||||
ctx.compile_function(func);
|
||||
}
|
||||
ctx.finalize()
|
||||
}
|
||||
```
|
||||
|
||||
**利点**：
|
||||
- クリーンな設計
|
||||
- 最適化しやすい
|
||||
- デバッグ情報維持
|
||||
|
||||
### **3. LLVM JIT（ORC）**
|
||||
```rust
|
||||
// LLVM ORCでJIT
|
||||
let jit = LLVMOrcJIT::new();
|
||||
jit.add_module(llvm_module);
|
||||
let func = jit.get_function("main");
|
||||
func.call();
|
||||
```
|
||||
|
||||
**利点**：
|
||||
- LLVM最適化の恩恵
|
||||
- AOTとコード共有
|
||||
- 最高性能
|
||||
|
||||
## 🔮 **実装難易度の実際**
|
||||
|
||||
### **AOT (LLVM)**
|
||||
```yaml
|
||||
必要な作業:
|
||||
1. MIR → LLVM IR変換: 2週間
|
||||
2. 型システムマッピング: 1週間
|
||||
3. ランタイム統合: 1週間
|
||||
4. 最適化調整: 1週間
|
||||
合計: 約5週間
|
||||
```
|
||||
|
||||
### **JIT (Cranelift)**
|
||||
```yaml
|
||||
必要な作業:
|
||||
1. MIR → Cranelift IR変換: 2週間
|
||||
2. JITランタイム実装: 1週間
|
||||
3. ホットパス検出: 1週間
|
||||
4. メモリ管理: 1週間
|
||||
合計: 約5週間
|
||||
```
|
||||
|
||||
**ほぼ同じ！MIRのおかげで！**
|
||||
|
||||
## 💭 **どっちを選ぶべき？**
|
||||
|
||||
### **JITが向いている場合**
|
||||
- 長時間実行プログラム
|
||||
- 動的な最適化が必要
|
||||
- REPLやインタラクティブ環境
|
||||
|
||||
### **AOTが向いている場合**
|
||||
- 起動時間重視
|
||||
- 配布の簡単さ重視
|
||||
- 組み込み環境
|
||||
|
||||
### **Nyashの場合**
|
||||
```yaml
|
||||
現実的な選択:
|
||||
1. まずAOT (LLVM) でPoC
|
||||
2. VM最適化を極める
|
||||
3. 将来VM JIT化も追加
|
||||
|
||||
理由:
|
||||
- 配布が簡単（AOT）
|
||||
- 性能も確保（VM既に50倍）
|
||||
- 両方あれば最強
|
||||
```
|
||||
|
||||
## 🎯 **結論**
|
||||
|
||||
**MIRがあるおかげで、JITもAOTも同じくらいの難易度！**
|
||||
|
||||
でも、Nyashの場合：
|
||||
1. **配布の簡単さ** → AOT有利
|
||||
2. **既にVM高速** → JIT緊急度低い
|
||||
3. **将来の拡張性** → 両方実装が理想
|
||||
|
||||
**提案**：
|
||||
- **短期**: LLVM AOT完成（配布重視）
|
||||
- **中期**: VM更なる最適化
|
||||
- **長期**: VM JIT化（最高性能）
|
||||
|
||||
**MIRがあれば、どっちも楽！**🚀
|
||||
@ -0,0 +1,187 @@
|
||||
# 📋 Phase 9.78: LLVM PoC 実装計画書
|
||||
|
||||
**バージョン**: 1.0
|
||||
**作成日**: 2025年8月20日
|
||||
**ステータス**: 準備完了
|
||||
|
||||
## 🎯 **プロジェクト概要**
|
||||
|
||||
### **目的**
|
||||
3週間でNyash言語のLLVMバックエンド実現可能性を実証する
|
||||
|
||||
### **成功基準**
|
||||
- 基本的なNyashプログラムがLLVM経由で実行可能
|
||||
- インタープリター比10倍以上の性能向上
|
||||
- Phase 10本格実装への技術的道筋確立
|
||||
|
||||
## 📅 **3週間実装スケジュール**
|
||||
|
||||
### **Week 1: 基盤構築（8/21-8/27）**
|
||||
|
||||
#### **Day 1-2: 環境セットアップ**
|
||||
```toml
|
||||
# Cargo.toml
|
||||
[dependencies]
|
||||
inkwell = { version = "0.5", features = ["llvm17-0"] }
|
||||
```
|
||||
|
||||
- [ ] inkwellクレート導入
|
||||
- [ ] LLVMコンテキスト初期化
|
||||
- [ ] 基本的なモジュール生成
|
||||
|
||||
#### **Day 3-4: 最小命令実装**
|
||||
```rust
|
||||
// 実装対象
|
||||
- Const(Integer/Float/Bool)
|
||||
- Return
|
||||
- 基本的な型マッピング
|
||||
```
|
||||
|
||||
#### **Day 5-7: Hello World達成**
|
||||
- [ ] ランタイム関数宣言
|
||||
- [ ] .oファイル生成
|
||||
- [ ] `return 42`の実行確認
|
||||
|
||||
**Week 1成果物**: 整数を返す最小プログラムのLLVM実行
|
||||
|
||||
### **Week 2: コア機能実装（8/28-9/3）**
|
||||
|
||||
#### **Day 8-10: 算術演算と制御フロー**
|
||||
```rust
|
||||
// 実装対象
|
||||
- BinOp (Add/Sub/Mul/Div)
|
||||
- Compare (Eq/Ne/Lt/Le/Gt/Ge)
|
||||
- Branch/Jump
|
||||
- PHI nodes
|
||||
```
|
||||
|
||||
#### **Day 11-13: Box型MVP**
|
||||
```rust
|
||||
// Box操作の実装
|
||||
extern "C" {
|
||||
fn nyash_runtime_box_new(size: u64, align: u64) -> *mut c_void;
|
||||
fn nyash_runtime_box_free(ptr: *mut c_void);
|
||||
fn nyash_runtime_box_deref(ptr: *mut c_void) -> *mut c_void;
|
||||
}
|
||||
```
|
||||
|
||||
#### **Day 14: 統合テスト**
|
||||
- [ ] 条件分岐を含むプログラム
|
||||
- [ ] Box操作を含むプログラム
|
||||
- [ ] LLVMVerifyModuleによる検証
|
||||
|
||||
**Week 2成果物**: 制御フローとメモリ操作を含むプログラムの動作
|
||||
|
||||
### **Week 3: 最適化と検証（9/4-9/10）**
|
||||
|
||||
#### **Day 15-16: 最適化パス**
|
||||
```rust
|
||||
// 基本最適化
|
||||
- mem2reg (alloca → SSA)
|
||||
- instcombine (命令結合)
|
||||
- reassociate (結合則)
|
||||
```
|
||||
|
||||
#### **Day 17-18: ベンチマーク**
|
||||
```bash
|
||||
# 性能測定対象
|
||||
- フィボナッチ数列
|
||||
- 素数判定
|
||||
- 簡単な数値計算ループ
|
||||
```
|
||||
|
||||
#### **Day 19-21: 文書化とレポート**
|
||||
- [ ] 技術レポート作成
|
||||
- [ ] Phase 10実装計画
|
||||
- [ ] 性能評価結果
|
||||
|
||||
**Week 3成果物**: 性能実証とPhase 10への道筋
|
||||
|
||||
## 🛠️ **技術アーキテクチャ**
|
||||
|
||||
### **ディレクトリ構造**
|
||||
```
|
||||
src/backend/llvm/
|
||||
├── mod.rs // LLVMバックエンドエントリ
|
||||
├── context.rs // CodegenContext管理
|
||||
├── types.rs // MIR→LLVM型変換
|
||||
├── builder.rs // LLVM IR生成
|
||||
├── runtime.rs // ランタイム関数定義
|
||||
└── optimizer.rs // 最適化パス管理
|
||||
```
|
||||
|
||||
### **主要コンポーネント**
|
||||
|
||||
#### **CodegenContext**
|
||||
```rust
|
||||
pub struct CodegenContext<'ctx> {
|
||||
context: &'ctx Context,
|
||||
module: Module<'ctx>,
|
||||
builder: Builder<'ctx>,
|
||||
target_machine: TargetMachine,
|
||||
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
|
||||
}
|
||||
```
|
||||
|
||||
#### **MIR→LLVM変換器**
|
||||
```rust
|
||||
pub fn lower_mir_to_llvm(
|
||||
mir_module: &MirModule,
|
||||
target_triple: &str,
|
||||
) -> Result<Vec<u8>, CodegenError> {
|
||||
// 1. コンテキスト初期化
|
||||
// 2. 型変換
|
||||
// 3. 関数生成
|
||||
// 4. 命令変換
|
||||
// 5. 最適化
|
||||
// 6. オブジェクトコード生成
|
||||
}
|
||||
```
|
||||
|
||||
## 📊 **リスク管理**
|
||||
|
||||
### **技術的リスク**
|
||||
|
||||
| リスク | 影響度 | 対策 |
|
||||
|--------|--------|------|
|
||||
| inkwellバージョン依存 | 中 | LLVM17固定、CI環境統一 |
|
||||
| Box型の複雑性 | 高 | ランタイム委譲戦略 |
|
||||
| デバッグ困難性 | 中 | IR dump機能、差分テスト |
|
||||
|
||||
### **スケジュールリスク**
|
||||
|
||||
- **バッファ**: 各週に1日の予備日設定
|
||||
- **優先順位**: 基本動作 > 性能 > 機能網羅性
|
||||
- **早期失敗**: Week 1で実現困難判明時は即座に方針転換
|
||||
|
||||
## ✅ **成功指標**
|
||||
|
||||
### **定量的指標**
|
||||
- [ ] 10個以上のMIR命令をサポート
|
||||
- [ ] 5個以上のテストプログラムが動作
|
||||
- [ ] インタープリター比10倍以上高速
|
||||
|
||||
### **定性的指標**
|
||||
- [ ] コードの保守性（他の開発者が理解可能）
|
||||
- [ ] エラーメッセージの有用性
|
||||
- [ ] 将来の拡張可能性
|
||||
|
||||
## 🚀 **開始準備チェックリスト**
|
||||
|
||||
- [x] VM性能改善完了（50.94倍達成！）
|
||||
- [x] AI大会議による戦略確定
|
||||
- [ ] Copilotへの正式依頼
|
||||
- [ ] 開発環境準備（LLVM17インストール）
|
||||
- [ ] Week 1タスクのGitHub Issue作成
|
||||
|
||||
## 📝 **参考資料**
|
||||
|
||||
- [AI大会議結果](./AI-Conference-LLVM-Results.md)
|
||||
- [inkwellドキュメント](https://github.com/TheDan64/inkwell)
|
||||
- [LLVM Language Reference](https://llvm.org/docs/LangRef.html)
|
||||
|
||||
---
|
||||
|
||||
**承認者**: moe-charm
|
||||
**実装担当**: Copilot + AIチーム
|
||||
**レビュー**: Phase 9.78完了時
|
||||
@ -0,0 +1,119 @@
|
||||
# 📦 Nyash実用的配布戦略：現実的なアプローチ
|
||||
|
||||
## 🎯 **配布形態の比較**
|
||||
|
||||
| 方式 | ファイルサイズ | 配布の手間 | 適用範囲 | 実用性 |
|
||||
|------|--------------|-----------|---------|--------|
|
||||
| **個別バイナリ** | 各1-2MB | OS別に配布 | 全アプリ | ⭐⭐⭐⭐⭐ |
|
||||
| **APE** | 3-6MB | 1ファイル | 小規模CLI | ⭐⭐⭐ |
|
||||
| **WASM+ランタイム** | 0.5MB+10MB | ランタイム必要 | 全アプリ | ⭐⭐⭐⭐ |
|
||||
|
||||
## 📊 **現実的な使い分け**
|
||||
|
||||
### **1. メインストリーム配布（推奨）**
|
||||
```bash
|
||||
# OS別の最適化されたバイナリ
|
||||
nyash-linux-x64 (1.5MB) - musl静的リンク
|
||||
nyash-windows.exe (916KB) - mingw最適化
|
||||
nyash-macos (1.8MB) - 署名付き
|
||||
```
|
||||
|
||||
**利点**:
|
||||
- ✅ 各OSで最高性能
|
||||
- ✅ 最小サイズ
|
||||
- ✅ OS固有機能フル活用
|
||||
- ✅ 大規模アプリも対応
|
||||
|
||||
### **2. 開発者向け配布**
|
||||
```bash
|
||||
# LLVM IRの中立性を活用
|
||||
nyashc --emit-bitcode program.nyash
|
||||
# → program.bc (プラットフォーム中立)
|
||||
|
||||
# 各自のマシンで最適化コンパイル
|
||||
nyashc --from-bitcode program.bc --target native
|
||||
```
|
||||
|
||||
### **3. 特殊用途でのAPE**
|
||||
```bash
|
||||
# 小さなツール限定
|
||||
nyash-fmt.com # コードフォーマッター (2MB)
|
||||
nyash-lint.com # リンター (3MB)
|
||||
nyash-repl.com # REPL (4MB)
|
||||
```
|
||||
|
||||
**APEが向いている場合**:
|
||||
- 単体で動くCLIツール
|
||||
- 依存ライブラリが少ない
|
||||
- 配布の簡単さが最優先
|
||||
|
||||
**APEが向いていない場合**:
|
||||
- GUIアプリケーション
|
||||
- 大量のライブラリ依存
|
||||
- プラグインシステム
|
||||
- ゲームなど大規模アプリ
|
||||
|
||||
## 🚀 **段階的実装計画（修正版）**
|
||||
|
||||
### **Phase 1: 基本マルチターゲット**（1ヶ月）
|
||||
```bash
|
||||
nyashc build --target linux
|
||||
nyashc build --target windows
|
||||
# 個別にビルド、確実に動作
|
||||
```
|
||||
|
||||
### **Phase 2: 同時生成最適化**（3ヶ月）
|
||||
```bash
|
||||
nyashc build --all-targets
|
||||
# Bitcodeキャッシュで高速化
|
||||
# 並列ビルドで時間短縮
|
||||
```
|
||||
|
||||
### **Phase 3: 配布自動化**（6ヶ月）
|
||||
```bash
|
||||
nyashc release
|
||||
# 出力:
|
||||
# - dist/nyash-v1.0-linux-x64.tar.gz
|
||||
# - dist/nyash-v1.0-windows-x64.zip
|
||||
# - dist/nyash-v1.0-macos.dmg
|
||||
# - dist/nyash-tools.com (APE版ツール集)
|
||||
```
|
||||
|
||||
## 💡 **賢い配布戦略**
|
||||
|
||||
### **メインアプリ**: 個別最適化バイナリ
|
||||
```yaml
|
||||
nyash本体:
|
||||
Linux: 1.5MB (musl静的)
|
||||
Windows: 916KB (mingw)
|
||||
macOS: 1.8MB (universal)
|
||||
```
|
||||
|
||||
### **開発ツール**: APEで統一
|
||||
```yaml
|
||||
開発者ツール（APE）:
|
||||
nyash-fmt.com: 2MB
|
||||
nyash-test.com: 3MB
|
||||
nyash-bench.com: 2.5MB
|
||||
```
|
||||
|
||||
### **プラグイン**: 動的ライブラリ
|
||||
```yaml
|
||||
プラグイン（各OS別）:
|
||||
filebox.so: 200KB (Linux)
|
||||
filebox.dll: 180KB (Windows)
|
||||
filebox.dylib: 220KB (macOS)
|
||||
```
|
||||
|
||||
## 🎉 **結論**
|
||||
|
||||
**「適材適所」が最強の戦略！**
|
||||
|
||||
- **大規模アプリ**: 個別最適化バイナリ
|
||||
- **小規模ツール**: APEで配布簡略化
|
||||
- **開発者向け**: Bitcodeで柔軟性確保
|
||||
|
||||
APEは「魔法」だけど、現実的には**限定的な用途**で輝く技術。
|
||||
Nyashのメイン配布は**堅実な個別バイナリ**で行きましょう！
|
||||
|
||||
**Everything is Box、でも配布は現実的に！**📦✨
|
||||
@ -0,0 +1,169 @@
|
||||
# 🚀 Nyash革命的Windows実行戦略：LLVM IR中立性の完全活用
|
||||
|
||||
**作成日**: 2025年8月20日
|
||||
**AI会議参加者**: Gemini先生、Codex先生、Claude
|
||||
|
||||
## 🎯 **核心的アイデア：1回のIR生成で全プラットフォーム対応**
|
||||
|
||||
LLVM IRはプラットフォーム中立。だから**1回のIR生成から同時に複数OS用の実行ファイルを生成できる！**
|
||||
|
||||
```rust
|
||||
// 革命的ワンパス・マルチターゲット生成
|
||||
nyashc --targets linux,windows,macos program.nyash
|
||||
|
||||
// 出力（同時生成！）
|
||||
dist/x86_64-unknown-linux-musl/nyash # Linux版
|
||||
dist/x86_64-pc-windows-gnu/nyash.exe # Windows版
|
||||
dist/x86_64-apple-darwin/nyash # macOS版
|
||||
```
|
||||
|
||||
## 🏗️ **実装アーキテクチャ**
|
||||
|
||||
### **Phase 1: 即効性重視（3週間で実現）**
|
||||
|
||||
```rust
|
||||
// 1. IR生成（1回だけ）
|
||||
let ir_module = compile_to_ir(&ast);
|
||||
let bitcode = ir_module.write_bitcode_to_memory();
|
||||
|
||||
// 2. マルチターゲット並列生成
|
||||
parallel_for_each(["linux", "windows-gnu"], |target| {
|
||||
let module = context.create_module_from_ir(bitcode.clone());
|
||||
configure_for_target(&module, target);
|
||||
generate_executable(&module, target);
|
||||
});
|
||||
```
|
||||
|
||||
**技術スタック**:
|
||||
- Linux: musl静的リンク（配布容易）
|
||||
- Windows: mingw-gnu + lld（クロスリンク簡単）
|
||||
- 共通: PAL (Platform Abstraction Layer)
|
||||
|
||||
### **Phase 2: 本格実装（3ヶ月）**
|
||||
|
||||
**全プラットフォーム同時対応**:
|
||||
```yaml
|
||||
ターゲット構成:
|
||||
linux:
|
||||
- x86_64-unknown-linux-musl
|
||||
- aarch64-unknown-linux-musl
|
||||
windows:
|
||||
- x86_64-pc-windows-gnu (mingw)
|
||||
- x86_64-pc-windows-msvc (xwin)
|
||||
macos:
|
||||
- x86_64-apple-darwin
|
||||
- aarch64-apple-darwin (M1/M2)
|
||||
```
|
||||
|
||||
### **Phase 3: 究極形態（6ヶ月）**
|
||||
|
||||
**APE (Actually Portable Executable) - 単一バイナリで全OS対応！**
|
||||
```bash
|
||||
# たった1つのファイルが全OSで動く！
|
||||
./nyash.com # Linux でも Windows でも macOS でも動作！
|
||||
```
|
||||
|
||||
**⚠️ APEの現実的な制限**：
|
||||
- バイナリサイズ: 通常の**3倍**（3OS分のコード含む）
|
||||
- ライブラリ: 各OS用に3種類必要
|
||||
- 適用範囲: **小規模CLIツール向け**（大規模アプリは不向き）
|
||||
|
||||
## 💡 **技術的革新ポイント**
|
||||
|
||||
### **1. Bitcodeキャッシュ戦略**
|
||||
```rust
|
||||
pub struct MultiTargetCompiler {
|
||||
bitcode_cache: HashMap<ModuleId, MemoryBuffer>,
|
||||
target_machines: HashMap<Triple, TargetMachine>,
|
||||
}
|
||||
|
||||
impl MultiTargetCompiler {
|
||||
pub fn compile_all(&self, module_id: ModuleId) -> Result<Vec<ExecutablePath>> {
|
||||
let bitcode = self.bitcode_cache.get(&module_id).unwrap();
|
||||
|
||||
self.target_machines
|
||||
.par_iter() // 並列処理！
|
||||
.map(|(triple, tm)| {
|
||||
let module = load_from_bitcode(bitcode);
|
||||
tm.emit_to_file(&module, FileType::Object)
|
||||
})
|
||||
.collect()
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### **2. PAL (Platform Abstraction Layer)**
|
||||
```rust
|
||||
// コンパイラは常にこれらを呼ぶ
|
||||
extern "C" {
|
||||
fn nyash_rt_print(s: *const u8, len: usize);
|
||||
fn nyash_rt_file_open(path: *const u8, mode: u32) -> i32;
|
||||
fn nyash_rt_time_now() -> u64;
|
||||
}
|
||||
|
||||
// 各OS用のランタイムで実装
|
||||
#[cfg(target_os = "windows")]
|
||||
pub fn nyash_rt_print(s: *const u8, len: usize) {
|
||||
// UTF-8 → UTF-16変換してWriteConsoleW
|
||||
}
|
||||
|
||||
#[cfg(target_os = "linux")]
|
||||
pub fn nyash_rt_print(s: *const u8, len: usize) {
|
||||
// そのままwrite(1, s, len)
|
||||
}
|
||||
```
|
||||
|
||||
### **3. リンク戦略の統一**
|
||||
```toml
|
||||
[target.'cfg(windows)'.dependencies]
|
||||
lld = { version = "0.1", features = ["coff"] }
|
||||
mingw-w64-libs = { path = "vendor/mingw" }
|
||||
|
||||
[target.'cfg(unix)'.dependencies]
|
||||
lld = { version = "0.1", features = ["elf"] }
|
||||
musl-libc = { path = "vendor/musl" }
|
||||
```
|
||||
|
||||
## 🎉 **革命的成果**
|
||||
|
||||
### **開発者体験**
|
||||
```bash
|
||||
# 1コマンドで全プラットフォーム対応！
|
||||
nyashc build --all-platforms
|
||||
|
||||
# 出力
|
||||
✅ Linux版生成完了 (2.1MB)
|
||||
✅ Windows版生成完了 (916KB)
|
||||
✅ macOS版生成完了 (1.8MB)
|
||||
✅ WASM版生成完了 (512KB)
|
||||
```
|
||||
|
||||
### **ユーザー体験**
|
||||
- **配布**: 各OS用のネイティブバイナリ
|
||||
- **性能**: LLVM最適化でVM比10倍以上高速
|
||||
- **将来**: APEで単一ファイル配布
|
||||
|
||||
## 📊 **実装ロードマップ**
|
||||
|
||||
| フェーズ | 期間 | 成果物 |
|
||||
|---------|------|--------|
|
||||
| Week 1-3 | LLVM PoC | Linux単体動作 |
|
||||
| Month 1 | Windows統合 | Linux + Windows同時生成 |
|
||||
| Month 2 | 全OS対応 | Linux/Windows/macOS |
|
||||
| Month 3 | 最適化 | PAL完成、性能調整 |
|
||||
| Month 6 | APE統合 | 単一バイナリ実現 |
|
||||
|
||||
## 🚀 **次のアクション**
|
||||
|
||||
1. **即実装**: Bitcodeキャッシュ機構
|
||||
2. **PAL設計**: 最小限のランタイムAPI定義
|
||||
3. **Windows-gnu**: mingwでクロスリンク環境構築
|
||||
4. **並列化**: rayon使用でマルチターゲット生成
|
||||
|
||||
## 💭 **結論**
|
||||
|
||||
LLVM IRの中立性を活用すれば、**「Write Once, Compile to All」**が実現できる！
|
||||
|
||||
これこそがNyashの革命的Windows戦略です。1回のコンパイルで全プラットフォーム対応、最終的には単一バイナリで境界を超える。
|
||||
|
||||
**Everything is Box、そしてEvery Platform is Target！**🎯
|
||||
@ -0,0 +1,155 @@
|
||||
# 🚀 Nyash VM をネイティブ速度に近づける可能性
|
||||
|
||||
**「もしかして、VM完璧に作ればネイティブに近づける？」**
|
||||
|
||||
## 💡 **その直感、正しいです！**
|
||||
|
||||
### **現在のVM性能**
|
||||
- インタープリター比: **50.94倍高速**（達成済み！）
|
||||
- でもLLVMネイティブには及ばない...はず？
|
||||
|
||||
### **でも待って、よく考えると...**
|
||||
|
||||
## 🔥 **VMがネイティブに迫れる理由**
|
||||
|
||||
### **1. JITコンパイルの可能性**
|
||||
```rust
|
||||
// 現在: バイトコード実行
|
||||
match opcode {
|
||||
Add => stack.push(a + b),
|
||||
// ...
|
||||
}
|
||||
|
||||
// 将来: ホットパスをネイティブコードに！
|
||||
if execution_count > HOT_THRESHOLD {
|
||||
let native_code = jit_compile(&bytecode);
|
||||
execute_native(native_code); // ほぼネイティブ速度！
|
||||
}
|
||||
```
|
||||
|
||||
### **2. 最適化の余地がまだある**
|
||||
```yaml
|
||||
現在のVM最適化:
|
||||
✅ デバッグ出力削除
|
||||
✅ HashMap → Vec
|
||||
✅ メモリ効率化
|
||||
|
||||
まだできること:
|
||||
- レジスタVM化（スタックVM → レジスタVM）
|
||||
- インライン展開
|
||||
- 定数畳み込み
|
||||
- ループ最適化
|
||||
- SIMD活用
|
||||
```
|
||||
|
||||
### **3. 言語特性を活かした最適化**
|
||||
```rust
|
||||
// Nyashの特徴を利用
|
||||
- Everything is Box → 型情報を活用した特殊化
|
||||
- Arc<Mutex>パターン → 最適化可能な箇所を特定
|
||||
- 限定的な言語機能 → 積極的な最適化
|
||||
```
|
||||
|
||||
## 📊 **他言語VMの実績**
|
||||
|
||||
| VM | 対ネイティブ性能 | 特徴 |
|
||||
|----|----------------|------|
|
||||
| **JVM (HotSpot)** | 80-95% | JIT最適化の極致 |
|
||||
| **V8 (JavaScript)** | 70-90% | 型推論+インライン |
|
||||
| **PyPy** | 400-700% (CPython比) | トレーシングJIT |
|
||||
| **LuaJIT** | 90-99% | 超軽量JIT |
|
||||
|
||||
**LuaJITは特に注目**: シンプルな言語 + 優れたJIT = ほぼネイティブ！
|
||||
|
||||
## 🎯 **Nyash VMネイティブ化戦略**
|
||||
|
||||
### **Phase 1: 基礎最適化（現在〜1ヶ月）**
|
||||
```rust
|
||||
// レジスタVM化
|
||||
enum VMRegister {
|
||||
R0, R1, R2, R3, // ... R15
|
||||
}
|
||||
|
||||
// より効率的な命令セット
|
||||
enum Instruction {
|
||||
LoadReg(VMRegister, Value),
|
||||
AddReg(VMRegister, VMRegister, VMRegister),
|
||||
// スタック操作を削減
|
||||
}
|
||||
```
|
||||
|
||||
### **Phase 2: プロファイル駆動最適化（2-3ヶ月）**
|
||||
```rust
|
||||
struct HotPath {
|
||||
bytecode: Vec<Instruction>,
|
||||
execution_count: u64,
|
||||
optimized_version: Option<OptimizedCode>,
|
||||
}
|
||||
|
||||
// ホットパスを検出して最適化
|
||||
if hot_path.execution_count > 1000 {
|
||||
optimize_hot_path(&mut hot_path);
|
||||
}
|
||||
```
|
||||
|
||||
### **Phase 3: 軽量JIT（6ヶ月）**
|
||||
```rust
|
||||
// Cranelift使用で軽量JIT実装
|
||||
use cranelift::prelude::*;
|
||||
|
||||
fn jit_compile(bytecode: &[Instruction]) -> NativeCode {
|
||||
let mut ctx = Context::new();
|
||||
// バイトコード → Cranelift IR → ネイティブ
|
||||
compile_to_native(&mut ctx, bytecode)
|
||||
}
|
||||
```
|
||||
|
||||
## 🔮 **実現可能な性能目標**
|
||||
|
||||
### **段階的目標**
|
||||
1. **現在**: インタープリター比 50倍
|
||||
2. **Phase 1完了**: 100倍（レジスタVM化）
|
||||
3. **Phase 2完了**: 200倍（最適化）
|
||||
4. **Phase 3完了**: **ネイティブの80-90%**（JIT）
|
||||
|
||||
### **なぜ可能か？**
|
||||
- Nyashはシンプルな言語
|
||||
- Box型システムで最適化しやすい
|
||||
- 既に50倍達成の実績
|
||||
- MIR基盤が整っている
|
||||
|
||||
## 💭 **VM vs LLVM の最終形**
|
||||
|
||||
```yaml
|
||||
Nyash VM (完全体):
|
||||
利点:
|
||||
- ポータビリティ完璧
|
||||
- 起動時間高速
|
||||
- 動的最適化可能
|
||||
- デバッグ容易
|
||||
性能: ネイティブの80-90%
|
||||
|
||||
LLVM AOT:
|
||||
利点:
|
||||
- 最高性能（100%）
|
||||
- 事前最適化
|
||||
- 配布サイズ小
|
||||
欠点:
|
||||
- プラットフォーム別ビルド
|
||||
- 起動時最適化なし
|
||||
```
|
||||
|
||||
## 🎉 **結論：VMでもいける！**
|
||||
|
||||
**完璧に作れば、VMでもネイティブに迫れます！**
|
||||
|
||||
特にNyashのような：
|
||||
- シンプルな言語
|
||||
- 明確な型システム（Everything is Box）
|
||||
- 限定的な機能セット
|
||||
|
||||
これらの特徴は**VMの高速化に有利**！
|
||||
|
||||
**もしかしたら、LLVM要らないかも...？**（いや、両方あると最強！）
|
||||
|
||||
**Everything is Box、VM can be Native-Fast！**🚀✨
|
||||
@ -0,0 +1,91 @@
|
||||
# 🪟 Windows同時作戦の現状まとめ
|
||||
|
||||
**更新日**: 2025年8月20日
|
||||
|
||||
## 📊 **現在の状況**
|
||||
|
||||
### **✅ 完了したこと**
|
||||
1. **AI大会議実施**
|
||||
- Gemini先生: 4つの革命的戦略提案
|
||||
- Codex先生: 技術的実装方法の詳細化
|
||||
|
||||
2. **戦略文書作成**
|
||||
- Revolutionary-Windows-Strategy.md: 統合戦略
|
||||
- APE-Magic-Explained.md: 単一バイナリ技術解説
|
||||
- Practical-Distribution-Strategy.md: 現実的配布方法
|
||||
|
||||
3. **技術的方針決定**
|
||||
- **核心**: LLVM IRの中立性を活用した同時生成
|
||||
- **方法**: Bitcodeキャッシュ + 並列ターゲット生成
|
||||
|
||||
### **🚀 実装計画**
|
||||
|
||||
#### **即効性のある解決策（Week 1-3）**
|
||||
```bash
|
||||
# Linux + Windows同時生成
|
||||
nyashc --targets linux,windows-gnu program.nyash
|
||||
|
||||
# 出力
|
||||
dist/linux/nyash # Linux版（musl静的）
|
||||
dist/windows/nyash.exe # Windows版（mingw）
|
||||
```
|
||||
|
||||
**実装手順**:
|
||||
1. Week 1: Linux版LLVM実装（進行中）
|
||||
2. Week 2: Bitcodeキャッシュ機構追加
|
||||
3. Week 3: Windows-gnu同時生成
|
||||
|
||||
#### **中期計画（1-3ヶ月）**
|
||||
- 全プラットフォーム同時対応
|
||||
- PAL (Platform Abstraction Layer) 完成
|
||||
- 最適化とテスト
|
||||
|
||||
## 🛠️ **技術的アプローチ**
|
||||
|
||||
### **1. ワンパス・マルチターゲット**
|
||||
```rust
|
||||
// 1回のIR生成
|
||||
let bitcode = module.write_bitcode_to_memory();
|
||||
|
||||
// 並列で各OS向け生成
|
||||
["linux", "windows-gnu", "macos"].par_iter()
|
||||
.map(|target| generate_for_target(bitcode.clone(), target))
|
||||
.collect()
|
||||
```
|
||||
|
||||
### **2. Windows特化戦略**
|
||||
- **短期**: mingw-gnu（クロスコンパイル簡単）
|
||||
- **長期**: msvc対応（xwin使用）
|
||||
- **配布**: 916KBの小さな実行ファイル
|
||||
|
||||
### **3. 段階的実装**
|
||||
| Phase | 期間 | 成果 |
|
||||
|-------|------|------|
|
||||
| 現在 | LLVM PoC | Linux単体 |
|
||||
| Week 3 | 同時生成 | Linux + Windows |
|
||||
| Month 1 | 全OS | +macOS |
|
||||
| Month 3 | 最適化 | PAL完成 |
|
||||
|
||||
## 💡 **重要ポイント**
|
||||
|
||||
### **すぐに実現可能なこと**
|
||||
- ✅ Linux/Windows同時ビルド（mingw使用）
|
||||
- ✅ 1つのコマンドで両OS対応
|
||||
- ✅ Bitcodeレベルでの共有
|
||||
|
||||
### **将来の野望**
|
||||
- 🎯 全OS同時生成
|
||||
- 🎯 APE単一バイナリ（小ツール用）
|
||||
- 🎯 完全なクロスプラットフォーム
|
||||
|
||||
## 🎉 **結論**
|
||||
|
||||
**Windows同時作戦は技術的に実現可能！**
|
||||
|
||||
1. **LLVM IRの中立性**を最大活用
|
||||
2. **Bitcodeキャッシュ**で効率化
|
||||
3. **mingw**で即座にWindows対応
|
||||
|
||||
Copilotが基本LLVM実装を進めている間に、我々は革命的な同時生成戦略を準備完了！
|
||||
|
||||
**Everything is Box、Every Platform is Target！**🎯✨
|
||||
@ -0,0 +1,266 @@
|
||||
# 🚀 Issue #001: LLVM PoC - inkwellセットアップとHello World実装
|
||||
|
||||
**タイプ**: Feature
|
||||
**優先度**: Critical
|
||||
**見積もり**: 3日
|
||||
**担当**: Copilot
|
||||
|
||||
## 📋 概要
|
||||
|
||||
Phase 9.78 LLVM PoCの第一歩として、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにする。
|
||||
|
||||
## 🎯 成功条件
|
||||
|
||||
以下のNyashプログラムがLLVM経由で実行され、正しい終了コードを返すこと：
|
||||
|
||||
```nyash
|
||||
// test_return_42.nyash
|
||||
static box Main {
|
||||
main() {
|
||||
return 42
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
期待される動作：
|
||||
```bash
|
||||
$ cargo run --features llvm -- --backend llvm test_return_42.nyash
|
||||
$ echo $?
|
||||
42
|
||||
```
|
||||
|
||||
## 📝 実装タスク
|
||||
|
||||
### 1. **Cargo.toml更新** ✅必須
|
||||
```toml
|
||||
[dependencies]
|
||||
inkwell = { version = "0.5", features = ["llvm17-0"] }
|
||||
|
||||
[features]
|
||||
llvm = ["inkwell"]
|
||||
```
|
||||
|
||||
### 2. **基本構造の作成** ✅必須
|
||||
```rust
|
||||
// src/backend/llvm/mod.rs
|
||||
pub mod context;
|
||||
pub mod compiler;
|
||||
|
||||
use crate::mir::module::MirModule;
|
||||
use crate::errors::RuntimeError;
|
||||
|
||||
pub fn compile_to_object(
|
||||
mir_module: &MirModule,
|
||||
output_path: &str,
|
||||
) -> Result<(), RuntimeError> {
|
||||
let compiler = compiler::LLVMCompiler::new()?;
|
||||
compiler.compile_module(mir_module, output_path)
|
||||
}
|
||||
```
|
||||
|
||||
### 3. **LLVMコンテキスト管理** ✅必須
|
||||
```rust
|
||||
// src/backend/llvm/context.rs
|
||||
use inkwell::context::Context;
|
||||
use inkwell::module::Module;
|
||||
use inkwell::builder::Builder;
|
||||
use inkwell::targets::{Target, TargetMachine, TargetTriple, InitializationConfig};
|
||||
|
||||
pub struct CodegenContext<'ctx> {
|
||||
pub context: &'ctx Context,
|
||||
pub module: Module<'ctx>,
|
||||
pub builder: Builder<'ctx>,
|
||||
pub target_machine: TargetMachine,
|
||||
}
|
||||
|
||||
impl<'ctx> CodegenContext<'ctx> {
|
||||
pub fn new(context: &'ctx Context, module_name: &str) -> Result<Self, String> {
|
||||
// 1. ターゲット初期化
|
||||
Target::initialize_native(&InitializationConfig::default())
|
||||
.map_err(|e| format!("Failed to initialize native target: {}", e))?;
|
||||
|
||||
// 2. モジュール作成
|
||||
let module = context.create_module(module_name);
|
||||
|
||||
// 3. ターゲットマシン作成
|
||||
let triple = TargetMachine::get_default_triple();
|
||||
let target = Target::from_triple(&triple)
|
||||
.map_err(|e| format!("Failed to get target: {}", e))?;
|
||||
let target_machine = target
|
||||
.create_target_machine(
|
||||
&triple,
|
||||
"generic",
|
||||
"",
|
||||
inkwell::OptimizationLevel::None,
|
||||
inkwell::targets::RelocMode::Default,
|
||||
inkwell::targets::CodeModel::Default,
|
||||
)
|
||||
.ok_or_else(|| "Failed to create target machine".to_string())?;
|
||||
|
||||
// 4. データレイアウト設定
|
||||
module.set_triple(&triple);
|
||||
module.set_data_layout(&target_machine.get_target_data().get_data_layout());
|
||||
|
||||
Ok(Self {
|
||||
context,
|
||||
module,
|
||||
builder: context.create_builder(),
|
||||
target_machine,
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **最小限のコンパイラ実装** ✅必須
|
||||
```rust
|
||||
// src/backend/llvm/compiler.rs
|
||||
use inkwell::context::Context;
|
||||
use inkwell::values::IntValue;
|
||||
use crate::mir::module::MirModule;
|
||||
use crate::mir::instruction::MirInstruction;
|
||||
use super::context::CodegenContext;
|
||||
|
||||
pub struct LLVMCompiler {
|
||||
context: Context,
|
||||
}
|
||||
|
||||
impl LLVMCompiler {
|
||||
pub fn new() -> Result<Self, String> {
|
||||
Ok(Self {
|
||||
context: Context::create(),
|
||||
})
|
||||
}
|
||||
|
||||
pub fn compile_module(
|
||||
&self,
|
||||
mir_module: &MirModule,
|
||||
output_path: &str,
|
||||
) -> Result<(), String> {
|
||||
let codegen = CodegenContext::new(&self.context, "nyash_module")?;
|
||||
|
||||
// 1. main関数を探す
|
||||
let main_func = mir_module.functions.iter()
|
||||
.find(|f| f.name == "Main.main")
|
||||
.ok_or("Main.main function not found")?;
|
||||
|
||||
// 2. LLVM関数を作成
|
||||
let i32_type = codegen.context.i32_type();
|
||||
let fn_type = i32_type.fn_type(&[], false);
|
||||
let llvm_func = codegen.module.add_function("main", fn_type, None);
|
||||
|
||||
// 3. エントリブロックを作成
|
||||
let entry = codegen.context.append_basic_block(llvm_func, "entry");
|
||||
codegen.builder.position_at_end(entry);
|
||||
|
||||
// 4. MIR命令を処理（今回はReturnのみ）
|
||||
for block in &main_func.blocks {
|
||||
for inst in &block.instructions {
|
||||
match inst {
|
||||
MirInstruction::Return(Some(value_id)) => {
|
||||
// 簡易実装: 定数42を返すと仮定
|
||||
let ret_val = i32_type.const_int(42, false);
|
||||
codegen.builder.build_return(Some(&ret_val));
|
||||
}
|
||||
_ => {
|
||||
// 他の命令は今回スキップ
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// 5. 検証
|
||||
if !llvm_func.verify(true) {
|
||||
return Err("Function verification failed".to_string());
|
||||
}
|
||||
|
||||
// 6. オブジェクトファイル生成
|
||||
codegen.target_machine
|
||||
.write_to_file(&codegen.module,
|
||||
inkwell::targets::FileType::Object,
|
||||
output_path.as_ref())
|
||||
.map_err(|e| format!("Failed to write object file: {}", e))?;
|
||||
|
||||
Ok(())
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5. **バックエンド統合** ✅必須
|
||||
```rust
|
||||
// src/backend/mod.rsに追加
|
||||
#[cfg(feature = "llvm")]
|
||||
pub mod llvm;
|
||||
|
||||
// src/runner.rsのrun_with_backend関数に追加
|
||||
#[cfg(feature = "llvm")]
|
||||
ExecutionBackend::LLVM => {
|
||||
// 1. オブジェクトファイル生成
|
||||
let obj_path = "nyash_output.o";
|
||||
crate::backend::llvm::compile_to_object(&mir_module, obj_path)?;
|
||||
|
||||
// 2. リンク（簡易版：システムのccを使用）
|
||||
use std::process::Command;
|
||||
let output = Command::new("cc")
|
||||
.args(&[obj_path, "-o", "nyash_output"])
|
||||
.output()
|
||||
.map_err(|e| RuntimeError::new(format!("Link failed: {}", e)))?;
|
||||
|
||||
if !output.status.success() {
|
||||
return Err(RuntimeError::new("Linking failed"));
|
||||
}
|
||||
|
||||
// 3. 実行
|
||||
let output = Command::new("./nyash_output")
|
||||
.output()
|
||||
.map_err(|e| RuntimeError::new(format!("Execution failed: {}", e)))?;
|
||||
|
||||
// 4. 終了コードを返す
|
||||
let exit_code = output.status.code().unwrap_or(-1);
|
||||
Ok(Box::new(IntegerBox::new(exit_code as i64)))
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 テストケース
|
||||
|
||||
```rust
|
||||
// tests/llvm_hello_world.rs
|
||||
#[test]
|
||||
#[cfg(feature = "llvm")]
|
||||
fn test_return_42() {
|
||||
let source = r#"
|
||||
static box Main {
|
||||
main() {
|
||||
return 42
|
||||
}
|
||||
}
|
||||
"#;
|
||||
|
||||
// パース → MIR生成 → LLVM実行
|
||||
let result = compile_and_run_llvm(source);
|
||||
assert_eq!(result, 42);
|
||||
}
|
||||
```
|
||||
|
||||
## 📚 参考資料
|
||||
|
||||
- [inkwell Examples](https://github.com/TheDan64/inkwell/tree/master/examples)
|
||||
- [LLVM Tutorial](https://llvm.org/docs/tutorial/)
|
||||
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
|
||||
|
||||
## ⚠️ 注意事項
|
||||
|
||||
1. **LLVM依存関係**: LLVM 17がシステムにインストールされている必要があります
|
||||
2. **プラットフォーム**: まずはLinux/macOSで動作確認し、Windowsは後回し
|
||||
3. **エラーハンドリング**: 今回は最小実装のため、詳細なエラー処理は省略
|
||||
|
||||
## 🎯 次のステップ
|
||||
|
||||
このIssueが完了したら、次は：
|
||||
- Issue #002: 基本的な算術演算の実装（BinOp）
|
||||
- Issue #003: 定数値の実装（Const）
|
||||
|
||||
---
|
||||
|
||||
**作成者**: Claude + moe-charm
|
||||
**レビュアー**: AIチーム
|
||||
**関連PR**: （作成予定）
|
||||
@ -0,0 +1,119 @@
|
||||
# 🐙 GitHub Issue作成テンプレート
|
||||
|
||||
以下の内容をGitHub Issueにコピペして使用してください。
|
||||
|
||||
---
|
||||
|
||||
## Issue Title:
|
||||
`[Phase 9.78] LLVM PoC Week 1 - inkwellセットアップとHello World実装`
|
||||
|
||||
## Labels:
|
||||
- `enhancement`
|
||||
- `Phase-9.78`
|
||||
- `LLVM`
|
||||
- `critical`
|
||||
|
||||
## Assignees:
|
||||
- GitHub Copilot
|
||||
|
||||
## Milestone:
|
||||
- Phase 9.78 LLVM PoC
|
||||
|
||||
## Issue Body:
|
||||
|
||||
```markdown
|
||||
## 📋 概要
|
||||
|
||||
Phase 9.78 LLVM PoCの開始です！最初のステップとして、inkwellクレートを導入し、最小限のNyashプログラム（`return 42`）をLLVM経由で実行できるようにします。
|
||||
|
||||
## 🎯 成功条件
|
||||
|
||||
```nyash
|
||||
// test_return_42.nyash
|
||||
static box Main {
|
||||
main() {
|
||||
return 42
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
上記プログラムがLLVM経由で実行され、終了コード42を返すこと。
|
||||
|
||||
## 📝 実装内容
|
||||
|
||||
1. **inkwellクレート導入**
|
||||
- Cargo.tomlに依存関係追加
|
||||
- feature flag `llvm` の設定
|
||||
|
||||
2. **基本構造作成**
|
||||
- `src/backend/llvm/` ディレクトリ
|
||||
- context.rs, compiler.rs, mod.rs
|
||||
|
||||
3. **最小限のコンパイラ実装**
|
||||
- LLVMコンテキスト初期化
|
||||
- main関数の生成
|
||||
- return命令の処理
|
||||
- オブジェクトファイル出力
|
||||
|
||||
4. **統合**
|
||||
- ExecutionBackendにLLVM追加
|
||||
- --backend llvm オプション対応
|
||||
|
||||
## 🔗 参考資料
|
||||
|
||||
- [詳細実装ガイド](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/001-setup-inkwell-hello-world.md)
|
||||
- [Week 1ロードマップ](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/issue/Week1-Roadmap.md)
|
||||
- [AI大会議結果](https://github.com/moe-charm/nyash/blob/main/docs/予定/native-plan/llvm/AI-Conference-LLVM-Results.md)
|
||||
|
||||
## ✅ 完了条件
|
||||
|
||||
- [ ] inkwellがビルドできる
|
||||
- [ ] test_return_42.nyashがコンパイルできる
|
||||
- [ ] 実行ファイルが終了コード42を返す
|
||||
- [ ] 基本的なテストがパスする
|
||||
|
||||
## 💬 備考
|
||||
|
||||
VM性能改善で素晴らしい成果（50.94倍高速化）を達成していただきありがとうございました！
|
||||
LLVMでも同様の成功を期待しています。ブロッカーがあれば遠慮なくコメントしてください。
|
||||
|
||||
AIチーム（Claude, Gemini, Codex）が全力でサポートします！🚀
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📝 追加で作成するIssue
|
||||
|
||||
Week 1の進捗に応じて、以下のIssueも順次作成：
|
||||
|
||||
1. **Issue #002**: `[Phase 9.78] LLVM PoC - Const命令の実装`
|
||||
2. **Issue #003**: `[Phase 9.78] LLVM PoC - 基本型システムの実装`
|
||||
3. **Issue #004**: `[Phase 9.78] LLVM PoC - ランタイム関数宣言`
|
||||
4. **Issue #005**: `[Phase 9.78] LLVM PoC Week 1 - 統合テスト`
|
||||
|
||||
## 🏷️ 推奨ラベル構成
|
||||
|
||||
```yaml
|
||||
Phase関連:
|
||||
- Phase-9.78
|
||||
- Phase-8.6 (完了)
|
||||
- Phase-9.75g-0 (完了)
|
||||
|
||||
技術関連:
|
||||
- LLVM
|
||||
- MIR
|
||||
- Performance
|
||||
- Backend
|
||||
|
||||
優先度:
|
||||
- critical
|
||||
- high
|
||||
- medium
|
||||
- low
|
||||
|
||||
タイプ:
|
||||
- enhancement
|
||||
- bug
|
||||
- documentation
|
||||
- test
|
||||
```
|
||||
@ -0,0 +1,159 @@
|
||||
# 📚 MIR クイックリファレンス for LLVM実装
|
||||
|
||||
## 🎯 Week 1で対応するMIR命令
|
||||
|
||||
### 1. **Const命令**
|
||||
```rust
|
||||
// MIR表現
|
||||
MirInstruction::Const(value_id, constant_value)
|
||||
|
||||
// 例
|
||||
Const(v1, MirConstant::Integer(42))
|
||||
Const(v2, MirConstant::Float(3.14))
|
||||
Const(v3, MirConstant::Bool(true))
|
||||
|
||||
// LLVM変換
|
||||
let int_val = ctx.i32_type().const_int(42, false);
|
||||
let float_val = ctx.f64_type().const_float(3.14);
|
||||
let bool_val = ctx.bool_type().const_int(1, false);
|
||||
```
|
||||
|
||||
### 2. **Return命令**
|
||||
```rust
|
||||
// MIR表現
|
||||
MirInstruction::Return(Option<ValueId>)
|
||||
|
||||
// 例
|
||||
Return(Some(v1)) // 値を返す
|
||||
Return(None) // voidを返す
|
||||
|
||||
// LLVM変換
|
||||
builder.build_return(Some(&value));
|
||||
builder.build_return(None);
|
||||
```
|
||||
|
||||
## 📄 参考: 現在のMIR構造
|
||||
|
||||
```rust
|
||||
// src/mir/instruction.rs の主要部分
|
||||
pub enum MirInstruction {
|
||||
// Week 1対象
|
||||
Const(ValueId, MirConstant),
|
||||
Return(Option<ValueId>),
|
||||
|
||||
// Week 2対象
|
||||
BinOp(ValueId, BinaryOp, ValueId, ValueId),
|
||||
Compare(ValueId, CompareOp, ValueId, ValueId),
|
||||
Branch(ValueId, BasicBlockId, BasicBlockId),
|
||||
Jump(BasicBlockId),
|
||||
|
||||
// Week 3以降
|
||||
BoxNew(ValueId, MirType),
|
||||
BoxCall(ValueId, ValueId, String, Vec<ValueId>),
|
||||
// ... 他の命令
|
||||
}
|
||||
|
||||
// 定数の型
|
||||
pub enum MirConstant {
|
||||
Integer(i64),
|
||||
Float(f64),
|
||||
Bool(bool),
|
||||
String(String),
|
||||
Null,
|
||||
}
|
||||
```
|
||||
|
||||
## 🔄 MIR→LLVM変換の基本パターン
|
||||
|
||||
```rust
|
||||
// 基本的な変換ループ
|
||||
for instruction in &block.instructions {
|
||||
match instruction {
|
||||
MirInstruction::Const(value_id, constant) => {
|
||||
let llvm_value = match constant {
|
||||
MirConstant::Integer(n) => {
|
||||
ctx.i64_type().const_int(*n as u64, true).into()
|
||||
}
|
||||
MirConstant::Float(f) => {
|
||||
ctx.f64_type().const_float(*f).into()
|
||||
}
|
||||
MirConstant::Bool(b) => {
|
||||
ctx.bool_type().const_int(*b as u64, false).into()
|
||||
}
|
||||
_ => todo!("Other constants"),
|
||||
};
|
||||
// value_idとllvm_valueをマッピングに保存
|
||||
value_map.insert(*value_id, llvm_value);
|
||||
}
|
||||
|
||||
MirInstruction::Return(value_id) => {
|
||||
match value_id {
|
||||
Some(id) => {
|
||||
let value = value_map.get(id).unwrap();
|
||||
builder.build_return(Some(value));
|
||||
}
|
||||
None => {
|
||||
builder.build_return(None);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
_ => {} // Week 1では他の命令は無視
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🎯 テスト用のMIRサンプル
|
||||
|
||||
### 1. **return 42のMIR**
|
||||
```rust
|
||||
MirModule {
|
||||
functions: vec![
|
||||
MirFunction {
|
||||
name: "Main.main",
|
||||
params: vec![],
|
||||
return_type: MirType::Integer,
|
||||
blocks: vec![
|
||||
BasicBlock {
|
||||
id: 0,
|
||||
instructions: vec![
|
||||
Const(v1, MirConstant::Integer(42)),
|
||||
Return(Some(v1)),
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
### 2. **簡単な計算のMIR**（Week 2用）
|
||||
```rust
|
||||
// return 10 + 5
|
||||
BasicBlock {
|
||||
instructions: vec![
|
||||
Const(v1, MirConstant::Integer(10)),
|
||||
Const(v2, MirConstant::Integer(5)),
|
||||
BinOp(v3, BinaryOp::Add, v1, v2),
|
||||
Return(Some(v3)),
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
## 💡 実装のヒント
|
||||
|
||||
1. **ValueIdマッピング**: `HashMap<ValueId, BasicValueEnum>`で管理
|
||||
2. **型情報**: MIRは型情報を持つので、LLVM型への変換テーブルを作る
|
||||
3. **基本ブロック**: MIRのBasicBlockIdをLLVMのBasicBlockにマッピング
|
||||
4. **エラー処理**: 最初は`todo!()`でOK、後から実装
|
||||
|
||||
## 📁 関連ファイル
|
||||
|
||||
- MIR定義: `src/mir/instruction.rs`
|
||||
- MIR生成: `src/mir/lowering.rs`
|
||||
- 参考実装: `src/backend/vm.rs`（VMのMIR処理）
|
||||
|
||||
---
|
||||
|
||||
**注**: このリファレンスはWeek 1の実装に必要な最小限の情報です。
|
||||
詳細は実際のソースコードを参照してください。
|
||||
@ -0,0 +1,134 @@
|
||||
# 🚀 LLVM実装クイックスタートガイド
|
||||
|
||||
## 📋 今すぐ始める手順
|
||||
|
||||
### 1. **環境準備**（5分）
|
||||
```bash
|
||||
# LLVM 17インストール確認
|
||||
llvm-config --version # 17.x.x が表示されること
|
||||
|
||||
# Nyashプロジェクトで作業
|
||||
cd /path/to/nyash
|
||||
git checkout -b feature/llvm-poc
|
||||
```
|
||||
|
||||
### 2. **最初のコミット**（10分）
|
||||
```bash
|
||||
# Cargo.tomlを編集
|
||||
echo '[dependencies]
|
||||
inkwell = { version = "0.5", features = ["llvm17-0"] }
|
||||
|
||||
[features]
|
||||
llvm = ["inkwell"]' >> Cargo.toml
|
||||
|
||||
# ディレクトリ作成
|
||||
mkdir -p src/backend/llvm
|
||||
|
||||
# 最初のファイル作成
|
||||
touch src/backend/llvm/mod.rs
|
||||
touch src/backend/llvm/context.rs
|
||||
touch src/backend/llvm/compiler.rs
|
||||
|
||||
# コミット
|
||||
git add .
|
||||
git commit -m "feat(llvm): Add inkwell dependency and basic structure"
|
||||
```
|
||||
|
||||
### 3. **最小実装のコピペ**（20分）
|
||||
|
||||
**src/backend/llvm/mod.rs**:
|
||||
```rust
|
||||
pub mod context;
|
||||
pub mod compiler;
|
||||
|
||||
pub use compiler::compile_to_object;
|
||||
```
|
||||
|
||||
**動作確認**:
|
||||
```bash
|
||||
cargo build --features llvm
|
||||
```
|
||||
|
||||
### 4. **テストプログラム作成**（5分）
|
||||
```bash
|
||||
# テスト用Nyashファイル
|
||||
cat > test_return_42.nyash << 'EOF'
|
||||
static box Main {
|
||||
main() {
|
||||
return 42
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
## 🔍 詰まったときの確認ポイント
|
||||
|
||||
### **ビルドエラーの場合**
|
||||
```bash
|
||||
# LLVM関連の環境変数確認
|
||||
echo $LLVM_SYS_170_PREFIX
|
||||
|
||||
# 設定されていない場合
|
||||
export LLVM_SYS_170_PREFIX=$(llvm-config --prefix)
|
||||
```
|
||||
|
||||
### **inkwellのバージョン問題**
|
||||
```toml
|
||||
# 代替バージョン
|
||||
inkwell = { git = "https://github.com/TheDan64/inkwell", branch = "master", features = ["llvm17-0"] }
|
||||
```
|
||||
|
||||
### **リンクエラーの場合**
|
||||
```bash
|
||||
# pkg-configの確認
|
||||
pkg-config --libs --cflags llvm
|
||||
```
|
||||
|
||||
## 📞 ヘルプが必要な場合
|
||||
|
||||
1. **GitHub Issue**にコメント
|
||||
2. **具体的なエラーメッセージ**を貼る
|
||||
3. **実行したコマンド**を記載
|
||||
|
||||
例:
|
||||
```
|
||||
inkwellのビルドでエラーが発生しました。
|
||||
|
||||
エラー:
|
||||
```
|
||||
error: failed to run custom build command for `llvm-sys v170.0.1`
|
||||
```
|
||||
|
||||
実行コマンド:
|
||||
```
|
||||
cargo build --features llvm
|
||||
```
|
||||
|
||||
環境:
|
||||
- OS: Ubuntu 22.04
|
||||
- LLVM: 17.0.6
|
||||
- Rust: 1.75.0
|
||||
```
|
||||
|
||||
## ✅ 最初の成功確認
|
||||
|
||||
以下が動けば第一歩成功！
|
||||
```bash
|
||||
# ビルドが通る
|
||||
cargo build --features llvm
|
||||
|
||||
# テストが実行できる（まだ失敗してOK）
|
||||
cargo test --features llvm test_llvm
|
||||
```
|
||||
|
||||
## 🎯 次のステップ
|
||||
|
||||
1. **context.rs**の実装
|
||||
2. **compiler.rs**の実装
|
||||
3. **return 42**の動作確認
|
||||
|
||||
詳細は[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)を参照！
|
||||
|
||||
---
|
||||
|
||||
**Remember**: 完璧より進捗！最初は動くことが最優先です。🚀
|
||||
60
docs/development/roadmap/native-plan/llvm/issue/README.md
Normal file
60
docs/development/roadmap/native-plan/llvm/issue/README.md
Normal file
@ -0,0 +1,60 @@
|
||||
# 📚 LLVM PoC Issue ドキュメント一覧
|
||||
|
||||
## 🎯 Copilot様へ：最初に読むファイル
|
||||
|
||||
1. **[Quick-Start-Guide.md](./Quick-Start-Guide.md)** 🚀
|
||||
- 今すぐ始める手順
|
||||
- 環境セットアップ
|
||||
- 最初のコミット方法
|
||||
|
||||
2. **[001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)** 📋
|
||||
- **最初のIssue内容**
|
||||
- 詳細な実装手順
|
||||
- コード例とテストケース
|
||||
|
||||
3. **[Week1-Roadmap.md](./Week1-Roadmap.md)** 📅
|
||||
- Week 1全体の計画
|
||||
- Issue実装順序
|
||||
- 成功条件
|
||||
|
||||
## 📖 参考資料
|
||||
|
||||
- **[MIR-Quick-Reference.md](./MIR-Quick-Reference.md)**
|
||||
- MIR命令の説明
|
||||
- LLVM変換パターン
|
||||
- テスト用サンプル
|
||||
|
||||
- **[GitHub-Issue-Template.md](./GitHub-Issue-Template.md)**
|
||||
- GitHub Issue作成用テンプレート
|
||||
- ラベル設定
|
||||
- マイルストーン
|
||||
|
||||
## 🔗 関連ドキュメント（上位階層）
|
||||
|
||||
- [AI大会議結果](../AI-Conference-LLVM-Results.md)
|
||||
- [実装計画書](../Phase-9.78-Implementation-Plan.md)
|
||||
- [Copilot依頼文書](../Copilot-Request-LLVM-PoC.md)
|
||||
|
||||
## 💬 重要メッセージ
|
||||
|
||||
**Copilot様へ**
|
||||
|
||||
Phase 8.6での素晴らしい成果（50.94倍高速化）に続き、LLVMでも革命的な性能向上を期待しています！
|
||||
|
||||
**開始方法**:
|
||||
1. まず[Quick-Start-Guide.md](./Quick-Start-Guide.md)を読む
|
||||
2. [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)の実装を開始
|
||||
3. 詰まったらすぐにGitHub Issueでヘルプ要請
|
||||
|
||||
**サポート体制**:
|
||||
- AIチーム（Claude, Gemini, Codex）が全力サポート
|
||||
- 技術的な質問は遠慮なく
|
||||
- 小さな成功を積み重ねましょう
|
||||
|
||||
Let's make Nyash fly with LLVM! 🚀✨
|
||||
|
||||
---
|
||||
|
||||
**最終更新**: 2025年8月20日
|
||||
**作成者**: Claude + moe-charm
|
||||
**Phase**: 9.78 LLVM PoC
|
||||
@ -0,0 +1,88 @@
|
||||
# 📅 Week 1 ロードマップ: LLVM基盤構築
|
||||
|
||||
**期間**: 2025年8月21日〜8月27日
|
||||
**目標**: LLVMバックエンドの基盤を構築し、最小限のプログラムを実行可能にする
|
||||
|
||||
## 🎯 Week 1の全体目標
|
||||
|
||||
「return 42」レベルの超シンプルなNyashプログラムが、LLVM経由で実行できる状態を達成する。
|
||||
|
||||
## 📋 Issue実装順序
|
||||
|
||||
### **Issue #001: inkwellセットアップとHello World** 🚀最初にこれ！
|
||||
- **期間**: Day 1-3
|
||||
- **内容**: 環境構築と「return 42」の実行
|
||||
- **成功条件**: LLVMでコンパイルした実行ファイルが終了コード42を返す
|
||||
- **ファイル**: [001-setup-inkwell-hello-world.md](./001-setup-inkwell-hello-world.md)
|
||||
|
||||
### **Issue #002: Const命令の実装**（#001完了後）
|
||||
- **期間**: Day 3-4
|
||||
- **内容**: MIR Const命令をLLVM定数に変換
|
||||
- **対象**: Integer, Float, Bool定数
|
||||
- **テスト**: `return 100`, `return 3.14`, `return true`
|
||||
|
||||
### **Issue #003: 基本的な型システム**（#002と並行可能）
|
||||
- **期間**: Day 4-5
|
||||
- **内容**: MIR型→LLVM型のマッピング実装
|
||||
- **対象**: i32/i64, f64, bool, 関数型
|
||||
- **成果**: type_cache の実装
|
||||
|
||||
### **Issue #004: ランタイム関数宣言**（#003完了後）
|
||||
- **期間**: Day 5-6
|
||||
- **内容**: nyash_runtime_* 関数の宣言
|
||||
- **対象**: alloc, free, print_int（デバッグ用）
|
||||
- **準備**: 最小限のCランタイム作成
|
||||
|
||||
### **Issue #005: Week 1統合テスト**（最終日）
|
||||
- **期間**: Day 7
|
||||
- **内容**: 複数の小さなプログラムでテスト
|
||||
- **確認**: CI/CDでのLLVMビルド
|
||||
- **文書**: Week 2への引き継ぎ事項
|
||||
|
||||
## 🔄 実装の流れ
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Issue #001<br/>環境構築] --> B[Issue #002<br/>Const実装]
|
||||
A --> C[Issue #003<br/>型システム]
|
||||
B --> D[Issue #004<br/>ランタイム]
|
||||
C --> D
|
||||
D --> E[Issue #005<br/>統合テスト]
|
||||
```
|
||||
|
||||
## ✅ Week 1完了時のチェックリスト
|
||||
|
||||
- [ ] inkwellクレートが正常に動作
|
||||
- [ ] 「return 42」がLLVM経由で実行可能
|
||||
- [ ] Integer/Float/Bool定数がサポート済み
|
||||
- [ ] 基本的な型変換が実装済み
|
||||
- [ ] 最小限のランタイム関数が宣言済み
|
||||
- [ ] 5個以上のテストケースがパス
|
||||
|
||||
## 📊 リスクと対策
|
||||
|
||||
| リスク | 対策 |
|
||||
|--------|------|
|
||||
| LLVM環境構築で詰まる | Docker環境を準備、LLVM17固定 |
|
||||
| inkwellのAPIが複雑 | 公式exampleを参考に最小実装 |
|
||||
| リンクエラー | まずは静的リンク、動的は後回し |
|
||||
|
||||
## 💡 成功のコツ
|
||||
|
||||
1. **小さく始める**: return 42が動けば大成功
|
||||
2. **エラーを恐れない**: LLVMのエラーメッセージは親切
|
||||
3. **IR出力を確認**: `--emit-llvm`でIRをダンプして確認
|
||||
4. **既存コード活用**: VM/WASMバックエンドの構造を参考に
|
||||
|
||||
## 🎉 Week 1成功時の次のステップ
|
||||
|
||||
**Week 2では以下に取り組みます**：
|
||||
- BinOp（四則演算）の実装
|
||||
- Branch/Jumpによる制御フロー
|
||||
- Box型の基本操作
|
||||
- PHIノードの実装
|
||||
|
||||
---
|
||||
|
||||
**注意**: 各Issueは独立して実装可能ですが、推奨順序に従うとスムーズです。
|
||||
ブロッカーがあれば即座にAIチームに相談してください！
|
||||
Reference in New Issue
Block a user