selfhost(pyvm): MiniVmPrints – prefer JSON route early-return (ok==1) to avoid fallback loops; keep default behavior unchanged elsewhere
This commit is contained in:
Selfhosting Dev
@ -1,7 +1,7 @@
|
||||
# Box-SSA Core-15 最終決定
|
||||
|
||||
Date: 2025-08-31
|
||||
Status: **凍結仕様** (Frozen Specification)
|
||||
Status: **固定仕様** (Frozen Specification)
|
||||
Summary: MIR命令セットを真の15個に統一
|
||||
|
||||
## 📊 問題と解決
|
||||
@ -77,4 +77,4 @@ Box-SSA Core-15を聞く
|
||||
|
||||
---
|
||||
|
||||
詳細なAI会議記録は [archives/](archives/) フォルダに保存
|
||||
詳細なAI会議記録は [archives/](archives/) フォルダに保存
|
||||
|
||||
@ -5,7 +5,7 @@ Status: Active Development → LLVM Implementation
|
||||
|
||||
## 🎯 本日の大革命：Box-SSA Core-15
|
||||
|
||||
### MIR命令セット凍結
|
||||
### MIR命令セットの固定
|
||||
- 26命令 → **真の15命令**に統一
|
||||
- すべてのBox操作を**BoxCall**に集約
|
||||
- Everything is Box哲学の完全実現
|
||||
@ -27,7 +27,7 @@ Status: Active Development → LLVM Implementation
|
||||
- Future/Await基本実装
|
||||
- 非同期ランタイム統合
|
||||
|
||||
4. **Box-SSA Core-15仕様凍結** (NEW!)
|
||||
4. **Box-SSA Core-15仕様固定** (NEW!)
|
||||
- MIR 15命令に統一
|
||||
- BoxCall万能化
|
||||
|
||||
@ -57,4 +57,4 @@ Status: Active Development → LLVM Implementation
|
||||
2. **実装統一**: BoxCallに全Box操作を集約
|
||||
3. **戦略転換**: JIT幻想から解放→LLVM直行
|
||||
|
||||
これでPhase 11.5は概念的に完了し、LLVM実装（Phase 11）へ移行準備完了！
|
||||
これでPhase 11.5は概念的に完了し、LLVM実装（Phase 11）へ移行準備完了！
|
||||
|
||||
@ -75,7 +75,7 @@ ChatGPT5は議論の余地なしと判断し、即座にMIR命令の列挙型を
|
||||
|
||||
## 🎉 結論
|
||||
|
||||
> 凍結は "Box-SSA Core-15"。Aの Ref* は捨てる／Bの専用命令は BoxCall に吸収して15個に収斂。これで「簡単さ＝表面の一枚」「速さ＝Lowering/最適化」で分離でき、VMとAOTとFFIを**一本の ABI**で貫けるにゃ。
|
||||
> 固定は "Box-SSA Core-15"。Aの Ref* は捨てる／Bの専用命令は BoxCall に吸収して15個に収斂。これで「簡単さ＝表面の一枚」「速さ＝Lowering/最適化」で分離でき、VMとAOTとFFIを**一本の ABI**で貫けるにゃ。
|
||||
|
||||
## 💻 ChatGPT5の心境
|
||||
|
||||
@ -86,4 +86,4 @@ if (命令数 == 15 && 設計 == "完璧") {
|
||||
}
|
||||
```
|
||||
|
||||
この瞬間、ChatGPT5は「これ以上の議論は時間の無駄」と判断し、無言でコーディングを開始した。エンジニアが最高の設計に出会った時の、最も純粋な反応である。
|
||||
この瞬間、ChatGPT5は「これ以上の議論は時間の無駄」と判断し、無言でコーディングを開始した。エンジニアが最高の設計に出会った時の、最も純粋な反応である。
|
||||
|
||||
@ -46,7 +46,7 @@ Phase 11: LLVM AOT（最高性能への挑戦）← 進行中
|
||||
|
||||
## ⚠️ 注意事項（運用方針）
|
||||
|
||||
- Core‑15 凍結（第三案）: { Const, UnaryOp, BinOp, Compare, TypeOp, Load, Store, Jump, Branch, Return, Phi, Call, NewBox, BoxCall, ExternCall }
|
||||
- Core‑15 仕様固定（第三案）: { Const, UnaryOp, BinOp, Compare, TypeOp, Load, Store, Jump, Branch, Return, Phi, Call, NewBox, BoxCall, ExternCall }
|
||||
- 統一ルール: ArrayGet/ArraySet, RefGet/RefSet, PluginInvoke はBoxCallに一本化（Optimizerで正規化、Verifierで禁止）
|
||||
- バリア方針: 初期はランタイム関数側で安全に処理、型特化Lowering段でIRへ内挿（write barrier）
|
||||
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# Box-SSA Core-15 最終仕様
|
||||
|
||||
Date: 2025-08-31
|
||||
Status: **凍結** (Frozen Specification)
|
||||
Status: **固定** (Frozen Specification)
|
||||
Author: ChatGPT5 + Claude協調
|
||||
|
||||
## ✅ 凍結命令セット（正味15個）
|
||||
## ✅ 固定命令セット（正味15個）
|
||||
|
||||
```
|
||||
{ Const, UnaryOp, BinOp, Compare, TypeOp,
|
||||
@ -111,7 +111,7 @@ slow_path:
|
||||
## 🚦 実装ロードマップ
|
||||
|
||||
### Phase 1: 仕様更新（即時）
|
||||
- [x] このドキュメントで仕様凍結
|
||||
- [x] このドキュメントで仕様固定
|
||||
- [ ] INSTRUCTION_SET.md を更新
|
||||
- [ ] テストの期待値を15に変更
|
||||
|
||||
@ -138,4 +138,4 @@ slow_path:
|
||||
- 最適化の統一的適用
|
||||
- 真の15命令達成
|
||||
|
||||
これが「あほみたいに簡単」で「恐ろしく速い」Nyashの最終形態です！
|
||||
これが「あほみたいに簡単」で「恐ろしく速い」Nyashの最終形態です！
|
||||
|
||||
@ -254,7 +254,7 @@ NyRegisterUserBox(const NyTypeSpec*, const NyMethodSpec*,
|
||||
|
||||
### 最大の課題
|
||||
1. **ABI安定と最適化の両立**
|
||||
- vtable拡張、署名IDの凍結、JITパッチ互換などを「一度決めて長期維持」する難しさ
|
||||
- vtable拡張、署名IDの仕様固定、JITパッチ互換などを「一度決めて長期維持」する難しさ
|
||||
2. **GC協調の完全性**
|
||||
- プラグインのtrace不備がリーク/サイクル残留を引き起こす
|
||||
3. **多様な信頼レベル混在**
|
||||
@ -287,4 +287,4 @@ extern "C" void NyRelease(NyValue); // 即値はno-op
|
||||
1. `nyabi.h`ドラフトと最小実装
|
||||
2. `register_user_box()`の仮実装＋スモーク
|
||||
3. `ny-abi-gen`簡易版（署名→スロット表生成）
|
||||
4. ICのmonomorphic実装→PIC→JITパッチの順に段階導入
|
||||
4. ICのmonomorphic実装→PIC→JITパッチの順に段階導入
|
||||
|
||||
@ -49,7 +49,7 @@
|
||||
- 最初は、コアな組み込み型はRust実装のまま、新しいプラグインや一部のモジュールをC ABI版で実装していくのが安全な進め方でしょう。
|
||||
|
||||
#### 互換性維持とテスト戦略
|
||||
- **ABIインターフェースの凍結:** `nyash_ops` の関数シグネチャとセマンティクス（所有権のルールなど）を一度定義したら、それを厳格に守ることが極めて重要です。
|
||||
- **ABIインターフェースの仕様固定:** `nyash_ops` の関数シグネチャとセマンティクス（所有権のルールなど）を一度定義したら、それを厳格に守ることが極めて重要です。
|
||||
- **大規模なテストスイート:** 移行を成功させるには、テストがすべてを決定します。
|
||||
1. **振る舞いの一致テスト:** 同じNyashソースコードを「Rust ABIのみ」「C ABIのみ」「両者混在」の3つのモードで実行し、出力や結果が完全に一致することを検証するテストスイートを構築します。
|
||||
2. **ユニットテスト:** Cで実装されたABIの各関数（`create_value`, `retain`, `release`など）を、Cのテストフレームワーク（例: `check`）で徹底的にテストします。
|
||||
@ -207,7 +207,7 @@
|
||||
- Con: more moving parts, boundary crossings remain.
|
||||
|
||||
### Concrete Next Steps
|
||||
- Define and freeze a v0 ABI header:
|
||||
- Define and fix (freeze) a v0 ABI header:
|
||||
- Add `api_version`, `struct_size`, `nyash_ctx*`, `nyash_allocator*`, `nyash_status`, `nyash_value` 16‑byte layout, `retain/release`, `lookup_selector`, `call`, `error` primitives, and capability bits.
|
||||
- Scaffold `plugins/nyash_abi_c/`:
|
||||
- Provide a stub provider that returns `NYASH_E_NOT_IMPL` but passes header/version checks; wire it in `nyash.toml`.
|
||||
@ -232,4 +232,4 @@ If you want, I can draft the minimal v0 header (with versioning/capabilities and
|
||||
4. **パフォーマンス最適化** - Tagged Pointers、セレクターキャッシング
|
||||
5. **セルフホスティング実現** - Rust依存を完全に排除可能
|
||||
|
||||
この深い考察により、Nyashのセルフホスティングへの道筋が明確になりました。
|
||||
この深い考察により、Nyashのセルフホスティングへの道筋が明確になりました。
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
Status: planning
|
||||
|
||||
Purpose
|
||||
- Freeze済みのコア仕様を維持しつつ、Nyash側（ユーザーマクロ＋標準ライブラリ）で LoopForm を先に実装し、ループの正規化を言語レベルで確立する。
|
||||
- 固定済みのコア仕様を維持しつつ、Nyash側（ユーザーマクロ＋標準ライブラリ）で LoopForm を先に実装し、ループの正規化を言語レベルで確立する。
|
||||
- Rust側は既存MIR/LLVMの整流を活用（PHI先頭グループ化の不変条件を活かす）。
|
||||
- 実アプリ/自己ホストで磨き込みを進め、言語としての使い心地を上げる。
|
||||
|
||||
@ -12,7 +12,7 @@ Scope
|
||||
- 代表スモーク/ゴールデンの追加（PyVM/LLVMの一致）とPHI健全性チェックの拡充。
|
||||
- Docsの整備（設計・ガイド・運用ポリシー）。
|
||||
|
||||
Out of Scope（凍結遵守）
|
||||
Out of Scope（機能追加ポーズ遵守）
|
||||
- Rust側の大規模なIR変更やバックエンド機能追加はしない（必要最小限のバグ修正のみ）。
|
||||
- 仕様変更は重大不具合を除き行わない。
|
||||
|
||||
@ -25,4 +25,3 @@ Docs
|
||||
- guides/loopform.md（利用者向け）
|
||||
- loopform-design.md（設計詳細）
|
||||
- SCHEDULE.md（開発予定表）
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# Phase 9.10: NyIR v1 仕様・フォーマット・検証器（Copilot実装用タスク）
|
||||
|
||||
目的（What/Why）
|
||||
- NyashのMIRを公開IR（NyIR v1）として凍結し、あらゆるフロントエンド/バックエンドの共通契約にする。
|
||||
- NyashのMIRを公開IR（NyIR v1）として仕様固定し、あらゆるフロントエンド/バックエンドの共通契約にする。
|
||||
- 仕様・テキスト/バイナリフォーマット・厳格検証器・ツール群を整備し、移植性と一貫性を保証する。
|
||||
- 設計の正本は `docs/nyir/spec.md`（Core＋Extの骨子）。本ファイルはCopilotが実装を進めるための具体タスク集。
|
||||
|
||||
|
||||
@ -4,10 +4,10 @@ Status: In Progress（9.79 P2PBox前のゲート）
|
||||
Last Updated: 2025-08-25
|
||||
|
||||
## 🎯 目的
|
||||
P2PBox（Phase 9.79）に着手する前に、MIRパイプライン（Builder/SSA/MIR26/Verifier/Optimizer/VM整合）を完全に安定化し、26命令セットで凍結する。これにより、P2P/Craneliftの土台を強固にする。
|
||||
P2PBox（Phase 9.79）に着手する前に、MIRパイプライン（Builder/SSA/MIR26/Verifier/Optimizer/VM整合）を完全に安定化し、26命令セットで仕様を固定する。これにより、P2P/Craneliftの土台を強固にする。
|
||||
|
||||
## 📦 スコープ（MIRまわりの全タスク）
|
||||
0) 命令セットの凍結（26命令が正）
|
||||
0) 命令セットの固定（26命令が正）
|
||||
- 命令セットの単一出典: `docs/reference/mir/INSTRUCTION_SET.md` を唯一の参照に統一
|
||||
- コード側の列挙とテスト: `src/mir/instruction.rs` の列挙と一致、総数26のテストで保証（ドキュメント≧コードではなくコード≡ドキュメント）
|
||||
- 25命令文献はアーカイブへ移動（本流は26命令）
|
||||
@ -16,7 +16,7 @@ P2PBox（Phase 9.79）に着手する前に、MIRパイプライン（Builder/SS
|
||||
- Loop SSA復帰: `loop_api` によるPhi挿入・seal・predecessor更新の段階適用、簡易lowering除去
|
||||
- TypeOp早期lowering網羅: `is/as/isType/asType` の関数/メソッド両パスで確実に `TypeOp(Check/Cast)` 生成、`print(isType(...))` 直下もdst化
|
||||
|
||||
2) MIR26命令ダイエットの凍結
|
||||
2) MIR26命令ダイエットの固定
|
||||
- TypeOp統合: Check/Castの意味論確定、Printer表示/エフェクト統一
|
||||
- WeakRef/Barrier統合: flag ON/OFFで差分固定（PoC featureで比較可能に）
|
||||
- 命令リストの合意化: 26命令でのPrinter/Verifier/Optimizer整合
|
||||
|
||||
Reference in New Issue
Block a user