hakorune/docs/development/roadmap/phases/phase-15/implementation/abi-migration-timing.md

ABI移行タイミング詳細検討

🎯 現状分析

現在のTypeBox実装

• TLVベース統一 - invoke_idですべてのメソッド呼び出し処理
• 7つのプラグイン - String/Integer/Array/Map/Console/File/Egui
• 問題なく動作 - 機能的には十分、パフォーマンスも実用レベル

LLVM層の進捗

• ChatGPT5がLLVM実装改善中
• PHI/ターミネーター問題を解決中
• BuilderCursor導入で構造化
• EXE生成までもう少し

🔄 移行オプション検討

Option 1: 今すぐ移行開始

メリット：

• プラグイン数が少ない（7個）今がチャンス
• 早期のパフォーマンス改善
• 技術的負債を早めに解消
• Phase 16に向けた準備

デメリット：

• LLVM作業と並行→リソース分散
• 優先度の問題（LLVM > ABI？）
• 現行で問題ないのに変更リスク

Option 2: LLVM完成後に移行（推奨）✅

メリット：

• 集中できる - まずLLVM完成に全力
• 最適化考慮 - LLVM/JITの特性を踏まえた設計
• 一度の変更 - まとめて最適な形に
• 実証データ - LLVM性能を見てから判断

デメリット：

• 移行が遅れる（でも急ぐ必要ない）
• TLVオーバーヘッド継続（でも実用上問題なし）

Option 3: 段階的準備

今できること：

1. struct_size活用コードの準備
2. ドキュメント整理（完了✅）
3. 拡張計画の詳細化
4. テストコード準備

LLVM後にやること：

1. create/destroy追加
2. プラグイン順次対応
3. パフォーマンス測定
4. 最適化

📊 判断基準

なぜLLVM完成後が最適か

1. 優先度の明確化

   • 現在の最重要課題：セルフホスティング
   • LLVM完成 → EXE生成 → セルフホスト実現
   • ABIは「改善」であって「必須」ではない

2. 設計の最適化

   • LLVMの最適化特性を理解してから
   • インライン化可能性の考慮
   • JIT/AOTでの扱いの違い

3. リスク管理

   • 動いているものを変えるリスク
   • LLVM作業への影響を避ける
   • 一度に大きく変える方が安全

4. 実装効率

   • ChatGPT5がLLVM集中できる
   • 混乱を避ける
   • 明確なマイルストーン

🚀 推奨ロードマップ

Phase 15（現在）

1. LLVM完成に集中
2. EXE生成実現
3. セルフホスト基盤確立
4. ABI拡張の詳細設計（並行）

Phase 15.5（LLVM完成直後）

1. ABI拡張実装
   • create/destroy追加
   • struct_size活用
   • 互換性維持
2. プラグイン移行
   • 性能重要なものから
   • 段階的に対応
3. パフォーマンス検証

Phase 16（次フェーズ）

1. ABI安定化宣言
2. 外部開発者向けドキュメント
3. 他言語バインディング

🎯 結論

LLVM完成後の移行が最適

理由：

1. 現在のTLVベースで機能的問題なし
2. LLVM完成が最優先（セルフホストへの道）
3. 最適化知見を活かした設計可能
4. リスク最小化・効率最大化

ただし準備は今から：

• ドキュメント整理（完了✅）
• 設計詳細化
• テスト準備
• 移行計画策定

これにより、LLVM完成後にスムーズに移行開始できる。