Files

Moe Charm 11506cee3b Phase 11-12: LLVM backend initial, semantics layer, plugin unification

Major changes:
- LLVM backend initial implementation (compiler.rs, llvm mode)
- Semantics layer integration in interpreter (operators.rs)
- Phase 12 plugin architecture revision (3-layer system)
- Builtin box removal preparation
- MIR instruction set documentation (26→Core-15 migration)
- Cross-backend testing infrastructure
- Await/nowait syntax support

New features:
- LLVM AOT compilation support (--backend llvm)
- Semantics layer for interpreter→VM flow
- Tri-backend smoke tests
- Plugin-only registry mode

Bug fixes:
- Interpreter plugin box arithmetic operations
- Branch test returns incorrect values

Documentation:
- Phase 12 README.md updated with new plugin architecture
- Removed obsolete NYIR proposals
- Added LLVM test programs documentation

Co-Authored-By: Claude <noreply@anthropic.com>

2025-09-01 23:44:34 +09:00

3.6 KiB

Raw Blame History

🚨 AI議論の誤解：存在しない問題を解決しようとした記録

誤解の本質

この文書は、AIたちが「スクリプトプラグイン」という存在しない問題を作り出し、複雑な解決策を提案した記録です。

実際の事実

Nyashスクリプト = 普通のユーザー定義Box
ユーザー定義Boxは既に完璧に動作している
特別な仕組みは一切不要

なぜこんな誤解をしたのか

「プラグイン」という言葉に引っ張られて、C ABIの外部DLLのような特別な仕組みが必要だと思い込んでしまった。

現実のフロー:
MIR → JIT → C関数呼び出し（固定アドレス）→ ネイティブコード実行
MIR → AOT → EXE内のC関数（静的リンク）→ ネイティブコード実行

不可能なフロー:
MIR → ??? → Nyashスクリプト実行（インタープリター必要）

なぜスクリプトプラグインは動作しないのか

1. インタープリター依存

// スクリプトプラグイン
export box CustomMath {
    sin(x) { return me._math.sin(x) }
}

↓ 実行にはNyash VMが必要 → EXEに埋め込めない

2. 動的型システム

C ABI: 静的型（i32, i64, double等）
Nyashスクリプト: 動的型（Box）
型変換にはランタイムが必要

3. メモリ管理

C ABI: 手動管理またはシンプルなGC
Nyashスクリプト: Arc<Mutex>
GC/参照カウント管理にランタイムが必要

実例：なぜFileBoxはC ABIなのか

// FileBoxプラグイン（ネイティブ）
#[no_mangle]
pub extern "C" fn nyash_plugin_invoke(...) -> i32 {
    // 直接システムコール可能
    // VMなしで動作
    // EXEに静的リンク可能
}

対して、Nyashスクリプトは：

VM必須
動的評価
EXEに埋め込み不可

結論：Phase 12の方向転換が必要

❌ 不可能なこと

スクリプトプラグインをJIT/AOTから直接呼び出し
スクリプトプラグインをEXEに埋め込み
ネイティブプラグインと完全に透過的な利用

✅ 可能なこと

インタープリターモード限定
- スクリプトプラグインはインタープリター実行時のみ
- 開発/プロトタイピング用途
トランスパイル方式
- Nyashスクリプト → C/Rust → ネイティブプラグイン
- ビルドステップが必要
ハイブリッド実行
- 開発時: スクリプトプラグイン（高速イテレーション）
- 本番時: ネイティブプラグイン（高性能）

修正された価値提案

開発フローの改善

1. アイデア → Nyashスクリプトでプロトタイプ
2. 動作確認 → インタープリターでテスト
3. 性能要求 → Rust/Cで再実装
4. 配布 → ネイティブプラグインとして

制限事項の明確化

JIT/AOT: ネイティブプラグインのみ
インタープリター: スクリプトプラグインも可
EXE生成: ネイティブプラグインのみ含む

推奨アクション

Phase 12の再定義
- 「開発支援ツール」として位置づけ
- JIT/AOT統合は諦める
ドキュメント修正
- 制限事項を明確に記載
- 誤解を招く「透過的利用」を削除
代替案の検討
- Nyash→Rustトランスパイラー
- プラグインテンプレート生成ツール

重要な教訓：C ABIの制約は、システムプログラミングの本質的な制約である。

3.6 KiB Raw Blame History Unescape Escape