- 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>
4.8 KiB
4.8 KiB
📋 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: 環境セットアップ
# Cargo.toml
[dependencies]
inkwell = { version = "0.5", features = ["llvm17-0"] }
- inkwellクレート導入
- LLVMコンテキスト初期化
- 基本的なモジュール生成
Day 3-4: 最小命令実装
// 実装対象
- 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: 算術演算と制御フロー
// 実装対象
- BinOp (Add/Sub/Mul/Div)
- Compare (Eq/Ne/Lt/Le/Gt/Ge)
- Branch/Jump
- PHI nodes
Day 11-13: Box型MVP
// 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: 最適化パス
// 基本最適化
- mem2reg (alloca → SSA)
- instcombine (命令結合)
- reassociate (結合則)
Day 17-18: ベンチマーク
# 性能測定対象
- フィボナッチ数列
- 素数判定
- 簡単な数値計算ループ
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
pub struct CodegenContext<'ctx> {
context: &'ctx Context,
module: Module<'ctx>,
builder: Builder<'ctx>,
target_machine: TargetMachine,
type_cache: HashMap<MirType, BasicTypeEnum<'ctx>>,
}
MIR→LLVM変換器
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倍以上高速
定性的指標
- コードの保守性(他の開発者が理解可能)
- エラーメッセージの有用性
- 将来の拡張可能性
🚀 開始準備チェックリスト
- VM性能改善完了(50.94倍達成!)
- AI大会議による戦略確定
- Copilotへの正式依頼
- 開発環境準備(LLVM17インストール)
- Week 1タスクのGitHub Issue作成
📝 参考資料
承認者: moe-charm
実装担当: Copilot + AIチーム
レビュー: Phase 9.78完了時