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
@ -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