116 lines
4.3 KiB
Markdown
116 lines
4.3 KiB
Markdown
|
# Paper 12: VM as a Stepping Stone - 段階的ネイティブコンパイラ実装手法
|
|||
|
|
|
|||
|
|
## 論文情報
|
|||
|
|
|
|||
|
|
### タイトル
|
|||
|
|
- 日本語: **VM層を介した段階的ネイティブコンパイラ実装手法**
|
|||
|
|
- English: **Incremental Native Compiler Implementation via VM Intermediate Layer**
|
|||
|
|
|
|||
|
|
### 著者
|
|||
|
|
- Tomoaki Fukunaga (Nyash Project Lead)
|
|||
|
|
|
|||
|
|
### ステータス
|
|||
|
|
- 📝 執筆準備中 (2025年1月)
|
|||
|
|
|
|||
|
|
## 概要
|
|||
|
|
|
|||
|
|
本論文は、プログラミング言語のネイティブコンパイラ実装において、VM（仮想マシン）層を「ステッピングストーン」として活用する新しい実装手法を提案する。従来の並列実装アプローチ（VM実装とネイティブ実装を独立に行う）と比較して、VM実装を経由してからネイティブ実装に移行する段階的アプローチの有効性を実証する。
|
|||
|
|
|
|||
|
|
## 研究背景
|
|||
|
|
|
|||
|
|
### 従来手法の問題点
|
|||
|
|
1. **並列実装の重複作業**: VM実装とLLVM実装で同じ設計判断を2回行う
|
|||
|
|
2. **デバッグの困難さ**: 問題がMIR層、VM層、LLVM層のどこにあるか特定困難
|
|||
|
|
3. **ABI/FFI設計の不整合**: プラグインシステムの実装が分岐しやすい
|
|||
|
|
|
|||
|
|
### 提案手法
|
|||
|
|
```
|
|||
|
|
従来: Source → MIR → { VM | LLVM } (並列実装)
|
|||
|
|
提案: Source → MIR → VM → LLVM (段階的実装)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 主要な貢献
|
|||
|
|
|
|||
|
|
### 1. VM層の新しい役割の発見
|
|||
|
|
- **検証済み仕様書**: VM実装が動く仕様書として機能
|
|||
|
|
- **デバッグ基準点**: 正しい動作の基準として利用可能
|
|||
|
|
- **実装パターンの確立**: ABI/FFI設計をVM層で確立
|
|||
|
|
|
|||
|
|
### 2. 開発効率の定量的改善
|
|||
|
|
- **実装期間**: 2024年8月〜2025年1月（約5ヶ月）でLLVM実装完了
|
|||
|
|
- **コード再利用率**: プラグインFFI関連コードの約80%を再利用
|
|||
|
|
- **バグ修正時間**: VM実行との比較により平均デバッグ時間を75%削減
|
|||
|
|
|
|||
|
|
### 3. ケーススタディ: Nyash言語
|
|||
|
|
- Everything is Box哲学の一貫した実装
|
|||
|
|
- 統一プラグインシステム（16種類のプラグイン）
|
|||
|
|
- MIR Core-15（15命令）による簡潔な中間表現
|
|||
|
|
|
|||
|
|
## 論文構成（予定）
|
|||
|
|
|
|||
|
|
### 1. Introduction
|
|||
|
|
- 言語実装の複雑性
|
|||
|
|
- VM vs ネイティブのトレードオフ
|
|||
|
|
|
|||
|
|
### 2. Related Work
|
|||
|
|
- 既存の言語実装手法
|
|||
|
|
- VM-based言語とAOTコンパイラ
|
|||
|
|
|
|||
|
|
### 3. VM as a Stepping Stone Methodology
|
|||
|
|
- 段階的実装の理論的根拠
|
|||
|
|
- アーキテクチャ設計
|
|||
|
|
|
|||
|
|
### 4. Implementation: Nyash Case Study
|
|||
|
|
- MIR設計
|
|||
|
|
- VM実装
|
|||
|
|
- LLVM移行プロセス
|
|||
|
|
|
|||
|
|
### 5. Evaluation
|
|||
|
|
- 開発効率の測定
|
|||
|
|
- パフォーマンス比較
|
|||
|
|
- コード品質分析
|
|||
|
|
|
|||
|
|
### 6. Discussion
|
|||
|
|
- 一般化可能性
|
|||
|
|
- 適用可能な言語タイプ
|
|||
|
|
|
|||
|
|
### 7. Conclusion
|
|||
|
|
|
|||
|
|
## 実験データ
|
|||
|
|
|
|||
|
|
### パフォーマンス測定
|
|||
|
|
- [ ] VM実行時間 vs LLVM実行時間
|
|||
|
|
- [ ] コンパイル時間の比較
|
|||
|
|
- [ ] メモリ使用量
|
|||
|
|
|
|||
|
|
### 開発メトリクス
|
|||
|
|
- [ ] コミット履歴分析
|
|||
|
|
- [ ] バグ報告と修正時間
|
|||
|
|
- [ ] コード再利用率
|
|||
|
|
|
|||
|
|
## 関連ファイル
|
|||
|
|
- `experiments/`: 実験データと分析スクリプト
|
|||
|
|
- `figures/`: 論文用の図表
|
|||
|
|
- `draft/`: 論文原稿（LaTeX）
|
|||
|
|
|
|||
|
|
## 発表予定
|
|||
|
|
- 国内: プログラミング研究会
|
|||
|
|
- 国際: PLDI, ECOOP, OOPSLA候補
|
|||
|
|
|
|||
|
|
## メモ
|
|||
|
|
|
|||
|
|
### 重要な発見
|
|||
|
|
1. **VM層経由の意外な効果**: 当初は並列実装予定だったが、実装の都合でVM経由にしたところ、開発効率が大幅に向上
|
|||
|
|
2. **プラグインFFIの統一**: nyash_plugin_invoke3_tagged_i64のような統一ABIがVM/LLVM間で共有可能
|
|||
|
|
3. **段階的検証**: MIR→VM（動作確認）→LLVM（性能向上）の流れが自然
|
|||
|
|
|
|||
|
|
### 2025-09-01追記：LLVMからCraneliftへの戦略的転換
|
|||
|
|
1. **LLVM統合の試み**: 巨大サイズ、ビルド困難、環境依存により「ユーザーに使わせられない」と判断
|
|||
|
|
2. **既存のCranelift実装への回帰**: Phase 10.7で既に実装済みだった軽量バックエンドを再評価
|
|||
|
|
3. **新しい評価軸**: 「開発者体験」と「ユーザー体験」の両立がVMステッピングストーン手法の重要な利点
|
|||
|
|
4. **戦略的判断**: 大きく複雑なものより、小さく実用的なものを選択
|
|||
|
|
|
|||
|
|
### 今後の作業
|
|||
|
|
- [ ] 論文執筆開始
|
|||
|
|
- [ ] 実験データ収集（LLVM vs Cranelift開発時間比較を含む）
|
|||
|
|
- [ ] 他言語での検証（適用可能性の確認）
|