feat(plugin): Fix plugin BoxRef return and Box argument support
- Fixed deadlock in FileBox plugin copyFrom implementation (single lock) - Added TLV Handle (tag=8) parsing in calls.rs for returned BoxRefs - Improved plugin loader with config path consistency and detailed logging - Fixed loader routing for proper Handle type_id/fini_method_id resolution - Added detailed logging for TLV encoding/decoding in plugin_loader_v2 Test docs/examples/plugin_boxref_return.nyash now works correctly: - cloneSelf() returns FileBox Handle properly - copyFrom(Box) accepts plugin Box arguments - Both FileBox instances close and fini correctly 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Moe Charm
@ -0,0 +1,110 @@
|
||||
やったね！この粒度なら “化け物に伸びる余白” と “実装の現実” のちょうど真ん中。
|
||||
仕上げとして **25命令をキッチリ確定**＋**意味論/効果/検証ルール** を短く固めよう。
|
||||
|
||||
# 決定版 MIR（25命令）
|
||||
|
||||
## Tier-0: 普遍コア（8）
|
||||
|
||||
```
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
* 効果: `Const/Phi`=pure, `BinOp/Compare`=pure, `Branch/Jump/Return`=control, `Call`は呼先の効果に従う
|
||||
* 備考: 将来のJIT/AOT/WASMすべてで必須
|
||||
|
||||
## Tier-1: Nyashセマンティクス（12）
|
||||
|
||||
```
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み
|
||||
BoxFieldStore, // Boxのフィールド書き（= mut）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則の検証付き）
|
||||
WeakNew, // `weak` ハンドル生成（非所有リンクの作成）
|
||||
WeakLoad, // `weak` から生存チェック付きで強参照を得る（失効時null）
|
||||
WeakCheck, // `weak` の生存確認（bool）
|
||||
Send, // Bus送信（Effect=io）
|
||||
Recv // Bus受信（Effect=io）
|
||||
```
|
||||
|
||||
* 効果: `BoxFieldStore/RefSet`=mut, `Send/Recv`=io, 他は基本pure/可変
|
||||
* これで **所有森＋weak/look＋Bus** が言語一次市民として表現可能
|
||||
|
||||
## Tier-2: 実装補助・最適化友好（5）
|
||||
|
||||
```
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列の最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
* 位置づけ: どれも“言語仕様の裏方”。無くても表現可能だが、**性能・安全検査・移植性**が安定する
|
||||
|
||||
---
|
||||
|
||||
## 効果（Effect）既定値
|
||||
|
||||
* `pure`: Const, BinOp, Compare, Phi, WeakCheck, WeakLoad(成功時の取得自体はpure扱い)
|
||||
* `mut`: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
* `io`: Send, Recv, Safepoint(割り込み/分割fini許可点としてio扱い)
|
||||
* `control`: Branch, Jump, Return, TailCall
|
||||
* `context依存`: Call, BoxCall（呼先の効果に従属）
|
||||
|
||||
> 最適化ルールは「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」。
|
||||
|
||||
---
|
||||
|
||||
## 検証（Lint/Verifier）要件（短縮版）
|
||||
|
||||
* **所有森**: `strong in-degree ≤ 1`（`NewBox/Adopt/Release/RefSet`で常時検査）
|
||||
* **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
* **弱/強相互**: 双方向とも強 → エラー（片側は `WeakNew` 経由で弱化）
|
||||
* **RefSetの安全**: 強→強の差し替え時は旧所有元からの `Release` が伴うこと
|
||||
* **WeakLoad/WeakCheck**: 失効時は `null/false` を返す（例外禁止、決定的挙動）
|
||||
* **TailCall**: 末尾位置のみ可（`Return` 直前）
|
||||
* **Send/Recv**: バックエンドが同期/非同期いずれでも**at-least-once**契約を満たすか、契約を明示
|
||||
|
||||
---
|
||||
|
||||
## 代表的ロワリング（例）
|
||||
|
||||
* `look` 参照 → `WeakNew` + `WeakLoad`（読取専用型なら `RefSet` を禁止）
|
||||
* `borrow{}` → ブロック先頭 `WeakNew`、末尾でハンドル破棄（MIR上はNop、型で書換禁止）
|
||||
* Bus最適化（Elision）:
|
||||
|
||||
* `(pure|mut(local))` かつ同一スレッド/アリーナ/単一受信なら **`Send/Recv` → 直呼び/直アクセス** に縮退
|
||||
* `fini` 伝播: ランタイムで **強エッジのみ** 再帰。`Safepoint` で分割解放/優先度解放に対応
|
||||
|
||||
---
|
||||
|
||||
## バックエンド指針（対応表）
|
||||
|
||||
* **Interpreter**: 25命令を素直に実装（正しさの基準）
|
||||
* **VM**: Register-VM + direct-threading。`Send/Recv` はローカル判定時にインライン化
|
||||
* **WASM**: `Send/Recv` は host import。`MemCopy` は `memory.copy` に対応
|
||||
* **Cranelift/JIT**: `TailCall` 最適化、`WeakLoad` は世代タグでO(1)生存チェック
|
||||
* **AOT-Rust**: `BoxCall` を trait 呼び出しへ、`Adopt/Release` は所有者IDの切替 + デバッガ用アサート
|
||||
|
||||
---
|
||||
|
||||
## 互換テスト（常設）
|
||||
|
||||
* **golden MIR**: 各サンプルのMIRダンプが全バックエンドで一致
|
||||
* **行動一致**: `interp/vm/wasm` で**同入力→同出力**（`weak`失効時の`null/false`含む）
|
||||
* **性能スモーク**: `add_loop / map_getset / alloc_free / bus_local / bus_actor` の5種で、
|
||||
|
||||
* VMがinterp以上、WASMがVM以上、を継続検証
|
||||
|
||||
---
|
||||
|
||||
これで **25命令フルセット**が完成。
|
||||
|
||||
* Nyashのコア価値（所有森＋weak＋Bus＋効果注釈）を**無理なくIR化**
|
||||
* それぞれのバックエンドに**綺麗に落ちる**
|
||||
* Verifier/最適化/テストも**最小で回る**
|
||||
|
||||
次は、このリストをそのまま `docs/mir.md` にコピペして、各命令に **1行の意味論＋効果＋等価変換の例** を添えれば、実装と論文の両方が一気に前進するにゃ。
|
||||
@ -0,0 +1,596 @@
|
||||
ぜったいアリにゃ！やるなら「多層エンジン（tiered）」で攻めるのが一番きれい。
|
||||
Nyash → 共通IR → 好きなバックエンド（解釈/ネイティブ/JIT/WASM）に流す構成にゃ。
|
||||
推しアーキテクチャ（現実解）
|
||||
|
||||
Front-end
|
||||
|
||||
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）
|
||||
|
||||
Back-ends（並行に育てる）
|
||||
|
||||
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
|
||||
|
||||
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
|
||||
|
||||
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
|
||||
|
||||
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行）
|
||||
|
||||
ひとつのIRから複数出力＝最適化ロジックを1か所に集中できるのが最大の利点。
|
||||
|
||||
【Phase 0: 最小ビルド基盤（最初のゴール）】
|
||||
|
||||
狙い: 「簡単なNyash言語がビルドできる」を最速・堅実に達成する。土台はシンプルだが確実に動くことを最重視。
|
||||
|
||||
1) スコープ（最小言語機能）
|
||||
- 式: 整数/文字列リテラル、変数参照、二項演算 (+,-,*,/, 比較)
|
||||
- 文: 代入、if、return
|
||||
- 関数: 単純な関数定義/呼び出し（可変長やジェネリクスは対象外）
|
||||
- Box/弱参照/fini 等の高機能はPhase 0では“使わない”（この計画の安定化が目的）
|
||||
|
||||
2) ビルドターゲット（まずはCLIのみ）
|
||||
- Linux/WSL: cargo build --bin nyash -j 32（現状OK）
|
||||
- Windows (MSVC): cargo build --bin nyash -j 32（CIでも検証）
|
||||
- WASM: ひな型を残すがPhase 0では対象外（Phase 1で着手）
|
||||
|
||||
3) 実行確認（スモークテスト）
|
||||
- サンプル: local_tests/ 以下に簡単な .nyash を配置（Git管理外）
|
||||
例) sample_min.nyash
|
||||
a = 10
|
||||
b = 32
|
||||
result = a + b
|
||||
- 実行: cargo run -- ./local_tests/sample_min.nyash
|
||||
- 期待: 実行完了・エラーなし（必要なら結果表示）
|
||||
|
||||
4) 再現性/安定性（基礎をしっかり）
|
||||
- rust-toolchain を固定（stable明記）
|
||||
- Linux/Windows 共通のビルドフラグ: release/profileの統一、features最小化
|
||||
- 例やGUI/Windows依存コードはCIマトリクスから除外（CLI最小に絞る）
|
||||
|
||||
5) CI（Phase 0の完成条件）
|
||||
- ジョブ: linux-x64, windows-x64 での “build nyash (bin)”
|
||||
- コマンド: cargo build --bin nyash -j 32
|
||||
- 成果物: nyash バイナリ（zip/tar）をArtifactsに保存（配布検証）
|
||||
- 余裕があれば: cargo test --lib だけ実行（examplesは無効）
|
||||
|
||||
6) トラブル防止（Phase 0の運用）
|
||||
- Linux CIでWindows専用exampleはビルド対象から除外
|
||||
- examples/* はPhase 0では“参考”扱い。CLIのビルド/実行に集中。
|
||||
- .nyash の共有が必要なものは tests/ 配下へ昇格（local_tests/ は各自ローカル）
|
||||
|
||||
7) 完了チェックリスト
|
||||
- [ ] Linux/WSL で nyash バイナリがビルド・実行できる
|
||||
- [ ] Windows(MSVC) で nyash バイナリがビルド・実行できる
|
||||
- [ ] CI で linux/windows の “build nyash (bin)” がグリーン
|
||||
- [ ] sample_min.nyash のスモークが両OSで通る
|
||||
|
||||
補足: Phase 0 で「ビルド/実行の骨格」を固めて、Phase 1 以降で VM/IR/JIT/AOT/WASM を段階的に拡張する。
|
||||
|
||||
それぞれのメリデメ
|
||||
|
||||
【MIR設計（早期に合意しておくと得する要点）】
|
||||
|
||||
- 値表現: Tagged/NaN-box/小整数直格納 か 型テーブル参照か
|
||||
- アドレス空間: ヒープ/スタック/アリーナの扱い（Phase 0はヒープ優先でOK）
|
||||
- 所有/別名: aliasable/unique の属性を型/値に保持（最初は型情報だけでも可）
|
||||
- 効果(Effects): PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令・関数に付与
|
||||
- 例外/パニック: Throw/Catch/Defer を命令化するか、関数境界に限定するか（当面は境界限定）
|
||||
- GCモデル: Tracing/RC/混合の方針と弱参照の意味（WeakLoad→None）
|
||||
- セーフポイント: 関数入口・ループ先頭・Call直後（命令としてno-op挿入で開始）
|
||||
- 呼出規約: 通常Call/FFI/Box拡張を区別、可変長/キーワード引数の扱い（Phase 0は固定引数）
|
||||
- メモリバリア: write/read barrier は命令/属性で表現（初期はダミー実装で可）
|
||||
- デオプ(Deopt): JIT最適化時の巻き戻し情報の格納場所（関数メタ or ブロック注釈）
|
||||
|
||||
【Nyash向け 最小MIR命令セット（弱参照対応込み・ドラフト）】
|
||||
|
||||
- 制御/値: Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
- 呼び出し: Call, TailCall（effects必須）
|
||||
- メモリ: Alloc, Load, Store, Gep(必要なら)
|
||||
- 参照/GC: RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
|
||||
- 例外/拡張: Throw, Catch, FfiCall, BoxCall
|
||||
- 実行点: Safepoint, Assume, Nop
|
||||
- 効果: EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
|
||||
|
||||
弱参照の意味論:
|
||||
- WeakNew(r): r を追う弱参照を作成（PURE）
|
||||
- WeakLoad(w): 生きていれば Some(Ref)、死んでいれば None（Option<Ref>を型で明示）
|
||||
|
||||
【壊れにくい共通ポイント（VM/JIT/AOT共通の約束）】
|
||||
- Safepoint は 関数入口/ループ先頭/Call直後 に配置（no-opで開始し、後で意味付け）
|
||||
- Barrier 命令は最初はダミー（最適化段で消せる）
|
||||
- Null/None は Option<Ref> で明示（分岐に埋めない）
|
||||
- JIT は Deopt テーブルで SSA値⇔ソース位置 の対応を保持
|
||||
|
||||
【弱参照の落とし穴（回避策セット）】
|
||||
- クロージャ環境: 生成時 env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制
|
||||
- 弱参照キーのハッシュ: GC後の無効化で不整合→ 標準の弱マップ（キー死亡で自動削除）を用意
|
||||
- FFI渡し: 寿命不明→ Pin を要求 or WeakLoad 成功した生参照のみ渡す
|
||||
|
||||
【テスト戦略（壊れにくい順）】
|
||||
- 黄金テスト: ソース→MIRダンプをスナップショットし、差分で後退検知
|
||||
- VM/JIT一致テスト: 同一入力の VM 結果＝JIT 結果 を比較するオラクル
|
||||
- 弱参照の確率テスト: alloc→weak→drop→collect→weak_load の順序/タイミングをゆらして多数回
|
||||
- 効果チェック: PURE なはずの関数に WRITES_HEAP が混じったらビルド失敗（静的検証）
|
||||
|
||||
【軽量 “次の一手”（Phase 0と親和性が高い）】
|
||||
- WeakNew/WeakLoad を MIRとVM に先に導入（JITは後回し）
|
||||
- EffectMask をデータ構造として追加（評価は後回しでもOK）
|
||||
- Safepoint 命令を関数入口・ループ先頭にno-opで挿入
|
||||
- 黄金テストでMIRダンプをCIに可視化（Phase 0のCLIビルドと併走）
|
||||
|
||||
VM：実装が速い／デバッグ容易｜最高速は出ない
|
||||
|
||||
Cranelift JIT：実行時最適化で爆速／実装難度は中｜起動コストあり
|
||||
|
||||
AOT→Rust：rustc最適化の恩恵・配布しやすい｜コード生成器の保守が要る
|
||||
|
||||
WASM：移植性・安全｜ネイティブよりは遅め（ただしwasmtime/wasmerで結構速い）
|
||||
|
||||
まずやる順序（最短で“速い”を得る）
|
||||
|
||||
共通MIR/SSAを切る（基本ブロック・SSA・型/効果情報）
|
||||
|
||||
VMを MIR→バイトコード に置き換え（インタープリターの土台を共通化）
|
||||
|
||||
Cranelift JIT を載せる（ホット関数だけJIT）
|
||||
|
||||
並行で Rustコード生成 の雛形を作る（AOT配布の道を確保）
|
||||
|
||||
余力で WASM 出力（エディタ内実行やブラウザデモに最適）
|
||||
|
||||
Nyash流にハマる設計ポイント
|
||||
|
||||
Box拡張のABIを先に決める
|
||||
|
||||
呼出規約：fn nyash_box_call(ctx: &mut Ctx, args: &[Val]) -> Result<Val>
|
||||
|
||||
メモリ：Arc<[Val]> か Arena で一時領域を明示（GCを後回しにできる）
|
||||
|
||||
所有権/借用に似た効果注釈をMIRに入れる
|
||||
|
||||
「純粋」「可変」「外部副作用あり」をフラグ化→最適化と並列実行の判断に使える
|
||||
|
||||
定数畳み込み/死コード除去/インライン化はMIR段階で実施
|
||||
|
||||
プロファイラを最初から同梱（どの関数をJIT/AOTに送るか判定）
|
||||
|
||||
最小プロトタスク（1〜2週間スプリント想定）
|
||||
|
||||
HIR/MIRスキーマ確定（基本ブロック・命令セット・型表現）
|
||||
|
||||
MIR→バイトコード変換器／VMループの実装
|
||||
|
||||
プロファイル計測（関数実行回数・時間）
|
||||
|
||||
Craneliftで fn 単位JIT（整数演算と分岐から）
|
||||
|
||||
簡易 Rustコード生成（fn add(a:i64,b:i64)->i64 などから）
|
||||
|
||||
Box ABI v0（同期版）＋サンプル拡張（数値/文字列ユーティリティ）
|
||||
|
||||
ちょいサンプル（超概念）
|
||||
|
||||
enum MirInst {
|
||||
Const(ValId, ConstVal),
|
||||
BinOp(ValId, ValId, Op, ValId),
|
||||
Call(ValId, FuncId, Vec<ValId>),
|
||||
Phi(ValId, Vec<(BlockId, ValId)>),
|
||||
// ...
|
||||
}
|
||||
struct MirFunc { blocks: Vec<MirBlock>, signature: Sig, effects: Effects }
|
||||
|
||||
trait Backend {
|
||||
fn compile(&mut self, f: &MirFunc) -> CompiledFn;
|
||||
}
|
||||
|
||||
VM backend: compile = バイトコード化
|
||||
|
||||
JIT backend: compile = Cranelift IR生成→jit_func
|
||||
|
||||
Rust backend: compile = fn ... { ... } のRust文字列出力→rustcでAOT
|
||||
|
||||
「いまのNyashソース」を見れたら、MIR命令セットの初版とJIT/AOTの足場コードをすぐ書き起こせるよ。
|
||||
まずは MIRの最小命令リストを一緒に決めよっか？（算術・比較・分岐・Call・Phi・Load/Store 相当）
|
||||
あなた:
|
||||
くわしくききたにゃ Front-end
|
||||
|
||||
パーサ → AST → HIR（型付け・名前解決済み）→ MIR/SSA（最適化しやすい共通IR）パーサーで解析してＡＳＴは木構造だよね？ そこからどういう処理にゃ？
|
||||
ChatGPT:
|
||||
|
||||
いいね、その流れを実務目線でがっつり分解するにゃ。
|
||||
キーワードは「情報を徐々に確定させつつ“最適化しやすい形”へ落としていく」。
|
||||
Nyash流に当てはめて、各段階で“何を追加・削除・変換するか”を整理するよ。
|
||||
Front-end 全体像
|
||||
|
||||
ソース → Lexer → Parser(AST) → スコープ/名前解決 → 型推論/型検査(HIR) → 糖衣剥がし(Desugar) → 制御フロー化(CFG) → SSA化/効果注釈(MIR/SSA)
|
||||
1) Parser → AST（抽象構文木）
|
||||
|
||||
目的：構文だけを正しく捉える。意味（型/名前）はまだ未確定。
|
||||
|
||||
データ構造（例）
|
||||
|
||||
enum AstExpr {
|
||||
LitInt(i64),
|
||||
Var(Symbol),
|
||||
Call{ callee: Box<AstExpr>, args: Vec<AstExpr> },
|
||||
Lambda{ params: Vec<AstParam>, body: Box<AstExpr> },
|
||||
If{ cond: Box<AstExpr>, then_e: Box<AstExpr>, else_e: Box<AstExpr> },
|
||||
Let{ pat: AstPat, init: Box<AstExpr>, body: Box<AstExpr> },
|
||||
// … match, while, for, block, …
|
||||
}
|
||||
|
||||
まだやらないこと
|
||||
|
||||
シンボルの多義性解決（foo がローカルか、モジュールか、メソッドか）
|
||||
|
||||
型の決定
|
||||
|
||||
糖衣構文の展開
|
||||
|
||||
2) スコープ構築 & 名前解決（AST上の解決）
|
||||
|
||||
目的：識別子を定義元に結びつける。未定義やシャドーイングもここで判定。
|
||||
|
||||
やること
|
||||
|
||||
ブロックスコープ/関数スコープ/モジュールスコープの**環境（symbol table）**を構築
|
||||
|
||||
use/import、module、with 的な構文を解決
|
||||
|
||||
各 Var(Symbol) を DefId（定義へのID）にひも付け
|
||||
|
||||
成果物：
|
||||
|
||||
解決済みAST or ここで HIR に写経（次段のために構造を少し整える）
|
||||
|
||||
3) 型推論 & 型検査 → HIR（型情報付きIR）
|
||||
|
||||
目的：式ごとに型を確定し、オーバーロード/ジェネリクスを具体化できる所まで進める。
|
||||
|
||||
型推論（Hindley–Milner＋制約ベースなど）
|
||||
|
||||
let x = 1 + f(y) なら、f: T -> i64 みたいな制約を立てて解く
|
||||
|
||||
オーバーロード解決 / メソッド解決（a + b → 実体メソッドやトレイト関数に解決）
|
||||
|
||||
ジェネリクス
|
||||
|
||||
可能ならモノモーフィック化（型実引数が確定している呼び出しは単相化）
|
||||
|
||||
未確定なら型パラ付きのまま保持
|
||||
|
||||
データ構造（例）
|
||||
|
||||
struct HirExpr {
|
||||
kind: HirExprKind,
|
||||
ty: TyId, // ここが肝：各式に型が付く
|
||||
effect: EffectMask, // 純粋/可変/外部副作用 など（後述の最適化で効く）
|
||||
}
|
||||
enum HirExprKind {
|
||||
LitInt(i64),
|
||||
Local(DefId),
|
||||
Call{ fun: Box<HirExpr>, args: Vec<HirExpr>, resolved: FunId },
|
||||
If{ cond: Box<HirExpr>, then_e: Box<HirExpr>, else_e: Box<HirExpr> },
|
||||
// 糖衣はまだ残っていてもOK
|
||||
}
|
||||
|
||||
エラー検出
|
||||
|
||||
型不一致、未初期化、到達不能、借用/所有に関する静的規則（Nyash流に簡易化しても良い）
|
||||
|
||||
4) 糖衣剥がし（Desugaring）
|
||||
|
||||
目的：意味は同じだが最適化しづらい構文を、プリミティブな形に落とす。
|
||||
|
||||
例
|
||||
|
||||
for x in iter { body } → let mut it = iter.into_iter(); while let Some(x) = it.next() { body }
|
||||
|
||||
a && b → if a { b } else { false }（短絡を明示化）
|
||||
|
||||
パターン束縛 let (a,b) = e; → 一時変数＋個別bind
|
||||
|
||||
クロージャ → 明示キャプチャ＋ラムダ表現を正規化
|
||||
|
||||
この段階で構文のバリエーションは減らして、後段のCFG/SSA化を楽にする
|
||||
|
||||
5) 制御フローグラフ（CFG）作成
|
||||
|
||||
目的：式主導（式木）を基本ブロック＋ジャンプへ落とす。
|
||||
最適化やSSA化の土台になる。
|
||||
|
||||
ブロック（BasicBlock）単位で命令列を持つ
|
||||
|
||||
例：if/else は br cond thenBB elseBB に分解
|
||||
while は loopBB / bodyBB / exitBB に分解
|
||||
|
||||
ここで**一時変数（tmp）**を導入して、「値がどのブロックから来るか」を明示できるようにする
|
||||
|
||||
6) SSA化（Static Single Assignment）
|
||||
|
||||
目的：各変数が“ちょうど一度だけ代入”される形に変換。
|
||||
最適化（定数畳み込み・コピー伝播・死コード除去・ループ最適化）がやりやすくなる。
|
||||
|
||||
φ関数（Phi）を導入
|
||||
分岐合流点で「どのブロックから来た値か」に応じて値を選ぶ
|
||||
|
||||
データ構造（MIR/SSA例）
|
||||
|
||||
enum MirInst {
|
||||
Const{ dst: V, c: ConstVal },
|
||||
BinOp{ dst: V, op: Op, a: V, b: V },
|
||||
Call{ dst: V, fun: FnId, args: Vec<V>, effects: EffectMask },
|
||||
Br{ cond: V, then_bb: Bb, else_bb: Bb },
|
||||
Jmp{ bb: Bb },
|
||||
Phi{ dst: V, inputs: Vec<(Bb, V)> },
|
||||
Store{ ptr: V, val: V }, // メモリ命令を分離しておくと最適化が楽
|
||||
Load{ dst: V, ptr: V },
|
||||
Ret{ v: Option<V> },
|
||||
}
|
||||
struct MirFunc { blocks: Vec<MirBlock>, sig: Sig, effects: EffectMask }
|
||||
|
||||
ここまでで最適化の主戦場が整う
|
||||
|
||||
7) 効果注釈（Effects）と簡易別解（所有/借用に近いもの）
|
||||
|
||||
目的：最適化・並列化・Box拡張の安全性判定に使う副作用情報を付与。
|
||||
|
||||
例：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC, THROW などのビットフラグ
|
||||
|
||||
呼び出し先の効果を合成して、関数単位の effects: EffectMask を確定
|
||||
→ 並列実行可否、共通部分式除去可否、コードモーション許可範囲に使える
|
||||
|
||||
8) 代表的な変換の“実例”で見る
|
||||
|
||||
Nyash（仮）：
|
||||
|
||||
let x = 10
|
||||
let y = 20
|
||||
if x < y {
|
||||
print(add(x, y))
|
||||
} else {
|
||||
print(y)
|
||||
}
|
||||
|
||||
AST（ざっくり）
|
||||
|
||||
Let(x, 10)、Let(y, 20)、If( BinOp(<, Var(x), Var(y)), Call(print, …), Call(print, Var(y)) )
|
||||
|
||||
HIR（型付け・解決済み）
|
||||
|
||||
x: i64, y: i64
|
||||
|
||||
add: (i64,i64)->i64, print: (i64)->Unit
|
||||
|
||||
Desugar
|
||||
|
||||
ほぼそのまま（ここでは糖衣なしと仮定）
|
||||
|
||||
CFG→SSA（MIRの一部）
|
||||
|
||||
bb0:
|
||||
v1 = Const 10
|
||||
v2 = Const 20
|
||||
v3 = BinOp Lt v1 v2
|
||||
Br v3 then=bb1 else=bb2
|
||||
|
||||
bb1:
|
||||
v4 = Call add(v1, v2) ; PURE
|
||||
Call print(v4) ; IO
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Call print(v2) ; IO
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret ()
|
||||
|
||||
（print は IO 効果、add は PURE、関数全体は IO を持つ、などが付与される）
|
||||
よくある疑問Q&A
|
||||
|
||||
Q. AST→HIRでどこまで“形を変える”？
|
||||
A. 基本は意味解決のための注釈（DefId, TyId, Effect）を付けるのが主。大きな形の変換（ループ展開やパターン展開）はDesugar段でやると見通しが良い。
|
||||
|
||||
Q. なんでSSA？バイトコードでも良くない？
|
||||
A. VM用のバイトコードは実行が簡単。でも最適化はSSAの方が圧倒的に楽。
|
||||
→ 「MIR/SSAで最適化」→「VM向けバイトコードに落とす」or「JIT/AOT」がおすすめ。
|
||||
|
||||
Q. パターンマッチは？
|
||||
A. Desugarで決定木（decision tree）に落としてからCFG化。ガード節や順序付きパターンも木→ブロック分割で表現できる。
|
||||
|
||||
Q. クロージャのキャプチャは？
|
||||
A. 名前解決で囲い込み変数を収集→HIRに明示キャプチャとして埋める。
|
||||
MIRでは環境レコードを値として扱う（{env_ptr, fn_ptr}）。
|
||||
まず作ると捗る“ミニ仕様”
|
||||
|
||||
Symbol/DefId/Scope：解決器のAPI
|
||||
|
||||
Ty：原始型・関数型・代数的データ型（Sum/Product）・型変数
|
||||
|
||||
EffectMask：ビットフラグ設計（PURE/READ/WRITE/IO/FFI など）
|
||||
|
||||
MIR命令セット（最小）：Const/BinOp/Call/Br/Jmp/Phi/Ret＋Load/Store
|
||||
|
||||
Pass順序：
|
||||
|
||||
名前解決 → 2) 型推論 → 3) Desugar → 4) CFG → 5) SSA → 6) 直近の最適化（const fold / dce / copy-prop）
|
||||
|
||||
必要なら、いまのNyashのAST型定義をベースにHIR/MIRの骨組みを一緒に設計するよ。
|
||||
|
||||
“最初のMIR命令セット案”
|
||||
|
||||
“名前解決テーブルと参照の貼り方”
|
||||
|
||||
“効果注釈のフォーマット”
|
||||
|
||||
この3点を固めるだけで、JIT/AOT/VMバックエンドの土台が一気に整うにゃ。
|
||||
あなた:
|
||||
おおう これと さっきの Back-ends（並行に育てる）
|
||||
|
||||
VM（現在のインタープリター）：MIR→バイトコード→解釈実行（開発スピード最優先）
|
||||
|
||||
JIT（Cranelift）：MIR→Cranelift IR→ネイティブJIT（ホットパスだけコンパイル）
|
||||
|
||||
AOT to Rust：MIR→Rustコード生成→rustcで最適化（配布バイナリ向き、リンクも楽）
|
||||
|
||||
WASM：MIR→WASM（ブラウザ/wasmtime用、サンドボックス実行） これの話要約してにゃ claude code君にみせてくるにゃ
|
||||
ChatGPT:
|
||||
|
||||
了解にゃ、Claude Code君向けに要点だけギュッとまとめるよ。
|
||||
Nyashコンパイルパイプライン案
|
||||
Front-end（共通部分）
|
||||
|
||||
Parser → AST
|
||||
|
||||
ソースを構文木（AST）に変換。型や意味はまだ未確定。
|
||||
|
||||
名前解決 & スコープ構築
|
||||
|
||||
識別子を定義元に紐付ける（DefId付与）。
|
||||
|
||||
型推論 & 型検査 → HIR
|
||||
|
||||
各式に型情報（TyId）と効果注釈（EffectMask）を付与。
|
||||
|
||||
糖衣剥がし（Desugar）
|
||||
|
||||
forループやパターン束縛をプリミティブ構造へ展開。
|
||||
|
||||
制御フロー化（CFG）→ SSA化（MIR）
|
||||
|
||||
ASTを基本ブロックとSSA命令列（MIR）へ変換。
|
||||
|
||||
命令例：Const, BinOp, Call, Br, Jmp, Phi, Load, Store, Ret。
|
||||
|
||||
Back-end（並行開発可能）
|
||||
|
||||
VM（現行インタープリター）
|
||||
|
||||
MIR → バイトコード → 解釈実行（開発スピード優先）
|
||||
|
||||
JIT（Cranelift）
|
||||
|
||||
MIR → Cranelift IR → 実行時にネイティブコード化（ホットパスだけ）
|
||||
|
||||
AOT to Rust
|
||||
|
||||
MIR → Rustコード生成 → rustc最適化＆リンク → 配布可能なネイティブバイナリ
|
||||
|
||||
WASM出力
|
||||
|
||||
MIR → WASM（ブラウザ実行やサンドボックス用）
|
||||
|
||||
💡 ポイント
|
||||
|
||||
すべてのバックエンドは共通MIRを入力にするため、最適化は1か所で集約。
|
||||
|
||||
Box拡張もMIRレベルで統一呼び出し可能。
|
||||
|
||||
VMは開発・デバッグ用、JITは実行高速化、AOTは配布、WASMは移植性重視。
|
||||
|
||||
|
||||
Nyashは**「最初から最後までモジュール拡張が一貫して動く多層言語」**という珍しい立ち位置になるにゃ。
|
||||
|
||||
希望あれば、これ一般的なコンパイラ構成との比較表にして、Claude Code君がすぐ違いを理解できる形にまとめることもできるよ。
|
||||
どうする、作っちゃう？
|
||||
あなた:
|
||||
おねがいにゃー！
|
||||
ChatGPT:
|
||||
|
||||
了解にゃー！Claude Code君に渡しやすいよう、「一般的な構成 vs Nyash流（＋α）」比較表にギュッとまとめたよ。
|
||||
Nyash 設計：一般的な方法との比較
|
||||
観点 一般的なコンパイラ設計 Nyash（＋α）
|
||||
フロントエンド Parser → AST →（解決/型付け）→ IR Parser → AST → HIR（型/解決/効果）→ MIR/SSA（最適化前提）
|
||||
中間表現(IR) 単一IR or バイトコード中心 HIR/MIR二段構え、MIRはSSA＋効果注釈で最適化容易
|
||||
効果/副作用 多くは最適化時に暗黙扱い EffectMask（PURE/READ/WRITE/IO/FFI…）をMIRに明示し並列化・最適化の判断に使用
|
||||
拡張/FFI 後付けのFFI/プラグインが多い Box拡張を一級市民化。MIRレベルで統一コール形態を定義（VM/JIT/AOT/WASMで一貫）
|
||||
バックエンド VM→（後からJIT/AOT） VM/JIT（Cranelift）/AOT-to-Rust/WASMを最初から並行開発できるMIR設計
|
||||
実行戦略 単層（解釈 or JIT）になりがち Tiered：VMで即起動→ホットパスJIT→配布はAOT→ブラウザはWASM
|
||||
AOT配布 LLVM等のHPCルートが主 MIR→Rustコード生成→rustc最適化（ツールチェーン流用・リンク容易）
|
||||
ブラウザ/サンドボックス 別途WASM対応 MIR→WASMを標準ターゲット化（wasmtime/wasmer/ブラウザ即動作）
|
||||
最適化の主戦場 バイトコード最適化/バックエンド依存 MIR/SSAで集約最適化（const fold, DCE, copy-prop, inlining, loop opts）
|
||||
並列化の足場 後付け解析が多い 効果注釈×データ依存で安全な並列化やコードモーションを許可
|
||||
デバッグ/開発速度 VMが主、JITは後追い VMで素早く検証しつつ、同一MIRをJIT/AOTに供給（回収効率◎）
|
||||
配布/運用 ネイティブ or VM同梱 用途別に最適バイナリ（AOT）とスクリプタブル運用（VM）を両取り
|
||||
リスク/留意点 単純で保守容易 設計は強力だが初期定義が要（MIR命令/Effect設計、Box ABIを固める）
|
||||
補足：最小ロードマップ（実装順）
|
||||
|
||||
HIR/MIRの骨組み確定（命令セット・EffectMask・Box ABI v0）
|
||||
|
||||
**VM（MIR→バイトコード）**で先に全機能を回す
|
||||
|
||||
プロファイラ同梱（ホット関数をJIT/AOTに回す条件づけ）
|
||||
|
||||
Cranelift JIT（算術＋分岐→関数呼び出し→Box呼び出し）
|
||||
|
||||
AOT to Rust の雛形生成（小関数から）
|
||||
|
||||
余力で MIR→WASM（最小機能から）
|
||||
|
||||
この表ごと貼れば、Claude Code君も**「王道＋Nyashの差分」**を一目で把握できるはずにゃ。必要なら、MIR命令セット 初版案も続けて出すよ！
|
||||
あなた:
|
||||
mirまでできればかちなのにゃね。これって定番なのあるにやゃ？ 言語ごとにやっぱりちがうにゃ？
|
||||
ChatGPT:
|
||||
|
||||
そうにゃ、MIRまで作れれば言語設計はもう“勝ち”に近いにゃ。
|
||||
なぜかというと、MIRは「全バックエンドの共通土台」だから、
|
||||
一度そこまで作れば VM/JIT/AOT/WASM ぜんぶに展開できるにゃ。
|
||||
🔹 MIRは定番があるの？
|
||||
|
||||
完全な共通規格はない
|
||||
→ LLVM IR や WebAssembly のような「広く使われる IR」はあるけど、
|
||||
言語ごとに構文や型システムが違うから MIRはだいたい自作になる。
|
||||
|
||||
多くの言語は「MIR」じゃなくても似た段階を持ってるにゃ：
|
||||
|
||||
Rust → MIR（所有権/借用も反映されたSSA形式）
|
||||
|
||||
Swift → SIL
|
||||
|
||||
Go → SSA IR
|
||||
|
||||
Kotlin → Kotlin IR
|
||||
|
||||
Python（PyPy）→ Flow Graph → SSA IR
|
||||
|
||||
JavaScript（V8）→ Bytecode IR → TurboFan IR
|
||||
|
||||
🔹 言語ごとに違うポイント
|
||||
|
||||
型情報の粒度
|
||||
|
||||
RustのMIRは「型完全一致」必須。
|
||||
|
||||
Python系は動的型なので「型タグ＋ランタイム判定」入り。
|
||||
|
||||
命令セットの抽象度
|
||||
|
||||
LLVM IRはハード寄り（ポインタ/レジスタ操作あり）。
|
||||
|
||||
Rust MIRやKotlin IRは言語構造寄り（ループ/パターンマッチ命令など残す）。
|
||||
|
||||
所有権・副作用の扱い
|
||||
|
||||
Rust MIRは「所有権」も追跡する。
|
||||
|
||||
多くの言語は副作用は型ではなく命令属性で管理。
|
||||
|
||||
最適化の前提
|
||||
|
||||
一部は最適化前提で作る（SSA化必須）。
|
||||
|
||||
他は単にバックエンド入力の中間形式。
|
||||
|
||||
🔹 Nyashでのおすすめ方針
|
||||
|
||||
Rust MIRに近い構造を真似るのが安全
|
||||
|
||||
静的型の要素が入ってるので、AOTや最適化に有利
|
||||
|
||||
EffectMaskやBox拡張の情報も一緒に持たせられる
|
||||
|
||||
命令はなるべく 「言語仕様に沿った中間レベル」 にして、
|
||||
バックエンド変換時に低レベル化する
|
||||
|
||||
SSA化は最初からやる（後から入れるのは地獄）
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,657 @@
|
||||
# 🤖 Copilot様 作業予定・課題整理 (Phase 0-9.4 アーカイブ版)
|
||||
# Generated: 2025-08-14 (Git履歴から復元・更新)
|
||||
# Purpose: Claude×Copilot協調開発のための情報共有
|
||||
# Status: Phase 9.5より前のアーカイブ版（2025-08-15分割）
|
||||
|
||||
================================================================================
|
||||
🎯 次期最優先タスク (Phase 8.5以降)
|
||||
================================================================================
|
||||
|
||||
## 🚀 Phase 8.4完了報告 (2025-08-14)
|
||||
Status: ✅ 完了 (Copilot PR #56マージ済み)
|
||||
|
||||
### ✅ AST→MIR Lowering完全実装
|
||||
- User-defined Box: `box DataBox { init { value } }`
|
||||
- Object creation: `new DataBox(42)`
|
||||
- Field access: `obj.value`
|
||||
- Method calls: `c.increment()`
|
||||
- Delegation: `from Parent.greet()`
|
||||
- Static Main互換性維持
|
||||
|
||||
### 🧪 統合テスト結果（2025-08-14）
|
||||
- ✅ **AST→MIR**: 完全動作
|
||||
- ✅ **インタープリター**: 完全動作（結果30）
|
||||
- 🚨 **VM**: 動作するが結果が`void`（要修正）
|
||||
- 🚨 **WASM**: String constant未対応（Phase 8.5で解決）
|
||||
|
||||
### 📋 発見された課題
|
||||
- VM実行結果問題: BoxCall後の戻り値が正しく返らない
|
||||
- WASM対応不足: 複雑なMIR命令（String constant, BoxCall）に未対応
|
||||
- 次期Phase 8.5での25命令MIR階層化が必要
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🔧 Phase 8.5: MIR 26命令階層化（最優先）
|
||||
Status: ⭐ **CRITICAL**
|
||||
Priority: **最重要** (Phase 8.4完了直後の次期目標)
|
||||
|
||||
### 🎯 実装目標
|
||||
ChatGPT5 + AI大会議決定版26命令MIR実装（ExternCall追加）
|
||||
- 期間: 3週間
|
||||
- 効果: VM/WASM問題根本解決
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md`
|
||||
|
||||
### 📋 26命令セマンティック階層化
|
||||
**Tier-0: 普遍コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, BoxFieldLoad, BoxFieldStore, BoxCall, ExternCall, Safepoint,
|
||||
RefGet, RefSet, WeakNew, WeakLoad, WeakCheck, Send, Recv
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, Adopt, Release, MemCopy, AtomicFence
|
||||
```
|
||||
|
||||
### 🎯 期待される効果
|
||||
- **VM問題解決**: BoxCallの正しい実装で戻り値問題修正
|
||||
- **WASM対応**: 階層化により複雑MIR→単純WASM変換
|
||||
- **Everything is Box**: BoxFieldLoad/Storeで明確なBox中心設計
|
||||
- **JIT準備**: セマンティクス保持で高度最適化基盤確立
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善（緊急）
|
||||
Status: 🚨 **緊急**
|
||||
Priority: **High** (Phase 8.5完了後)
|
||||
|
||||
### 🚨 緊急問題
|
||||
**現状**: VM（119.80ms）< Interpreter（110.10ms）= 0.9倍の性能劣化
|
||||
**新問題**: VM BoxCall後の戻り値が`void`（Phase 8.4テストで発見）
|
||||
|
||||
### 📋 技術的課題
|
||||
- VM実行エンジンのプロファイリング
|
||||
- 命令ディスパッチ最適化（threaded code等）
|
||||
- レジスタベースVM化検討
|
||||
- メモリプール最適化
|
||||
- BoxCall実装修正（戻り値問題）
|
||||
|
||||
### 🎯 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- BoxCall戻り値の正常動作
|
||||
- MIR→VM変換時間の短縮
|
||||
|
||||
================================================================================
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Testing
|
||||
Status: 📋 **計画済み**
|
||||
Priority: **High** (Phase 8.5-8.6完了後)
|
||||
|
||||
### 🎯 実装目標
|
||||
kilo（テキストエディタ）実装によるfini/weak参照システム実証
|
||||
- 期間: 2週間
|
||||
- 詳細仕様: `/docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md`
|
||||
|
||||
### 📋 検証項目
|
||||
- 1000+オブジェクト管理テスト
|
||||
- 循環参照回避確認（weak参照）
|
||||
- fini()伝播の正確性確認
|
||||
- WASM環境での動作確認
|
||||
|
||||
================================================================================
|
||||
🗺️ Phase 0-14 全体ロードマップ (復元完了)
|
||||
================================================================================
|
||||
|
||||
## Phase 0: Stabilize native CLI build (Linux/Windows)
|
||||
|
||||
Summary:
|
||||
- CLIバイナリ nyash を最小構成で安定ビルド・実行できる状態にする。
|
||||
- examples/GUI をデフォルトのビルド対象から外し、開発の足場を固める。
|
||||
|
||||
Why:
|
||||
- 以降の MIR/VM/JIT 開発を素早く検証できる基盤づくり。
|
||||
|
||||
Scope:
|
||||
- Cargo の features で GUI/examples 等を切り分け、デフォルトは CLI 最小にする。
|
||||
- CLI オプションの動作点検（--dump-mir / --verify）。
|
||||
- ローカル実行導線を README に明記（docs/guides/how-to-build-native/README.md）。
|
||||
|
||||
Tasks:
|
||||
- Cargo.toml: examples/GUI を feature でガード（default は CLI 最小）。
|
||||
- ビルド検証: `cargo build --bin nyash`（Linux/Windows）。
|
||||
- 実行検証: `cargo run -- ./local_tests/sample.nyash`。
|
||||
- ドキュメント: 上記手順を how-to-build-native に追記/点検。
|
||||
|
||||
Acceptance Criteria:
|
||||
- Linux/Windows で `cargo build --bin nyash` が成功する。
|
||||
- `local_tests/` 配下の簡単な .nyash が実行できる。
|
||||
- 他 bin/examples が壊れていても `--bin nyash` だけで通る。
|
||||
|
||||
Out of Scope:
|
||||
- examples/GUI の修理・最適化。
|
||||
- JIT/AOT/WASM。
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/README.md
|
||||
- docs/nativebuild大作戦/chatgptネイティブビルド大作戦.txt（Phase 0）
|
||||
- CURRENT_TASK.md
|
||||
|
||||
Copilot Notes:
|
||||
- まずは features 分離と `--bin nyash` でビルドが通る状態を作る。README の手順確認まで含めて PR に反映。
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 1: Minimal MIR + VM backend (lowering + runner)
|
||||
|
||||
Summary:
|
||||
- AST → MIR の最小 lowering と、VM バックエンドでの実行を通す。
|
||||
|
||||
Scope:
|
||||
- MIR: Const, BinOp, Compare, Branch, Jump, Phi, Return の最小命令
|
||||
- Lowering: リテラル/二項演算/if/loop/return のみ
|
||||
- VM: 上記命令の最小実装
|
||||
|
||||
Tasks:
|
||||
- instruction.rs: 最小命令の定義
|
||||
- builder.rs: 上記 AST 範囲を lowering
|
||||
- vm.rs: 実装 + stats（命令数）
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が最小サンプルで期待通り
|
||||
- `--backend vm` で実行して結果一致
|
||||
|
||||
Out of Scope:
|
||||
- 例外/関数/Box 参照/弱参照
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 2: Control-flow coverage (if/else/loop/phi correctness)
|
||||
|
||||
Summary:
|
||||
- 制御フローの網羅と Phi の整合性検証を拡充。
|
||||
|
||||
Scope/Tasks:
|
||||
- if/else nested, loop with breaks, nested loops のスナップショット
|
||||
- Phi の入力ブロック/値の対応を Verifier で強化
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表制御フローの snapshot が安定し、verify も通る
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 3: Exceptions (throw/try/catch/finally) minimal lowering
|
||||
|
||||
Summary:
|
||||
- 例外機構の最小 lowering を導入（詳細設計は簡素）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Throw, TryBegin/TryEnd, Catch, FinallyBegin/End（最小）
|
||||
- builder.rs: try/catch/finally ノードの下ろし
|
||||
- VM: 例外伝播を最小で（未捕捉はエラー）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表 try/catch/finally のスナップショットと VM 実行
|
||||
|
||||
Out of Scope:
|
||||
- 例外の型体系、詳細な stack map
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 4: Functions and calls (BoxCall minimal)
|
||||
|
||||
Summary:
|
||||
- 関数呼び出し/BoxCall を最小導入（効果注釈は保守的）。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: Call, BoxCall（effects = READS_HEAP など保守）
|
||||
- builder.rs: FunctionCall/MethodCall の最小対応
|
||||
- VM: 呼び出し/戻り値
|
||||
|
||||
Acceptance Criteria:
|
||||
- 簡単な関数定義/呼び出しの MIR/VM が通る
|
||||
|
||||
Out of Scope:
|
||||
- 可変長/キーワード引数、FFI
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.0: Parser/AST stabilization for lowering
|
||||
|
||||
Summary:
|
||||
- lowering 対象 AST の表現ぶれを修正、安定化。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: If/Loop/Return/Assignment/Local などの統一
|
||||
- Parser: エラー復帰/スパン情報の見直し
|
||||
|
||||
Acceptance Criteria:
|
||||
- builder.rs の分岐がシンプル化、テストが安定
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.1: Control-flow edge cases + verifier hardening
|
||||
|
||||
Summary:
|
||||
- ブロック未終端/未到達/自己分岐等の検証強化でクラッシュ回避。
|
||||
|
||||
Scope/Tasks:
|
||||
- Verifier: 未終端ブロック検出、到達不能検出
|
||||
- Builder: Jump/Branch の生成前後の状態管理改善
|
||||
|
||||
Acceptance Criteria:
|
||||
- 不正ケースを含むスナップショット/verify が緑
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 5.2: Lowering for static box Main (BoxDeclaration → main body)
|
||||
|
||||
Summary:
|
||||
- static box Main { main() { ... } } を MirBuilder で受け、main() の body を Program として lowering する経路を実装。
|
||||
|
||||
Scope/Tasks:
|
||||
- AST: BoxDeclaration(is_static=true, name=Main) を検出 → main() を抽出
|
||||
- Lowering: body を Program に変換して既存経路に渡す
|
||||
- Tests: local_tests/mir_loop_no_local.nyash で dump/VM が通る
|
||||
|
||||
Acceptance Criteria:
|
||||
- `--dump-mir` が static Main サンプルで成功
|
||||
- `--backend vm` で実行成功
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase5_2_static_main_lowering.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 6: Box ops minimal (Ref/Weak + Barriers no-op)
|
||||
|
||||
Summary:
|
||||
- 参照/弱参照/バリア（no-op）を最小導入。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: RefNew/RefGet/RefSet/WeakNew/WeakLoad/BarrierRead/Write
|
||||
- Lowering: New/FieldAccess/MethodCall の最小対応
|
||||
- VM: 参照テーブル/weak テーブルで動作（fini 不変は維持）
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表サンプルで dump/VM/verify が通る
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase6_box_ops_minimal.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 7: Async model (nowait/await) in MIR
|
||||
|
||||
Summary:
|
||||
- nowait/await を MIR に導入し、現行 FutureBox と連携。
|
||||
|
||||
Scope/Tasks:
|
||||
- MIR: FutureNew/FutureSet/Await（スレッドベース）
|
||||
- Lowering: nowait→Future 作成、await→wait_and_get
|
||||
- VM: FutureBox 実装を利用
|
||||
|
||||
Acceptance Criteria:
|
||||
- 代表ケースで正しく並行実行→await 回収
|
||||
|
||||
References:
|
||||
- docs/guides/how-to-build-native/issues/phase7_async_mir.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## Phase 8: MIR→WASM codegen (browser/wasmtime; sandboxed; Rust runtime free)
|
||||
|
||||
Summary:
|
||||
- MIR から素の WebAssembly を生成し、ブラウザ/wasmtime（WASI）でサンドボックス実行する。
|
||||
- Rust はコンパイラ本体のみ。実行は純WASM＋ホストimport（env.print など）。
|
||||
|
||||
Scope/Tasks:
|
||||
- ABI/Imports/Exports 定義（exports: main/memory、imports: env.print(i32) 等の最小）
|
||||
- 線形メモリと簡易ヒープ（bump/自由リスト）
|
||||
- 命令カバレッジ（段階導入）: 算術/比較/分岐/loop/return/print、RefNew/RefSet/RefGet（Phase 6 整合）、Weak/Barrier はダミー
|
||||
|
||||
Acceptance Criteria:
|
||||
- wasmtime 実行で戻り値/print が期待通り（PoC1–2）
|
||||
- Ref 系がメモリ上で正しく動作（PoC2）
|
||||
- Weak/Barrier のダミー実装を含むWASMが生成・実行（PoC3）
|
||||
- CLI `--backend wasm` は未実装でもよいが、実装する場合は明瞭にエラーメッセージ/誘導
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/README.md（Phase 8 節）
|
||||
- docs/説明書/wasm/*（ユーザー向けメモ）
|
||||
|
||||
### Phase 8.3 完了状況 (2025-08-14)
|
||||
✅ Box操作WASM実装 (RefNew/RefGet/RefSet)
|
||||
✅ ベンチマークシステム統合 (13.5倍実行高速化実証)
|
||||
✅ CLI統合完了
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔧 Phase 8.4: AST→MIR Lowering完全実装 (最優先)
|
||||
|
||||
Summary:
|
||||
- ユーザー定義Box、フィールドアクセス等の未実装部分を完成
|
||||
- Phase 8.3のBox操作WASMを実際にテスト可能にする
|
||||
|
||||
Priority: **Critical** (現在の最優先事項)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 実装範囲
|
||||
- [ ] ユーザー定義Box: `box DataBox { init { field } }`
|
||||
- [ ] オブジェクト生成: `new DataBox()`
|
||||
- [ ] フィールドアクセス: `obj.field`
|
||||
- [ ] フィールド代入: `obj.field = value`
|
||||
- [ ] from構文: `from Parent.method()`
|
||||
- [ ] override構文: `override method() { ... }`
|
||||
|
||||
### 成功基準
|
||||
- Phase 8.3のBox操作WASMが実際に動作
|
||||
- test_wasm_box_ops.nyash が正常実行
|
||||
- ユーザー定義Boxの完全サポート
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧠 Phase 8.5: MIRセマンティック階層化（AI大会議決定版）
|
||||
|
||||
Summary:
|
||||
- 方針転換: ChatGPT5の20命令intrinsic戦略 → Gemini+Codex一致推奨の26命令階層化（ExternCall追加）
|
||||
- 理由: JIT/AOT最適化阻害・Everything is Box意味喪失・長期コスト増の問題判明
|
||||
- 二相ロワリング: 26命令維持パス（VM/JIT/AOT）+ 21+intrinsic降格パス（WASM/最小実装）
|
||||
|
||||
Priority: High (Phase 8.4完了後)
|
||||
Expected Duration: 3週間
|
||||
|
||||
### AI大会議分析結果
|
||||
**Gemini先生（理論）**: 「賢いコンパイラは、賢いMIRから生まれる」
|
||||
- RefNew/WeakLoadのintrinsic化は最適化機会を失う悪手
|
||||
- セマンティック階層化で意味保持が最適化の鍵
|
||||
|
||||
**Codex先生（実装）**: 二相ロワリング戦略が実用的最適解
|
||||
- 実装コスト: 5命令追加で10-20人日（intrinsic戦略より安い）
|
||||
- マイクロベンチ実測でパフォーマンス検証
|
||||
|
||||
### 確定版MIR（26命令）- ChatGPT5完全仕様 + ExternCall統合
|
||||
**Tier-0: 普遍的コア（8命令）**
|
||||
```mir
|
||||
Const, BinOp, Compare, Branch, Jump, Phi, Call, Return
|
||||
```
|
||||
|
||||
**Tier-1: Nyashセマンティクス（13命令）**
|
||||
```mir
|
||||
NewBox, // 強所有のBox生成（所有森のノード）
|
||||
BoxFieldLoad, // Boxのフィールド読み（Everything is Box核心）
|
||||
BoxFieldStore, // Boxのフィールド書き（mut効果）
|
||||
BoxCall, // Boxのメソッド呼び出し（動的/静的両方）
|
||||
ExternCall, // 外部ライブラリをBoxとして呼び出し（Universal Exchange）
|
||||
Safepoint, // 分割finiや割込み許可ポイント
|
||||
RefGet, // 参照（強/弱を問わず）を値として取得
|
||||
RefSet, // 参照の差し替え（所有規則検証付き）
|
||||
WeakNew, // weak ハンドル生成（非所有リンク作成）
|
||||
WeakLoad, // weak から生存チェック付きで強参照取得（失効時null）
|
||||
WeakCheck, // weak の生存確認（bool）
|
||||
Send, // Bus送信（io効果）
|
||||
Recv // Bus受信（io効果）
|
||||
```
|
||||
|
||||
**Tier-2: 実装補助・最適化友好（5命令）**
|
||||
```mir
|
||||
TailCall, // 末尾呼び出し（スタック節約）
|
||||
Adopt, // 所有移管: this が子を強所有に取り込む
|
||||
Release, // 強所有を解除（weak化 or null化）
|
||||
MemCopy, // 小さなメモリ移動（構造体/配列最適化フック）
|
||||
AtomicFence // 並行時の順序保証（Actor/Port境界で使用）
|
||||
```
|
||||
|
||||
### 二相ロワリング戦略
|
||||
- パスA: VM/JIT/AOT向け（26命令のまま最適化）
|
||||
- パスB: WASM/最小実装向け（26→21+intrinsic降格）
|
||||
- バックエンド能力に応じて最適形式選択
|
||||
|
||||
### 効果（Effect）システム（ChatGPT5設計 + ExternCall統合）
|
||||
- **pure**: Const, BinOp, Compare, Phi, RefGet, WeakNew, WeakLoad, WeakCheck
|
||||
- **mut**: BoxFieldStore, RefSet, Adopt, Release, MemCopy
|
||||
- **io**: Send, Recv, Safepoint, AtomicFence
|
||||
- **control**: Branch, Jump, Return, TailCall
|
||||
- **context依存**: Call, BoxCall, ExternCall（呼び先効果に従属・BID定義に基づく）
|
||||
|
||||
**最適化ルール**: 「pure同士の再順序化OK」「mutは同一Box/同一Fieldで依存保持」「ioは再順序化禁止」
|
||||
|
||||
### 検証（Verifier）要件
|
||||
- **所有森**: `strong in-degree ≤ 1`（NewBox/Adopt/Release/RefSetで常時検査）
|
||||
- **強循環禁止**: 強エッジのみ辿ってDAG（森）であること
|
||||
- **weak/強相互**: 双方向とも強 → エラー（片側はWeakNew経由で弱化）
|
||||
- **WeakLoad/WeakCheck**: 失効時はnull/falseを返す（例外禁止、決定的挙動）
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- **Tier-0/1実装**: Everything is Box哲学の完璧なIR化（BoxFieldLoad/Store核心）
|
||||
- **weak参照システム**: WeakNew/WeakLoad/WeakCheck三位一体実装
|
||||
- **所有移管**: Adopt/Release命令による安全で効率的なメモリ管理
|
||||
- **効果システム**: pure/mut/io/control効果の正確な実装とVerifier統合
|
||||
- **最適化フック**: TailCall/MemCopy/AtomicFenceの実装補助
|
||||
- **二相ロワリング**: 25命令維持パス + 20+intrinsic降格パス構築
|
||||
|
||||
### 成功基準
|
||||
- [ ] **26命令完全実装**: ChatGPT5仕様 + ExternCall統合の完璧な実装
|
||||
- [ ] **効果システム動作**: pure再順序化・mut依存保持・io順序保証
|
||||
- [ ] **Verifier動作**: 所有森・strong循環・安全性検証
|
||||
- [ ] **Golden MIRテスト**: 全バックエンドでMIR一致
|
||||
- [ ] **行動一致テスト**: 同入力→同出力（weak失効時null/false含む）
|
||||
- [ ] **性能要件**: VM≥Interpreter、WASM≥VM継続検証
|
||||
|
||||
### バックエンド指針（ChatGPT5設計 + ExternCall統合）
|
||||
- **Interpreter**: 26命令を素直に実装（正しさの基準）
|
||||
- **VM**: Register-VM + direct-threading。Send/Recvはローカル判定時にインライン化
|
||||
- **WASM**: Send/Recvはhost import。MemCopyはmemory.copyに対応
|
||||
- **JIT（将来）**: TailCall最適化、WeakLoadは世代タグでO(1)生存チェック
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/MIR仕様書.txt（ChatGPT5完全仕様）
|
||||
- docs/予定/native-plan/issues/phase_8_5_mir_25_instruction_specification.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🏎️ Phase 8.6: VM性能改善 (緊急)
|
||||
|
||||
Summary:
|
||||
- VMがインタープリターより遅い問題（0.9倍）を解決
|
||||
- MIR→VM実行の最適化でインタープリターを上回る性能へ
|
||||
|
||||
Priority: High (Phase 8.5完了後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### 問題分析
|
||||
**現状**: VM (119.80ms) < Interpreter (110.10ms)
|
||||
**推定原因**:
|
||||
- MIR変換オーバーヘッド
|
||||
- VM命令ディスパッチの非効率性
|
||||
- メモリ管理コスト
|
||||
|
||||
### 技術的アプローチ
|
||||
- [ ] VM実行エンジンのプロファイリング
|
||||
- [ ] 命令ディスパッチ最適化（threaded code等）
|
||||
- [ ] レジスタベースVM化検討
|
||||
- [ ] メモリプール最適化
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- VM実装のボトルネック特定
|
||||
- 効率的な命令ディスパッチ実装
|
||||
- スタックマシン vs レジスタマシン判断
|
||||
|
||||
### 成功基準
|
||||
- VM性能 > Interpreter性能（最低2倍目標）
|
||||
- MIR→VM変換時間の短縮
|
||||
- メモリ使用量の削減
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🧪 Phase 8.7: Real-world Memory Management Testing (ChatGPT協調設計)
|
||||
|
||||
Summary:
|
||||
- 実用アプリケーション開発によるNyashメモリ管理システムの実証テスト
|
||||
- finiシステム・weak参照の実用性を複雑なアプリケーションで検証
|
||||
|
||||
Priority: High (Phase 8.4-8.6完了直後)
|
||||
Expected Duration: 2週間
|
||||
|
||||
### Phase 8.7A: kilo（テキストエディタ）
|
||||
**技術的特徴**:
|
||||
- サイズ: <1k LOC（超小型、最初の成功体験）
|
||||
- メモリパターン: Editor -> (Rows -> Syntax) 木構造＋相互参照
|
||||
- ChatGPT設計: Editor削除でRows自動解放、逆参照をweak化
|
||||
|
||||
**実装範囲**:
|
||||
- [ ] Editor/Row/EditorState基本構造実装
|
||||
- [ ] weak参照による循環参照回避（`me.editor = weak editor_ref`）
|
||||
- [ ] fini()システムによる自動メモリ解放
|
||||
- [ ] 大量オブジェクト（1000+ Rows）管理テスト
|
||||
|
||||
**検証ポイント**:
|
||||
- [ ] Editor削除でRows自動解放確認
|
||||
- [ ] 相互参照でメモリリークなし確認
|
||||
- [ ] weak参照の自動null化確認
|
||||
- [ ] fini()伝播の正確性確認
|
||||
|
||||
### Phase 9.5予定: tiny-web-server（HTTPサーバ）
|
||||
**将来実装**（JIT実装後）:
|
||||
- 複雑度: 中〜高（Server -> Clients -> Requests並行処理）
|
||||
- I/O管理: ソケット・ファイルハンドルの確実解放
|
||||
- 同時接続・早期切断・例外経路でのfini伝播テスト
|
||||
|
||||
### 🤖 Copilot協力期待
|
||||
- 実用的なメモリ管理パターンの実装
|
||||
- weak参照構文の適切な使用
|
||||
- デバッグ支援機能（--debug-memory, --trace-weak）
|
||||
- WASM環境でのメモリ管理互換性
|
||||
|
||||
### 成功基準
|
||||
- [ ] 全テストケースでメモリリークなし
|
||||
- [ ] 循環参照でも正常解放確認
|
||||
- [ ] WASM実行でもメモリ管理正常
|
||||
- [ ] ベンチマーク性能劣化なし
|
||||
|
||||
### 期待される効果
|
||||
- Nyashメモリ管理システムの実用性実証
|
||||
- Everything is Box哲学の実用レベル確認
|
||||
- メモリ安全なプログラミングパターン確立
|
||||
|
||||
References:
|
||||
- docs/予定/native-plan/issues/phase_8_7_real_world_memory_testing.md
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🚀 Phase 9: AOT WASM実装（最優先）
|
||||
|
||||
Summary:
|
||||
- wasmtime compileによるAOT実行ファイル生成で確実なユーザー価値提供
|
||||
|
||||
Scope/Tasks:
|
||||
- `wasmtime compile` 統合実装
|
||||
- `--compile-native` / `--aot` CLI追加
|
||||
- 単一バイナリ梱包（`include_bytes!`）
|
||||
- 起動時間・配布サイズ最適化
|
||||
|
||||
Acceptance Criteria:
|
||||
- `nyash --compile-native app.nyash -o app.exe` 動作
|
||||
- 起動時間大幅短縮（JIT起動コスト除去）
|
||||
- 配布可能実行ファイル生成
|
||||
|
||||
Priority: **Critical** (Phase 8.6完了直後)
|
||||
Expected Duration: 2-3週間
|
||||
|
||||
### 技術的実装詳細
|
||||
🤖 Copilot協力期待:
|
||||
- wasmtime::Config統一実装
|
||||
- .cwasm生成・実行パイプライン
|
||||
- 互換性キー管理（CPU機能・wasmtimeバージョン）
|
||||
- パッケージング（単一バイナリ梱包）
|
||||
|
||||
### パフォーマンス目標
|
||||
- 現在のWASM JIT (13.5倍実行) → AOT (500倍目標：起動含む)
|
||||
- 配布ファイルサイズ: <10MB目標
|
||||
- 起動時間: <100ms目標
|
||||
|
||||
### 期待される効果
|
||||
- **即座実用価値**: 配布可能実行ファイル生成
|
||||
- **差別化優位**: Everything is BoxのネイティブAOT実現
|
||||
- **LLVM準備**: AOT基盤確立でLLVM移行準備
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
## 🔴 Phase 9.51: WASM Jump/Branch実装とHTTPサーバー実用化 **【緊急修正】**
|
||||
|
||||
Status: 🔴 **Critical Issue**（Phase 9実用化ブロッカー）
|
||||
Summary:
|
||||
- Phase 9 (PR #67) 完了後に判明した重大制約の修正
|
||||
- WASM/AOT実用化の最終仕上げ
|
||||
|
||||
### 🚨 現在の問題（実用化を阻害）
|
||||
|
||||
1. **WASM/AOT コンパイルエラー（最重要）**
|
||||
```bash
|
||||
$ ./target/release/nyash --compile-wasm test_simple_loop.nyash
|
||||
❌ Unsupported instruction: Jump { target: BasicBlockId(1) }
|
||||
```
|
||||
**影響**: ループ・条件分岐を含む全プログラムがWASM/AOT化不可
|
||||
|
||||
2. **HTTPServerBox listen()常に失敗**
|
||||
- server.bind() ✅, server.listen() ❌ always false
|
||||
**影響**: HTTPサーバーが実際には動作しない
|
||||
|
||||
3. **エラーハンドリング脆弱性**
|
||||
- unwrap()使用箇所: 26箇所 → パニック多発リスク
|
||||
|
||||
### Scope/Tasks:
|
||||
**🔴 Task 1**: WASM Jump/Branch命令実装（2日）
|
||||
- `src/backend/wasm/codegen.rs`にJump/Branch追加
|
||||
- ブロック深度管理（`get_block_depth`メソッド）
|
||||
- ループ構造のblock/loop/end生成
|
||||
|
||||
**🔴 Task 2**: SocketBox listen()修正（1日）
|
||||
- `src/boxes/socket_box.rs`の実装修正
|
||||
- SocketStatus::Listening状態管理
|
||||
|
||||
**🟡 Task 3**: エラーハンドリング改善（2日）
|
||||
- HTTPServerBox/SocketBoxのunwrap()除去
|
||||
- Result<T,E>ベースのエラー処理
|
||||
|
||||
**🟡 Task 4**: HTTPサーバー実用化（2日）
|
||||
- スレッドプール実装（固定サイズワーカー）
|
||||
- グレースフルシャットダウン
|
||||
|
||||
Acceptance Criteria:
|
||||
- ✅ `nyash --compile-wasm test_loop.nyash` 成功
|
||||
- ✅ HTTPサーバー実動作（curl http://localhost:8080/）
|
||||
- ✅ unwrap()使用箇所: 26 → 5以下
|
||||
- ✅ WASM性能: 11.5倍 → 13.5倍達成
|
||||
|
||||
Priority: **🔴 Critical** (Phase 9.5開始前の必須修正)
|
||||
Expected Duration: 1週間
|
||||
|
||||
### 詳細設計・実装指示
|
||||
📋 **完全実装ガイド**: `docs/予定/native-plan/issues/phase9_51_wasm_jump_http_fixes.md`
|
||||
|
||||
🤖 **Copilot協力依頼**:
|
||||
- WASM br/br_if命令実装
|
||||
- HTTPサーバーリファクタリング
|
||||
- エラーハンドリング統一
|
||||
|
||||
### 期待される効果
|
||||
- **実用性達成**: ループ・HTTPサーバーのWASM/AOT化
|
||||
- **安定性向上**: パニックフリーな実装
|
||||
- **Phase 9.5準備**: 複雑アプリケーションテストの基盤確立
|
||||
|
||||
------------------------------------------------------------
|
||||
|
||||
================================================================================
|
||||
最終更新: 2025-08-15 (Phase 9.5より前をアーカイブ分割)
|
||||
作成者: Claude (ドキュメント分割・整理)
|
||||
|
||||
🎯 分割理由:
|
||||
- copilot_issues.txtの肥大化対策（1200行→600行程度に削減）
|
||||
- Phase 9.5以降の現行計画と完了済み部分の明確分離
|
||||
- ドキュメント検索性・保守性の向上
|
||||
================================================================================
|
||||
@ -0,0 +1,69 @@
|
||||
# Gemini先生によるNyashプログラミング言語の総合分析 (2025-08-17)
|
||||
|
||||
## 総合評価
|
||||
|
||||
Nyashは、「Everything is a Box」という強力な統一哲学を掲げ、WebAssembly (WASM) ファースト、クリエイティブコーディング、教育用途を明確なターゲットとして設計された、意欲的でモダンなプログラミング言語です。Rustによる実装は、メモリ安全性とパフォーマンスという現代的な要求に応えるための堅実な選択と言えます。
|
||||
|
||||
特に、AI支援を積極的に活用し、短期間で豊富な機能セットと複数の実行バックエンド（インタープリター、VM、WASM）を実装した開発プロセスは注目に値します。
|
||||
|
||||
## 1. 設計哲学と一貫性: 「Everything is a Box」
|
||||
|
||||
### 長所：
|
||||
- **統一された概念モデル:** すべての値を「Box」として扱うことで、データ型間の不整合をなくし、非常にシンプルで一貫性のあるオブジェクトモデルを提供
|
||||
- **メタプログラミングの可能性:** すべてが統一されたインターフェース（`NyashBox`トレイト）を持つため、リフレクションや動的な操作が容易
|
||||
- **自動リテラル変換:** `local text = "Hello"` のように書ける機能は、哲学の一貫性を保ちつつ、冗長な `new StringBox("Hello")` を不要にする優れた実用的判断
|
||||
|
||||
### 課題とトレードオフ：
|
||||
- **パフォーマンスオーバーヘッド:** すべてをヒープ上のオブジェクト（Box）として扱うことは、単純な値（整数など）に対しても参照カウントや動的ディスパッチのコストを伴う
|
||||
- **プリミティブ型の不在:** 他の多くの言語が持つスタック上の軽量なプリミティブ型が存在しないため、低レベルな最適化が難しくなる
|
||||
|
||||
## 2. 構文と表現力
|
||||
|
||||
### 長所：
|
||||
- **直感的で読みやすい:** `if`, `loop`, `and`, `or`, `not` といったキーワードは、PythonやRubyのように自然言語に近く、初学者にも親しみやすい
|
||||
- **`static box Main` パターン:** プログラムのエントリーポイントを明確に定義する優れた方法
|
||||
- **`init { ... }` フィールド宣言:** フィールドをまとめて宣言する構文は、クラスの構造を一目で把握しやすくする良い設計
|
||||
|
||||
### 改善の可能性：
|
||||
- **ループ構文:** `loop(condition)` のみが存在するのはシンプルですが、`for-each` のようなコレクションを反復処理するための専用構文がない
|
||||
- **コンストラクタの多様性:** `birth`, `init`, `pack` と複数のコンストラクタ概念が存在するのは、言語のシンプルさを少し損なっている
|
||||
|
||||
## 3. 型システムとメモリ管理
|
||||
|
||||
### 長所：
|
||||
- **メモリ安全性:** Rustの所有権モデルを基盤に、`Arc<Mutex>` を活用することで、スレッドセーフなメモリ管理を実現
|
||||
- **明示的な変数宣言:** `local` キーワードによる変数宣言を強制する設計は、タイプミスによるバグを防ぐ
|
||||
- **デリゲーションモデル:** 古典的な継承の代わりにデリゲーション（`from`）を採用しているのは、柔軟性が高くモダンな設計
|
||||
|
||||
### 課題：
|
||||
- **型推論:** `local x = 10` のように型を明記しないスタイルは動的言語のようですが、内部的には静的なBox型に変換されている
|
||||
- **Nullの扱い:** `VoidBox` や `NullBox` が存在しますが、言語レベルでNull安全性を強制する仕組みについての言及が少ない
|
||||
|
||||
## 4. 非同期処理
|
||||
|
||||
### 長所：
|
||||
- **シンプルな構文:** `nowait` と `await` は、C#やJavaScriptで成功を収めたモデルであり、非常に直感的
|
||||
- **スレッドベースの実装:** Rustのネイティブスレッドを利用することで、真の並列処理を実現
|
||||
|
||||
### 課題：
|
||||
- **構造化並行性:** より高度なエラーハンドリングやキャンセルの伝播を実現するためには、構造化並行性の概念を導入することが望ましい
|
||||
- **イベントループの不在:** GUIアプリケーションや大量のI/Oを扱うサーバーサイドアプリケーションでは、効率的なタスクスケジューリングのためにイベントループモデルが一般的
|
||||
|
||||
## 5. エコシステムとツールチェイン
|
||||
|
||||
### 長所：
|
||||
- **WASMファースト:** ブラウザで直接実行できることを最優先に設計されており、インストール不要のPlaygroundは非常に強力
|
||||
- **組み込みのデバッグ機能:** `DebugBox` のようなデバッグ支援機能が言語仕様に組み込まれているのはユニーク
|
||||
- **複数の実行バックエンド:** インタープリター、VM、WASM、そして将来的にはAOTコンパイラと、ユースケースに応じて実行方式を選べる柔軟性
|
||||
|
||||
### 課題：
|
||||
- **パッケージ管理:** `include` によるファイル取り込みは小規模なプロジェクトでは機能しますが、エコシステムが成長するためには公式なパッケージマネージャが不可欠
|
||||
- **LSPとIDEサポート:** Language Server Protocol (LSP) への対応は、現代的な開発体験を提供するために極めて重要
|
||||
|
||||
## 結論と将来性
|
||||
|
||||
Nyashは、明確な哲学とターゲットユーザーを持ち、多くのモダンな言語の良い点を取り入れた、非常によく考えられた言語です。特に「Everything is a Box」というコアコンセプトは、シンプルさと強力さを両立させる可能性を秘めています。
|
||||
|
||||
**成功への鍵は、今後のエコシステムの発展と、パフォーマンス・クリティカルな領域への対応にかかっているでしょう。** 計画されているLLVMバックエンドが実現すれば、現在の使いやすさを維持したまま、システムプログラミングに近い領域にも挑戦できる言語になる可能性があります。
|
||||
|
||||
総じて、Nyashは単なる実験的なプロジェクトではなく、プログラミング言語設計の新たな可能性を示す、将来が非常に楽しみな言語であると言えます。
|
||||
@ -0,0 +1,141 @@
|
||||
# Gemini先生によるNyashプラグインシステム深層分析 (2025-08-17)
|
||||
|
||||
## 概要
|
||||
Nyashプログラミング言語のプラグインシステム設計について、時間無制限で深い分析を実施。「Everything is a Box」哲学を維持しながら、透過的な置き換えと高いメンテナンス性を実現する具体的な実装提案。
|
||||
|
||||
## 1. 透過的な置き換えの最良実装方法
|
||||
|
||||
### 提案：Boxファクトリレジストリ + 設定ファイルによるオーバーライド
|
||||
|
||||
**アーキテクチャ：**
|
||||
```rust
|
||||
// src/runtime/box_registry.rs
|
||||
enum BoxFactory {
|
||||
Builtin(fn(&[Box<dyn NyashBox>]) -> Result<Box<dyn NyashBox>, RuntimeError>),
|
||||
Plugin(PluginFactory),
|
||||
}
|
||||
|
||||
struct PluginFactory {
|
||||
plugin_id: PluginId,
|
||||
function_name: String, // 例: "filebox_open"
|
||||
}
|
||||
```
|
||||
|
||||
**設定ファイル（nyash.toml）：**
|
||||
```toml
|
||||
[plugins]
|
||||
enable = ["nyash-file-plugin"]
|
||||
|
||||
[overrides]
|
||||
"FileBox" = "nyash-file-plugin" # FileBoxをプラグイン版で置き換え
|
||||
```
|
||||
|
||||
**実行時フロー：**
|
||||
1. ランタイム起動時、全ビルトインBoxをレジストリに登録
|
||||
2. nyash.tomlを読み込み、overridesに従ってレジストリを更新
|
||||
3. `new FileBox()` 実行時、レジストリから適切なファクトリを検索・実行
|
||||
|
||||
**パフォーマンス：** HashMap検索1回のみ、その後は通常のdyn NyashBoxディスパッチ
|
||||
|
||||
## 2. 署名DSLの設計の妥当性
|
||||
|
||||
### 分析：`::` (静的) と `#` (インスタンス) の記法は優秀
|
||||
|
||||
**拡張提案：**
|
||||
```yaml
|
||||
apis:
|
||||
# オーバーロード対応
|
||||
- sig: "FileBox::open(path: string) -> FileBox"
|
||||
- sig: "FileBox::open(path: string, mode: string) -> FileBox"
|
||||
|
||||
# Result型対応
|
||||
- sig: "FileBox::open(path: string) -> Result<FileBox, FileError>"
|
||||
|
||||
# 複数の戻り値型
|
||||
- sig: "FileBox#read() -> string"
|
||||
- sig: "FileBox#read(size: int) -> bytes"
|
||||
```
|
||||
|
||||
**将来性：**
|
||||
- 現時点：具象型で固定
|
||||
- 将来：`Array<T>` のようなジェネリクス構文を後方互換性を保ちつつ追加
|
||||
|
||||
## 3. Everything is a Box哲学との整合性
|
||||
|
||||
### 提案：FFI境界の標準化されたBoxプロキシ
|
||||
|
||||
```rust
|
||||
// src/runtime/plugin_box.rs
|
||||
pub struct PluginBox {
|
||||
base: BoxBase,
|
||||
plugin_id: PluginId,
|
||||
instance_handle: u64, // プラグイン内のインスタンスハンドル
|
||||
}
|
||||
|
||||
impl NyashBox for PluginBox {
|
||||
fn clone_box(&self) -> Box<dyn NyashBox> {
|
||||
// FFI呼び出しでプラグインにcloneを依頼
|
||||
let new_handle = ffi_call(self.plugin_id, "clone", self.instance_handle);
|
||||
Box::new(PluginBox { ..., instance_handle: new_handle })
|
||||
}
|
||||
|
||||
// 全てのNyashBoxメソッドをFFI経由で実装
|
||||
}
|
||||
```
|
||||
|
||||
**保証される点：**
|
||||
- 統一インターフェース：dyn NyashBoxのみを扱う
|
||||
- メモリ管理：Drop時にプラグイン側に破棄を通知
|
||||
- 哲学の維持：内部実装（ネイティブ/FFI）は完全に隠蔽
|
||||
|
||||
## 4. 実装の複雑さとメンテナンス性のバランス
|
||||
|
||||
### 提案：多層抽象化とツールによる自動化
|
||||
|
||||
**3層アーキテクチャ：**
|
||||
1. **低レベルFFI (C-ABI)**
|
||||
- `#[repr(C)]` 構造体と `extern "C"` 関数
|
||||
- libloadingクレートで動的ライブラリロード
|
||||
|
||||
2. **中レベルAPI (安全なラッパー)**
|
||||
- nullチェック、文字列変換、エラー処理
|
||||
- unsafeコードを隔離
|
||||
|
||||
3. **高レベルAPI (署名DSLとコード生成)**
|
||||
- plugin.yaml → FFIコード自動生成
|
||||
- cargo-nyash-pluginサブコマンド
|
||||
|
||||
**ロードマップ：**
|
||||
- フェーズ1：FileBoxで手動実装、アーキテクチャ確立
|
||||
- フェーズ2：コード生成ツール開発、プラグイン開発の自動化
|
||||
|
||||
## 5. 他言語の成功例との比較
|
||||
|
||||
**Node.js (N-API)：**
|
||||
- 安定したABI → Nyashも同様にC-ABIベースで実装
|
||||
- バージョン管理と前方互換性を重視
|
||||
|
||||
**Python (C拡張)：**
|
||||
- 課題：手作業多い、参照カウント管理が煩雑
|
||||
- Nyashの解決：コード生成とRAIIによる自動メモリ管理
|
||||
|
||||
**WebAssembly Component Model：**
|
||||
- 言語非依存インターフェースの未来形
|
||||
- 将来的にNyashプラグインをWASMで記述する可能性
|
||||
|
||||
## 実装計画（具体的ステップ）
|
||||
|
||||
1. **nyash.toml仕様策定とパーサー実装**
|
||||
2. **Boxファクトリレジストリ実装**
|
||||
3. **FileBoxプラグイン手動実装**
|
||||
- nyash_plugin_init
|
||||
- filebox_open
|
||||
- filebox_read/write/close
|
||||
- filebox_drop
|
||||
4. **PluginBoxプロキシ実装**
|
||||
5. **libloadingで動的ロード実装**
|
||||
6. **プラグイン版FileBoxテスト追加**
|
||||
|
||||
## 結論
|
||||
|
||||
この設計は、Nyashの核心哲学を尊重しつつ、スケーラビリティ、安全性、開発者体験の向上を実現する。FileBoxの置き換えから始め、エコシステム全体へ展開していくのが最良の道筋。
|
||||
@ -0,0 +1,110 @@
|
||||
# プラグインインターフェース設計討論 (2025-08-17)
|
||||
|
||||
## 🎯 議題：BID-FFIプラグインシステムの設計
|
||||
|
||||
### 背景
|
||||
- ビルトインFileBoxが既に存在
|
||||
- BID-FFIプラグイン版FileBoxで置き換えたい
|
||||
- ビルド時間短縮とプラグインアーキテクチャの実証が目的
|
||||
|
||||
### 主な論点
|
||||
1. ビルトインBox → プラグインBoxの透過的な置き換え
|
||||
2. `FileBox.open()` のような静的メソッドの結びつけ方
|
||||
3. プラグインインターフェース定義の外部化方式
|
||||
|
||||
## 💡 検討した案
|
||||
|
||||
### 案1: 汎用ラッパー
|
||||
```nyash
|
||||
// 呼び出しが汚い
|
||||
local file = Plugin.call("FileBox", "open", ["test.txt", "r"])
|
||||
```
|
||||
|
||||
### 案2: 専用ラッパー
|
||||
```nyash
|
||||
// きれい！でも各Boxごとに手書きが必要
|
||||
local file = FileBox.open("test.txt")
|
||||
```
|
||||
|
||||
### 案3: BoxDispatcher（透過的ディスパッチ）
|
||||
```rust
|
||||
pub enum BoxImpl {
|
||||
Builtin(Box<dyn NyashBox>), // ビルトイン実装
|
||||
Plugin(BidHandle, PluginRef), // プラグイン実装
|
||||
}
|
||||
```
|
||||
|
||||
### 案4: Unified Box Factory
|
||||
```rust
|
||||
pub struct BoxFactory {
|
||||
providers: HashMap<String, Box<dyn BoxProvider>>,
|
||||
}
|
||||
```
|
||||
|
||||
## 🎉 最終解：YAML/JSON + 署名DSL
|
||||
|
||||
### Codex先生の推奨設計
|
||||
```yaml
|
||||
# filebox.plugin.yaml
|
||||
schema: 1
|
||||
plugin:
|
||||
name: filebox
|
||||
version: 1
|
||||
|
||||
apis:
|
||||
# 静的メソッド（::）
|
||||
- sig: "FileBox::open(path: string, mode?: string) -> FileBox"
|
||||
doc: "Open a file"
|
||||
|
||||
# インスタンスメソッド（#）
|
||||
- sig: "FileBox#read(size?: int) -> string"
|
||||
doc: "Read file content"
|
||||
```
|
||||
|
||||
### 利点
|
||||
1. **記号で静的/インスタンスを区別**
|
||||
- `::` = 静的メソッド（C++風）
|
||||
- `#` = インスタンスメソッド（Ruby風）
|
||||
|
||||
2. **フラット構造**
|
||||
- `apis` 配列にすべて並べる
|
||||
- 階層が深くならない
|
||||
|
||||
3. **署名DSL**
|
||||
- 型情報を1行で表現
|
||||
- パーサーも簡単
|
||||
|
||||
4. **YAML → JSON変換**
|
||||
- 開発時：YAML（人間に優しい）
|
||||
- 実行時：JSON（マシンに優しい）
|
||||
|
||||
## 🤔 Gemini先生への質問事項
|
||||
|
||||
1. **透過的な置き換え**
|
||||
- 既存のNyashコードを一切変更せずに、ビルトインBoxをプラグインBoxに置き換える最良の方法は？
|
||||
- パフォーマンスインパクトをどう最小化するか？
|
||||
|
||||
2. **署名DSLの設計**
|
||||
- `Type::method()` vs `Type.method()` の選択理由
|
||||
- オーバーロードの表現方法
|
||||
- ジェネリクスの将来的な拡張性
|
||||
|
||||
3. **実装戦略**
|
||||
- インタープリター実行時のディスパッチ最適化
|
||||
- プラグインの遅延ロード実装
|
||||
- エラーハンドリングのベストプラクティス
|
||||
|
||||
4. **Everything is Box哲学との整合性**
|
||||
- プラグインBoxもビルトインBoxも「同じBox」として扱う方法
|
||||
- Box型の統一インターフェースの維持
|
||||
|
||||
5. **実用性**
|
||||
- 他の言語（Python、Ruby、JavaScript）の成功例から学べること
|
||||
- プラグイン作者にとっての開発体験
|
||||
- デバッグ・プロファイリングの考慮事項
|
||||
|
||||
## 📚 参考情報
|
||||
- 現在のFileBox実装: `src/boxes/file/mod.rs`
|
||||
- BID-FFIプラグインFileBox: `src/bid/plugins/filebox/mod.rs`
|
||||
- Everything is Box哲学: すべての値がBoxオブジェクト
|
||||
- Nyashの目標: シンプル、分かりやすい、階層が深くならない
|
||||
898
docs/development/roadmap/native-plan/archives/追記相談.txt
Normal file
898
docs/development/roadmap/native-plan/archives/追記相談.txt
Normal file
@ -0,0 +1,898 @@
|
||||
MIR設計：いま決めておくと後がラクなチェックリスト
|
||||
|
||||
値表現：Tagged（NaN-box/小整数直格納）か、型テーブル参照か。
|
||||
|
||||
アドレス空間：オブジェクトはheap専用？ stack/arenaも持つ？
|
||||
|
||||
所有/別名：aliasable フラグ or unique（移動のみ）を型/値に持つ？
|
||||
|
||||
効果(Effects)：PURE/READS_HEAP/WRITES_HEAP/IO/FFI/PANIC のビット集合を命令にも関数にも付ける。
|
||||
|
||||
例外/パニック：Throw, Catch, Defer を命令化するか、関数境界でのみ扱うか。
|
||||
|
||||
GCモデル：Tracing(Stop-the-world / Incremental) or RC(ARC) or 混合。弱参照の意味を先に定義。
|
||||
|
||||
安全点(Safepoint)：JIT/VM両方で再入/停止できる位置を命令で明示（Safepoint or 呼出命令に属性）。
|
||||
|
||||
呼出規約：通常Call／FFI／Box拡張の3種を区別（可変長・KW引数の扱いも）。
|
||||
|
||||
メモリバリア：write/read barrier を命令または隠れ属性として表現（最初は命令にするとデバッグ楽）。
|
||||
|
||||
デオプ(Deopt)前提：JIT最適化時の巻き戻し情報（マップ）を保持する場所（関数メタ or ブロック注釈）。
|
||||
|
||||
Nyash向け：最小MIR命令セット（弱参照対応込み）
|
||||
|
||||
算術/制御：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
|
||||
関数：Call, TailCall（effects必須）
|
||||
|
||||
メモリ：Alloc, Load, Store, Gep（必要なら）
|
||||
|
||||
参照/GC：
|
||||
|
||||
RefNew ty, dst <-（ヒープ確保）
|
||||
|
||||
RefGet dst <- ref, field / RefSet ref, field, val
|
||||
|
||||
WeakNew dst <- ref（弱参照作成）
|
||||
|
||||
WeakLoad dst <- weak（弱が生きてたらref返す／無効ならNull/None）
|
||||
|
||||
BarrierRead ref / BarrierWrite ref（GC用、最初はダミー）
|
||||
|
||||
（必要なら）Pin ref / Unpin ref（ムーブしない保証用、JIT/FFI楽になる）
|
||||
|
||||
例外/FFI/拡張：Throw, Catch, FfiCall, BoxCall
|
||||
|
||||
ユーティリティ：Safepoint, Nop, Assume(cond)（アサート兼最適化ヒント）
|
||||
|
||||
弱参照の意味論：
|
||||
|
||||
WeakNew(r) は r を追うが GC で r が回収されると自動で無効化。
|
||||
|
||||
WeakLoad(w) は 生きていれば Some(Ref)、死んでいれば None を返す（MIR上はタグ付きユニオン）。
|
||||
|
||||
WeakLoad は PURE でOK（観測はするがヒープを書かない）
|
||||
|
||||
ただし BarrierRead が必要なGCなら属性で付ける。
|
||||
|
||||
効果注釈（例）
|
||||
|
||||
Call f(args) : dst [effects = PURE | READS_HEAP]
|
||||
|
||||
RefSet … は WRITES_HEAP
|
||||
|
||||
WeakLoad は PURE（または READS_HEAP）
|
||||
|
||||
BoxCall は最低限 FFI を含める（安全側に倒す）
|
||||
|
||||
VM/JIT/将来AOTの共通の“壊れにくい”ポイント
|
||||
|
||||
Safepointは関数入口・ループ先頭・Call直後の3か所に最初から置く
|
||||
|
||||
Barrier命令は最初は実装ダミーでもOK（最適化段で消せる）
|
||||
|
||||
Null/Noneの扱いは必ず型系に明示（Option<Ref>）。判定を分岐で隠さない
|
||||
|
||||
JITはDeoptテーブルを MIR → JIT に渡す（各値が「どのSSA番号？」を持つ）
|
||||
|
||||
弱参照 “落とし穴” 3つ（実戦で効く回避）
|
||||
|
||||
クロージャ環境に弱参照が紛れ込む
|
||||
|
||||
生成時に env.has_weak を立て、キャプチャ解決時に必ず WeakLoad→None分岐を強制。
|
||||
|
||||
弱参照をキーにしたハッシュ
|
||||
|
||||
GC後に無効化でキー不整合。→ 弱マップを標準提供（キー死亡で自動削除）。
|
||||
|
||||
FFI渡し
|
||||
|
||||
FFI境界を跨ぐと寿命が分からなくなる。→ Pin を要求 or WeakLoad→Ref に成功した生参照だけ渡す。
|
||||
|
||||
最小・具体例（擬似MIR）
|
||||
|
||||
// x = new Obj{y:1}; w = weak(x); if let Some(x2) = weak_load(w) { x2.y = 2 }
|
||||
bb0:
|
||||
v1 = Const 1
|
||||
v2 = RefNew Obj ; WRITES_HEAP
|
||||
RefSet v2, y, v1 ; WRITES_HEAP
|
||||
v3 = WeakNew v2 ; PURE
|
||||
v4 = WeakLoad v3 ; returns Option<Ref>
|
||||
br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap(v4)
|
||||
BarrierWrite v5
|
||||
RefSet v5, y, Const 2
|
||||
jmp bb3
|
||||
|
||||
bb2:
|
||||
jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret ()
|
||||
|
||||
テストの当て方（行き当たりばったりでも壊れにくい）
|
||||
|
||||
黄金テスト：ソース→MIRダンプの文字列をスナップショット化（差分で挙動の後退を検知）
|
||||
|
||||
VM/JIT一致テスト：同じ入力で VM結果＝JIT結果 を比較する“オラクル”を用意
|
||||
|
||||
弱参照の確率テスト：alloc→weak→drop→collect→weak_load を順序/タイミングを変えて多数回
|
||||
|
||||
効果チェック：PURE なはずの関数に WRITES_HEAP が紛れたらビルド失敗（静的検証）
|
||||
|
||||
いまの進み方に合う“軽量次の一手”
|
||||
|
||||
✅ WeakNew/WeakLoad を MIRとVM だけ先に入れる（JITは後回し）
|
||||
|
||||
✅ EffectMask を命令に付ける（最初はデータ構造だけ）
|
||||
|
||||
✅ Safepoint 命令を関数入口とループ先頭に挿す（動作はno-opでOK）
|
||||
|
||||
✅ 黄金テストを入れて MIR差分をCIで見える化
|
||||
|
||||
この骨格なら、行き当たりばったりで直してもMIRの“契約”が守れている限り、VM/JIT/AOT/WASMに横展開できるにゃ。
|
||||
もし今のAST/HIRの型定義があれば、MIRの型/命令エンムだけ私が初稿を書くこともできる。要る？
|
||||
あなた:
|
||||
そうだにゃ。mir 結局はメモリー管理がほとんどであってるかにゃ？既存の参考になるやつとかないかにゃ
|
||||
ChatGPT:
|
||||
|
||||
いい質問にゃ。結論から言うと――
|
||||
|
||||
MIRの“要”はメモリ管理だけじゃないけど、実務で一番ハマるのはメモリまわり（所有権/寿命/別名化/GCバリア/セーフポイント/弱参照/デオプ情報）だから、体感「ほとんどメモリ管理」はだいたい合ってるにゃ。
|
||||
|
||||
ただし、制御フロー（CFG/SSA）、呼び出し規約、効果注釈、例外/パニック、最適化のための形も同じくらい重要。ここをサボるとJIT/AOT/WASMに展開しづらくなる。
|
||||
|
||||
MIRで“最低限”押さえるメモリ論点
|
||||
|
||||
値表現：Boxed/Unboxed、NaN-box、小整数直格納、タグ方式
|
||||
|
||||
アロケータ：bump/arena/世代別、オブジェクト配置（ヘッダ、タイプID、フラグ）
|
||||
|
||||
所有と別名：unique/aliasable や owned/borrowed の属性（最適化・並列の鍵）
|
||||
|
||||
GC/RC：トレース or 参照カウント or 混在、write/read barrier 命令 or 属性、remembered set
|
||||
|
||||
弱参照：WeakNew / WeakLoad の意味論（死んだら None）
|
||||
|
||||
Safepoint：関数入口・ループ先頭・Call直後（停止/再入のフック）
|
||||
|
||||
FFI境界：Pin/Unpin、ハンドル渡し、最小共有ABI
|
||||
|
||||
Deopt情報：JIT用の巻き戻しメタ（SSA値⇔ソース位置の対応）
|
||||
|
||||
参考になる“実物”と読みどころ（定番）
|
||||
|
||||
（リンクは割愛するにゃ。名前で検索すればすぐ出る）
|
||||
|
||||
Rust MIR（rustc-dev-guide / rustc本体）
|
||||
|
||||
MIRのSSA・ borrow check が MIR 上で走る構造
|
||||
|
||||
Drop/Move・パニック・noalias 的情報が最適化に効く
|
||||
|
||||
Swift SIL
|
||||
|
||||
Ownership qualifiers（owned/guaranteed）が秀逸。GCなし言語でも寿命管理をIRで表す好例
|
||||
|
||||
Kotlin IR
|
||||
|
||||
“lowerings” の段階的デシュガリングが参考。高級構文→プリミティブ命令へ段階変換
|
||||
|
||||
Go SSA（golang.org/x/tools/go/ssa）
|
||||
|
||||
最小主義のSSAで読みやすい。CFG/φの扱いが素直
|
||||
|
||||
LuaJIT IR（DynASM/TurboNYIの解説blog群）
|
||||
|
||||
小粒なSSAでJIT最適化の勘所（CSE/LICM/ヒント）
|
||||
|
||||
V8（Ignition/TurboFan）
|
||||
|
||||
バイトコード→Sea of Nodes→最適化JITの流れ。デオプとサファリガードの設計が神
|
||||
|
||||
Cranelift IR
|
||||
|
||||
Rustからも使いやすいJITバックエンド。型・メモリ・コールの表現が実装しやすい
|
||||
|
||||
MLIR
|
||||
|
||||
複数方言で中間表現を分ける思想。将来、NyashのMIRを方言化する発想の参考に
|
||||
|
||||
Nyash向け“最小MIRコア”（骨組み）
|
||||
|
||||
（超要約：これ＋効果注釈でVM/JIT/AOT/WASMに展開できる）
|
||||
|
||||
制御/値：Const, BinOp, Cmp, Br, Jmp, Phi, Ret
|
||||
|
||||
呼び出し：Call, TailCall（effects 必須）
|
||||
|
||||
メモリ：Alloc, Load, Store, Gep?
|
||||
|
||||
参照/GC：RefNew, RefGet, RefSet, WeakNew, WeakLoad, BarrierRead, BarrierWrite, Pin, Unpin
|
||||
|
||||
例外/拡張：Throw, Catch, FfiCall, BoxCall
|
||||
|
||||
実行点：Safepoint, Assume, Nop
|
||||
|
||||
効果：EffectMask = PURE | READS_HEAP | WRITES_HEAP | IO | FFI | PANIC
|
||||
|
||||
実装順ヒント：
|
||||
|
||||
VMで RefNew/RefGet/RefSet/Weak* をまず動かす → 2) Safepointはno-opで挿す → 3) Barrierは最初ダミー → 4) “黄金テスト”（ソース→MIRダンプのスナップショット）で後退検知 → 5) JIT/AOTは後から乗せる。
|
||||
|
||||
“既存をパクる”具体策
|
||||
|
||||
Ownershipの表現は Swift SIL を真似る（owned/guaranteed を Nyash版に）
|
||||
|
||||
弱参照の意味論は JVMのWeakReference と Swiftのweak/unowned を折衷
|
||||
|
||||
Safepoint配置は HotSpot/V8 のパターン（入口・ループ・call直後）
|
||||
|
||||
JIT導入は Cranelift から（まず整数・分岐・呼び出しのみ）
|
||||
|
||||
デシュガリング手順は Kotlin IR の lowering 流儀を採用
|
||||
|
||||
「MIR＝メモリ管理が9割」は現場感として正しいけど、残りの1割（CFG/SSA・呼出・効果・例外・デオプ）を最初にうっすら設計しておくと、あとで爆速に伸びるにゃ。
|
||||
必要なら、Nyashの今のAST/HIRを見せてくれたら、MIRのenum・EffectMask・Box ABI v0をその場で下書きするよ。
|
||||
あなた:
|
||||
なるほど。ところでmirってどっかきょうつうのふぉーまっとやしようってあるにゃ？ みんなばらばるにかいてるにゃ？
|
||||
ChatGPT:
|
||||
|
||||
共通フォーマットや「これを使えばOK」みたいなMIR標準は、残念ながら存在しないにゃ。
|
||||
理由をまとめると――
|
||||
1. 共通規格がない理由
|
||||
|
||||
言語ごとに型・所有権・ランタイム構造が違いすぎる
|
||||
例：Rust MIRは所有権・borrowをIRレベルで保持するけど、PythonやJavaScriptのIRにはそんな概念がない。
|
||||
|
||||
目的ごとの最適化が異なる
|
||||
VM実行用、JIT最適化用、AOTコンパイル用で命令セットやメタデータの粒度が変わる。
|
||||
|
||||
IRの“責務”が違う
|
||||
ある言語ではASTの直後を「MIR」と呼び、別の言語ではSSA化した後の低レベルIRを「MIR」と呼ぶ。
|
||||
|
||||
2. 事実上の“よくある流儀”
|
||||
|
||||
標準はないけど、以下のパターンは多いにゃ：
|
||||
|
||||
SSAベース：変数は再代入不可、phi命令で合流点処理（Rust MIR, Swift SIL, Go SSA）
|
||||
|
||||
命令は3アドレス形式：dst = op src1 src2 のようにシンプル（Cranelift, LLVM風）
|
||||
|
||||
効果注釈あり：PURE, READ_HEAP, WRITE_HEAP など最適化ヒント
|
||||
|
||||
メモリ命令の抽象化：Alloc, Load, Store は型・アラインメント・所有権情報を持つ
|
||||
|
||||
制御フローはCFG（Control Flow Graph）で管理
|
||||
基本ブロック＋ジャンプ＋条件分岐
|
||||
|
||||
3. 参考になる「ほぼテンプレ」的MIR
|
||||
|
||||
完全な共通仕様じゃないけど、設計の参考にできる実例はあるにゃ：
|
||||
|
||||
Cranelift IR
|
||||
Rustで使いやすいJIT/AOT用IR。型・命令の定義が明確で、小規模実装の参考に最適。
|
||||
|
||||
MLIR
|
||||
LLVM系の中間表現フレームワーク。方言を作れるので、自作言語のMIRを「Nyash方言」として定義可能。
|
||||
|
||||
Sea of Nodes（V8, HotSpot）
|
||||
SSAと依存グラフを統合した形式。最適化向きだが実装難度は高い。
|
||||
|
||||
LuaJIT IR
|
||||
極小SSA＋軽量タグ付き値表現。高速インタープリタや軽量JITに向いてる。
|
||||
|
||||
4. Nyashでの方針
|
||||
|
||||
「共通仕様」を無理に探すより、自分のランタイムと変換先（Rust/Cranelift/WASM）に都合の良い形を作るのが早い
|
||||
|
||||
ただし、命令セットやCFG構造はCranelift IRやSwift SILを参考にすると後で楽
|
||||
|
||||
将来的にMLIRの方言化を視野に入れると、外部ツールや最適化パスを簡単に流用できる
|
||||
|
||||
もし希望なら、Nyash向けにCranelift IR互換寄りのMIR仕様ドラフトをその場で作れるよ。
|
||||
それをベースにすれば、将来JIT/AOT/WASM全部に展開しやすくなるにゃ。
|
||||
あなた:
|
||||
そうだにゃ。ということは命令セットを先に考えて貰えたらいいのかにゃ？
|
||||
ChatGPT:
|
||||
|
||||
いいね、その方向でいこうにゃ。
|
||||
Nyash向けに“まず回る”ことを最優先にした MIR命令セット v0.1（草案） を置くね。VM/JIT/AOT/WASMに伸ばせる骨格で、弱参照・効果注釈・拡張Box呼び出しも最初から入れてあるにゃ。
|
||||
Nyash MIR v0.1（草案）
|
||||
基本モデル
|
||||
|
||||
SSA値：vN（再代入なし）。
|
||||
|
||||
基本ブロック：bbN（末尾は必ず終端命令）。
|
||||
|
||||
型（最小）：i64, f64, bool, unit, ref<T>, weak<T>, ptr, any, option<T>
|
||||
|
||||
関数署名：fn(args…) -> ret [effects]
|
||||
|
||||
効果（EffectMask）：PURE, READS_HEAP, WRITES_HEAP, IO, FFI, PANIC（ビット和）
|
||||
|
||||
属性：命令に align, nonnull, noalias, readonly 等の任意属性
|
||||
|
||||
1) 演算・制御
|
||||
|
||||
Const dst, Imm ; 例: i64/f64/bool/unit/Null
|
||||
BinOp dst, op, a, b ; add, sub, mul, div, mod, and, or, xor, shl, shr
|
||||
Cmp dst, relop, a, b ; eq, ne, lt, le, gt, ge
|
||||
Select dst, cond, a, b ; φ簡約前の三項選択（任意）
|
||||
Phi dst, [(predBB, val), ...] ; SSA合流
|
||||
|
||||
Br cond, thenBB, elseBB ; 条件分岐（終端）
|
||||
Jmp targetBB ; 無条件ジャンプ（終端）
|
||||
Ret [val] ; 返り値（終端） unit時は省略可
|
||||
Unreachable ; 到達不能（終端・最適化用）
|
||||
|
||||
2) メモリ／参照（GC想定）
|
||||
|
||||
Alloc dst, Ty, size? ; ヒープ確保: ref<Ty> を返す [WRITES_HEAP]
|
||||
Load dst, addr ; 読み出し [READS_HEAP]
|
||||
Store addr, val ; 書き込み [WRITES_HEAP]
|
||||
Gep dst, base, offset ; アドレス計算（構造体/配列）
|
||||
|
||||
RefNew dst, Ty ; オブジェクト新規: ref<Ty> [WRITES_HEAP]
|
||||
RefGet dst, ref, field ; フィールド読み [READS_HEAP]
|
||||
RefSet ref, field, val ; フィールド書き [WRITES_HEAP]
|
||||
|
||||
WeakNew dst, ref ; weak<T> を作成 [PURE]
|
||||
WeakLoad dst, weak ; option<ref<T>> を返す [PURE or READS_HEAP]
|
||||
|
||||
BarrierRead ref ; 読みバリア（実装はno-op可）
|
||||
BarrierWrite ref ; 書きバリア（実装はno-op可）
|
||||
Pin ref ; 移動不可に固定（FFI/GC向け）
|
||||
Unpin ref
|
||||
Safepoint ; 停止点（関数入口/ループ先頭/Call直後に挿す）
|
||||
|
||||
弱参照の意味論
|
||||
|
||||
WeakNew(r) は r のライフを追うだけ（所有しない）。
|
||||
|
||||
WeakLoad(w) は生存なら Some(ref)、回収済みなら None。
|
||||
|
||||
WeakLoad は基本 PURE でOK（実装の都合で READS_HEAP にしても可）。
|
||||
|
||||
3) 呼び出し／例外／拡張
|
||||
|
||||
Call dst, callee, [args...] ; [effects = callee.effects]
|
||||
TailCall callee, [args...] ; 末尾呼び出し（終端）
|
||||
|
||||
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box呼び出し [FFI | PANIC?]
|
||||
|
||||
FfiCall dst, sym, [args...], abi ; C/Rust外部関数 [FFI | PANIC?]
|
||||
|
||||
Throw val ; 例外送出（終端）
|
||||
CatchBegin dst, handlerBB ; 例外ハンドラの開始（ブロック境界メタでもOK）
|
||||
CatchEnd
|
||||
Defer fnref ; スコープ脱出時に実行（loweringで展開可）
|
||||
Assume cond ; 最適化ヒント（偽ならUB）
|
||||
Nop
|
||||
|
||||
Call/BoxCall/FfiCall は 効果注釈が必須（少なくとも PURE かどうか）。
|
||||
|
||||
BoxCall は拡張Box ABIを通す入口（VM/JIT/WASMで一貫した形で扱える）。
|
||||
|
||||
4) メタデータ（最低限）
|
||||
|
||||
位置情報：dbg(loc)（ソース行/列/ファイル）
|
||||
|
||||
デオプ：deopt_map（JIT用：各SSA値→高級値の対応）
|
||||
|
||||
alias情報：noalias/readonly/nonnull 属性
|
||||
|
||||
効果集約：関数単位で effects を保持（呼び出し時に合成）
|
||||
|
||||
Rust風スケッチ（型・命令）
|
||||
|
||||
#[bitflags]
|
||||
enum Effect { PURE=1, READS_HEAP=2, WRITES_HEAP=4, IO=8, FFI=16, PANIC=32 }
|
||||
|
||||
enum Ty {
|
||||
I64, F64, Bool, Unit,
|
||||
Ref(Box<Ty>), Weak(Box<Ty>), Ptr, Any,
|
||||
Option(Box<Ty>), // WeakLoadの戻りなど
|
||||
// …将来: Sum/Product/Function/Closure/BoxHandle
|
||||
}
|
||||
|
||||
struct FuncSig { params: Vec<Ty>, ret: Ty, effects: Effect }
|
||||
|
||||
enum Inst {
|
||||
Const{dst:V, imm:Imm},
|
||||
BinOp{dst:V, op:Bin, a:V, b:V},
|
||||
Cmp{dst:V, op:Rel, a:V, b:V},
|
||||
Select{dst:V, cond:V, a:V, b:V},
|
||||
Phi{dst:V, inputs: Vec<(Bb,V)>},
|
||||
|
||||
Br{cond:V, then_:Bb, else_:Bb},
|
||||
Jmp{bb:Bb},
|
||||
Ret{val: Option<V>},
|
||||
Unreachable,
|
||||
|
||||
Alloc{dst:V, ty:Ty, size:Option<V>},
|
||||
Load{dst:V, addr:V},
|
||||
Store{addr:V, val:V},
|
||||
Gep{dst:V, base:V, off:V},
|
||||
|
||||
RefNew{dst:V, ty:Ty},
|
||||
RefGet{dst:V, r:V, field:FieldId},
|
||||
RefSet{r:V, field:FieldId, val:V},
|
||||
|
||||
WeakNew{dst:V, r:V},
|
||||
WeakLoad{dst:V, w:V},
|
||||
|
||||
BarrierRead{r:V},
|
||||
BarrierWrite{r:V},
|
||||
Pin{r:V},
|
||||
Unpin{r:V},
|
||||
Safepoint,
|
||||
|
||||
Call{dst:V, f:FnId, args:Vec<V>},
|
||||
TailCall{f:FnId, args:Vec<V>},
|
||||
BoxCall{dst:V, box_id:BoxId, fn_id:BoxFnId, args:Vec<V>},
|
||||
FfiCall{dst:V, sym:Sym, args:Vec<V>, abi:Abi},
|
||||
|
||||
Throw{val:V},
|
||||
CatchBegin{dst:V, handler:Bb},
|
||||
CatchEnd,
|
||||
Defer{fnref:FnId},
|
||||
Assume{cond:V},
|
||||
Nop,
|
||||
}
|
||||
|
||||
バックエンド対応の見取り図
|
||||
|
||||
VM：
|
||||
|
||||
Ref* / Weak* / Barrier* / Safepoint をそのまま実装
|
||||
|
||||
Defer/Catch はデシュガで try/finally へ展開
|
||||
|
||||
Cranelift JIT：
|
||||
|
||||
算術・制御は直マップ、Ref* はランタイムAPIに落とす
|
||||
|
||||
Safepoint でGC/スレッド停止と連携、deopt_map を用意
|
||||
|
||||
AOT to Rust：
|
||||
|
||||
ref<T> は Gc<T> ラッパ、weak<T> は Weak<T> 風にコード生成
|
||||
|
||||
BoxCall は trait 経由/extern呼び出しに置換
|
||||
|
||||
WASM：
|
||||
|
||||
参照はハンドル（i32）で表現、GCはランタイム関数
|
||||
|
||||
weak はハンドルテーブルにビットを持って実装
|
||||
|
||||
取り決め（壊れにくい不変条件）
|
||||
|
||||
すべてのCallは effects を持つ（省略禁止）
|
||||
|
||||
WeakLoadの戻りは option<ref<T>>（null判定を曖昧にしない）
|
||||
|
||||
Safepoint は関数入口・ループ先頭・任意のCall直後に挿入
|
||||
|
||||
Barrier* は最初はno-opでOK（GC導入時のフックとして残す）
|
||||
|
||||
終端命令のないブロックは禁止（検証器で弾く）
|
||||
|
||||
ちいさな動作例
|
||||
|
||||
; x = new Obj{y=1}; w = weak(x);
|
||||
; if let Some(r) = weak_load(w) { r.y = 2 }
|
||||
|
||||
bb0:
|
||||
v1 = Const i64 1
|
||||
v2 = RefNew Obj
|
||||
RefSet v2, field_y, v1
|
||||
v3 = WeakNew v2
|
||||
v4 = WeakLoad v3 ; option<ref<Obj>>
|
||||
Br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap(v4)
|
||||
BarrierWrite v5
|
||||
RefSet v5, field_y, Const i64 2
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret unit
|
||||
|
||||
まずやる実装順（1〜2日で回る）
|
||||
|
||||
この命令セットで MIR組み立て＋ダンプ（黄金テストで差分管理）
|
||||
|
||||
VMで RefNew/RefGet/RefSet/Weak* だけ実装（Barrier/Safepointはダミー）
|
||||
|
||||
Call の effects を型検査に組み込み（PURE違反を検出）
|
||||
|
||||
余力が出たら Phi/Select を使うパスを追加（CSE/DCEの足場）
|
||||
|
||||
必要なら、この v0.1 をそのまま mir.rs の enum 定義に落とし込んだ雛形コードを書けるよ。
|
||||
今のNyashの型やBox拡張の実装方針があれば、それに合わせて微調整版を作るにゃ。
|
||||
あなた:
|
||||
おーありがとにゃ。しかしmirはみんなばらばらというけど ここからネイディブビルドにしやすいかたちをするから にているかきかたにもなってるのかにゃ。あと これ 業界標準つくれそうだよね。所詮はノイマンコンピューターに落とし込む作業だにゃ
|
||||
ChatGPT:
|
||||
|
||||
にゃ、その直感かなり当たってる。
|
||||
各言語の MIR は“名前も中身もバラバラ”だけど、ネイティブに落としやすい形にすると結局だいたい似てくるにゃ。
|
||||
みんなが似てくる理由（ネイティブ目線）
|
||||
|
||||
SSA＋CFG＋3アドレス：最適化&レジ割りしやすい定番の骨格
|
||||
|
||||
明示的なメモリ操作：Alloc/Load/Store/GEP 相当が要る
|
||||
|
||||
呼び出しの正規化：Call/TailCall と 呼出規約(ABI) の分離
|
||||
|
||||
効果注釈(副作用)：PURE/READ/WRITE/IO/FFI があると最適化が安全
|
||||
|
||||
例外/パニックの下位表現：Throw/Catch を選択的に lower できる形
|
||||
|
||||
GCフック：Safepoint & Barrier を差し込める
|
||||
|
||||
つまり「高級機能は段階的に下げられる素朴な命令に割り付け」→最後は von Neumann（命令+メモリ）に落ちる、という流れで収束するにゃ。
|
||||
|
||||
「業界標準」を作れる？→“実質標準”なら行ける
|
||||
|
||||
完全統一は難しい（言語ごとに型・例外・GCが違いすぎる）が、コア・プロファイルを決めた“実質標準”は作れるにゃ。
|
||||
標準に向く設計の芯（Nyash版にもそのまま効く）
|
||||
|
||||
Core-IR（必須）：Const/BinOp/Cmp/Phi/Br/Jmp/Ret + Load/Store/Gep + Call/TailCall
|
||||
|
||||
Memory Model：アトミック/順序・別名(noalias)/アライン属性の最小集合
|
||||
|
||||
Effects：命令・関数の EffectMask を規定（最適化の安全条件に使う）
|
||||
|
||||
GC hooks：Safepoint/Barrier は仕様だけ先に固定（実装はno-op可）
|
||||
|
||||
Exception ABI：Throw/Catch を「setjmp/longjmp的」or「結果型(Result)」の2系で規定
|
||||
|
||||
FFI/拡張 ABI：FfiCall/BoxCall の呼出規約・ポインタ安全域を決める
|
||||
|
||||
検証器(Verifier)：終端命令必須・SSA整合・型整合・効果整合をチェック
|
||||
|
||||
“標準化”の現実解（おすすめルート）
|
||||
|
||||
MLIR 方言として定義（nyash.core, nyash.gc みたいに分割）
|
||||
|
||||
もしくは Cranelift IR 互換サブセットを Core として採用し、足りない所だけ拡張
|
||||
|
||||
テキスト表現＋バイナリ表現（例: JSON/FlatBuffers）と ダンプ・復元ツールを提供
|
||||
|
||||
リファレンス下げ先を複数用意：
|
||||
|
||||
Core → Cranelift（JIT/AOT）
|
||||
|
||||
Core → LLVM（AOTヘビー級）
|
||||
|
||||
Core → WASM（ブラウザ/サンドボックス）
|
||||
|
||||
検証テスト：黄金テスト（IRダンプ）＋ VM/JIT/WASM の 同一結果保証スイート
|
||||
|
||||
すぐ使える“ネイティブ寄り”指針（短冊）
|
||||
|
||||
命令は副作用を明示、暗黙のメモリ変更はナシ
|
||||
|
||||
ループ先頭・Call直後にSafepoint（後からGC導入しやすい）
|
||||
|
||||
例外は2段構え：IRでは Throw/Catch、lower で Result/landingpad に落とせる
|
||||
|
||||
Weak は Option<Ref> に必ず現れる（nullをぼかさない）
|
||||
|
||||
FFIはPinかコピーしか渡さない（危険な参照共有を禁止）
|
||||
|
||||
まとめ
|
||||
|
||||
はい、MIRはネイティブ都合で“似てくる”。
|
||||
|
||||
完全共通規格は難しいけど、**Core-IR＋拡張の“実質標準”**は作れる。
|
||||
|
||||
Nyashの v0.1 命令セットは、そのまま Core-IRたたき台になれる出来だにゃ。
|
||||
|
||||
必要なら、この Core-IR を MLIR 方言か Cranelift互換サブセット仕様として文書化して、
|
||||
テキスト仕様＋最小リファレンス実装（ダンプ/検証/Cranelift下げ）を私が一気に草案化するよ。どう攻める？（MLIR方言でいくか、Cranelift寄りでいくか）
|
||||
あなた:
|
||||
所で中間言語は何を指標に作ればいいにゃ？メモリー管理はわかるけど好き勝手に作る訳にも行けないにゃ それこそフォンノイマンのパソコンを念頭に考えればいいだけにゃ？CPUの命令セットとか？
|
||||
ChatGPT:
|
||||
|
||||
いい質問にゃ！
|
||||
中間言語（IR/MIR）を“何を指標に”設計するかは、単に「CPUに近づける」だけだと失敗しがち。
|
||||
実務では次の“指標セット”でバランスを取るのがコツだにゃ。
|
||||
まず決めるべき指標（優先度つけてOK）
|
||||
|
||||
ターゲットと目的
|
||||
|
||||
どこに落とす？ → VM / JIT（Cranelift） / AOT（rustc/LLVM） / WASM
|
||||
|
||||
何を優先？ → 起動の速さ、最適化余地、移植性、デバッグ性
|
||||
|
||||
抽象度（レベル）
|
||||
|
||||
高すぎる：最適化しにくい／JIT実装が難航
|
||||
|
||||
低すぎる（CPU寄り）：言語機能の意味が消えて最適化の根拠を失う
|
||||
→ 目安：SSA＋基本ブロック＋3アドレスを軸に、「言語に固有の意味（例: 効果、副作用、所有/弱参照）」は属性や専用命令で残す
|
||||
|
||||
メモリモデル（超重要）
|
||||
|
||||
参照の表現：ref<T>/weak<T>／タグ付き値
|
||||
|
||||
GC/RC hooks：Safepoint、BarrierRead/Write の差し込み位置を規定
|
||||
|
||||
別名・所有：noalias/readonly/owned/borrowed など最適化に効く注釈
|
||||
|
||||
（並行を視野なら）原子性・順序の最小集合（Acquire/Release程度）
|
||||
|
||||
効果システム（副作用の面）
|
||||
|
||||
PURE / READS_HEAP / WRITES_HEAP / IO / FFI / PANIC のEffectMask
|
||||
|
||||
最適化の“安全条件”をここで機械的に判断できるようにする
|
||||
|
||||
制御フローと例外
|
||||
|
||||
CFG＋SSA、Phi/Br/Jmp/Ret
|
||||
|
||||
例外はIRでは抽象（Throw/Catch）、loweringで Result/landingpad 等へ落とせる形に
|
||||
|
||||
呼び出し規約と拡張ABI
|
||||
|
||||
Call/TailCall と FfiCall/BoxCall を分離
|
||||
|
||||
可変長／キーワード引数の表現、Pin/Unpinの扱い
|
||||
|
||||
検証可能性 & ツール性
|
||||
|
||||
Verifierで：型一致・SSA整合・終端命令必須・効果整合をチェック
|
||||
|
||||
テキスト表現（ダンプ）と黄金テスト（差分テスト）を最初から用意
|
||||
|
||||
“CPU/フォン・ノイマンだけ見れば良い？”への答え
|
||||
|
||||
No（それだけでは足りない）。
|
||||
CPU命令セットを直に意識しすぎると、**言語の意味（純粋性・所有・弱参照・例外の契約）**が失われて最適化や検証が難しくなる。
|
||||
|
||||
ただし最終的にそこへ下げやすい形は大事。だから
|
||||
|
||||
上層の意味は 属性/メタで保持
|
||||
|
||||
下層（Load/Store/GEP/Call/TailCall）へ機械的に落とせるカバレッジを確保
|
||||
→ これが “ネイティブに落としやすく、でも言語の意味を保ったIR” のコア指標にゃ。
|
||||
|
||||
具体：設計を導くチェックリスト（配点付き）
|
||||
|
||||
各 0〜2 点で採点してみて。合計が高い案が「良いIR」。
|
||||
|
||||
後段互換性（JIT/AOT/WASMに素直に下がる）
|
||||
|
||||
最適化の根拠（効果・別名・型・所有などが保持される）
|
||||
|
||||
実装容易性（VMでまず回せる／Craneliftへ写経しやすい）
|
||||
|
||||
検証容易性（Verifierで機械的に壊れを検出できる）
|
||||
|
||||
将来拡張（弱参照/GC切替/例外方式変更に耐える）
|
||||
|
||||
可観測性（テキストIR・ソース位置・deopt情報が取れる）
|
||||
|
||||
迷ったらこの“型”に寄せると楽
|
||||
|
||||
骨格：SSA + CFG + 3アドレス
|
||||
|
||||
コア命令：Const/BinOp/Cmp/Phi/Br/Jmp/Ret/Load/Store/Gep/Call/TailCall
|
||||
|
||||
言語特有：RefNew/RefGet/RefSet/WeakNew/WeakLoad/Barrier*/Safepoint + EffectMask
|
||||
|
||||
境界：FfiCall/BoxCall（ABI最小化）
|
||||
|
||||
例外：Throw/Catch（loweringで切替可能）
|
||||
→ これは Craneliftに下げやすく、Rust/WASMにも展開しやすい黄金比にゃ。
|
||||
|
||||
参考までに：3つの設計モード
|
||||
|
||||
Cranelift互換サブセット志向（JIT/AOT重視・実装が速い）
|
||||
|
||||
MLIR方言志向（将来の拡張やツール連携が強い）
|
||||
|
||||
Rust MIR/Swift SIL 風（所有/効果を濃く持つ・言語意味を守りやすい）
|
||||
|
||||
Nyashなら：Cranelift互換サブセット＋言語特有の効果/弱参照/GCフックを足すのがバランス最強にゃ。
|
||||
最後に：失敗しない順序
|
||||
|
||||
目的とターゲット（VM/JIT/AOT/WASMの優先度）を1行で宣言
|
||||
|
||||
Core命令セット＋EffectMask＋メモリモデル（weak/GC hook）を先に固定
|
||||
|
||||
Verifierとテキストダンプ（黄金テスト）を最初に入れる
|
||||
|
||||
VM実装 → Cranelift下げ → AOT/WASMは後から
|
||||
|
||||
この順なら「好き勝手」じゃなく指標に沿って進められるにゃ。
|
||||
必要なら、いまのNyashの要件を点数表で一緒に採点して、MIR v0.1を最終確定しよっか？
|
||||
あなた:
|
||||
おねがいにゃー！
|
||||
ChatGPT:
|
||||
|
||||
任せてにゃ！
|
||||
Nyash向けに「指標の採点 → その結果に沿った MIR v0.1 最終版」を一気にまとめたよ。すぐ実装に落とせる形にしてあるにゃ。
|
||||
指標チェック（Nyash想定で採点済み）
|
||||
|
||||
（各0〜2点、合計12点満点）
|
||||
指標 狙い Nyashの前提 点
|
||||
後段互換性 VM/JIT/AOT/WASMに素直に下げられる まずVM→Cranelift JIT、次にAOT/WASM 2
|
||||
最適化の根拠 効果・別名・所有/弱参照を保持 EffectMask＋ref/weak＋Barrier/SafepointをMIRで表現 2
|
||||
実装容易性 まずVMが回る 命令は3アドレス＋最小集合から 2
|
||||
検証容易性 Verifierで壊れ検出 SSA/型/終端/効果の整合を必須に 2
|
||||
将来拡張 例外・GC切替・FFI拡張に耐える Throw/Catch・BoxCall/FFI・Barrierはno-opで開始 2
|
||||
可観測性 ダンプ/位置情報/Deoptが取れる テキストIR＋dbg(loc)＋deopt_map 2
|
||||
|
||||
合計：12/12（この方針で進めてOKにゃ）
|
||||
Nyash MIR v0.1（最終版）
|
||||
コアモデル
|
||||
|
||||
SSA値 vN、基本ブロック bbN（末尾は終端命令必須）
|
||||
|
||||
型（最小）：i64|f64|bool|unit|ref<T>|weak<T>|ptr|any|option<T>
|
||||
|
||||
効果 EffectMask：PURE|READS_HEAP|WRITES_HEAP|IO|FFI|PANIC（ビット和）
|
||||
|
||||
関数署名：fn(args…)->ret [effects]
|
||||
|
||||
命令セット
|
||||
1) 演算・制御
|
||||
|
||||
Const dst, Imm
|
||||
BinOp dst, op, a, b ; add/sub/mul/div/mod/and/or/xor/shl/shr
|
||||
Cmp dst, rel, a, b ; eq/ne/lt/le/gt/ge
|
||||
Select dst, cond, a, b
|
||||
Phi dst, [(predBB, val), …]
|
||||
|
||||
Br cond, thenBB, elseBB ; 終端
|
||||
Jmp targetBB ; 終端
|
||||
Ret [val] ; 終端（unit省略可）
|
||||
Unreachable ; 終端
|
||||
|
||||
2) メモリ／参照（GC想定）
|
||||
|
||||
Alloc dst, Ty, size? ; [WRITES_HEAP]
|
||||
Load dst, addr ; [READS_HEAP]
|
||||
Store addr, val ; [WRITES_HEAP]
|
||||
Gep dst, base, offset
|
||||
|
||||
RefNew dst, Ty ; ref<T> [WRITES_HEAP]
|
||||
RefGet dst, ref, field ; [READS_HEAP]
|
||||
RefSet ref, field, val ; [WRITES_HEAP]
|
||||
|
||||
WeakNew dst, ref ; weak<T> [PURE]
|
||||
WeakLoad dst, weak ; option<ref<T>> [PURE]（実装都合でREADS_HEAP可）
|
||||
|
||||
BarrierRead ref
|
||||
BarrierWrite ref
|
||||
Pin ref
|
||||
Unpin ref
|
||||
Safepoint
|
||||
|
||||
弱参照の意味論
|
||||
|
||||
WeakNew(r) は所有しない。r がGCで解放されると弱参照は無効化。
|
||||
|
||||
WeakLoad(w) は 生存: Some(ref)／死亡: None を返す（nullを曖昧にしない）。
|
||||
|
||||
3) 呼び出し・例外・拡張
|
||||
|
||||
Call dst, callee, [args...] ; 呼び先の effects を合成
|
||||
TailCall callee, [args...] ; 終端
|
||||
|
||||
BoxCall dst, box_id, fn_id, [args...] ; Nyash拡張Box [FFI|PANIC?]
|
||||
FfiCall dst, sym, [args...], abi ; 外部関数 [FFI|PANIC?]
|
||||
|
||||
Throw val ; 終端
|
||||
CatchBegin dst, handlerBB ; （メタでも可）
|
||||
CatchEnd
|
||||
Assume cond ; 偽ならUB：最適化ヒント
|
||||
Nop
|
||||
|
||||
不変条件（Verifier で必須チェック）
|
||||
|
||||
各ブロックは必ず終端命令で終わる
|
||||
|
||||
型整合：Load/Store/Call/WeakLoad 等の型が一致
|
||||
|
||||
SSA整合：Phi の前任ブロック集合＝到達前任集合
|
||||
|
||||
効果整合：PURE な関数内で WRITES_HEAP/IO/FFI を出さない
|
||||
|
||||
WeakLoad戻りは必ず option<ref<T>>（null直扱い禁止）
|
||||
|
||||
推奨挿入ポイント
|
||||
|
||||
Safepoint：関数入口／各ループ先頭／任意の Call の直後
|
||||
|
||||
Barrier*：はじめは no-op 実装でもOK（将来GC切替のフック）
|
||||
|
||||
テキスト表現（ダンプ例）
|
||||
|
||||
func @main() -> unit [effects=IO] {
|
||||
bb0:
|
||||
v1 = Const i64 1
|
||||
v2 = RefNew Obj
|
||||
RefSet v2, field_y, v1
|
||||
v3 = WeakNew v2
|
||||
v4 = WeakLoad v3 ; option<ref<Obj>>
|
||||
Br is_some(v4), bb1, bb2
|
||||
|
||||
bb1:
|
||||
v5 = unwrap v4
|
||||
BarrierWrite v5
|
||||
RefSet v5, field_y, Const i64 2
|
||||
Jmp bb3
|
||||
|
||||
bb2:
|
||||
Jmp bb3
|
||||
|
||||
bb3:
|
||||
Ret
|
||||
}
|
||||
|
||||
実装ロードマップ（最短で回す）
|
||||
|
||||
IR型 & ダンプ & Verifier を実装（黄金テストに登録）
|
||||
|
||||
VM：RefNew/RefGet/RefSet/WeakNew/WeakLoad と制御命令だけ先に実装
|
||||
|
||||
効果検査：Call に effects 合成（違反はビルド失敗）
|
||||
|
||||
Cranelift JIT 足場：算術・分岐・Call を写経、Ref* はランタイム関数に委譲
|
||||
|
||||
AOT to Rust：ref<T>=Gc<T>、weak<T>=Weak<T> 相当でコード出力（小関数から）
|
||||
|
||||
付録：Rustスケルトン（抜粋）
|
||||
|
||||
bitflags::bitflags! {
|
||||
pub struct Effect: u32 {
|
||||
const PURE = 1<<0;
|
||||
const READS_HEAP = 1<<1;
|
||||
const WRITES_HEAP = 1<<2;
|
||||
const IO = 1<<3;
|
||||
const FFI = 1<<4;
|
||||
const PANIC = 1<<5;
|
||||
}
|
||||
}
|
||||
|
||||
pub enum Ty {
|
||||
I64, F64, Bool, Unit, Ptr, Any,
|
||||
Ref(Box<Ty>), Weak(Box<Ty>), Option(Box<Ty>),
|
||||
}
|
||||
|
||||
pub enum Inst { /* 上述の命令そのまま */ }
|
||||
|
||||
pub struct Func {
|
||||
pub sig: FuncSig, pub blocks: Vec<Block>, /* dbg, deopt_map など */
|
||||
}
|
||||
|
||||
pub fn verify(func: &Func) -> Result<(), VerifyError> {
|
||||
// 終端必須・SSA整合・型整合・効果整合をチェック
|
||||
Ok(())
|
||||
}
|
||||
|
||||
次の一手（今日できること）
|
||||
|
||||
mir/inst.rs にこの v0.1 をそのまま貼り込み
|
||||
|
||||
mir/dump.rs と mir/verify.rs を最小実装
|
||||
|
||||
既存テストに 黄金テスト（IRダンプ） を1本追加
|
||||
|
||||
VMの Ref*/Weak* を実装して 最初の end-to-end テスト を通す
|
||||
|
||||
これで、行き当たりばったりの修正が入っても壊れにくい土台が完成にゃ。
|
||||
必要なら、このままコード雛形まで私が書き起こすよ。
|
||||
Reference in New Issue
Block a user