hakorune/docs/予定/native-plan/copilot_issues.txt

# 🤖 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調査 の順序
================================================================================