012fc1930f
- Extract Copilot's BID converter code to src/bid-converter-copilot/ for future use - Create comprehensive plugin migration request document for Copilot - Target 13 built-in boxes for plugin conversion (HTTP, GUI, Audio, etc.) - Preserve existing nyash.toml-based plugin system - Reorganize docs/説明書/reference/ structure for better organization
503 lines
20 KiB
Plaintext
503 lines
20 KiB
Plaintext
# 🤖 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調査 の順序
|
||
================================================================================
|