Files

Selfhosting Dev 53a869136f 📚 ABI統合ドキュメント整理 & LLVM BuilderCursor改善

## ABI関連
- docs/reference/abi/ABI_INDEX.md 作成（統合インデックス）
- 分散していたABI/TypeBoxドキュメントへのリンク集約
- CLAUDE.mdに「ABI統合インデックス」リンク追加
- ABI移行タイミング詳細検討（LLVM完成後のPhase 15.5推奨）

## LLVM改善（ChatGPT5協力）
- BuilderCursor導入でposition管理を構造化
- emit_return/jump/branchをcursor経由に統一
- PHI/terminator問題への対策改善
- より明確なbasic block位置管理

🤖 Generated with [Claude Code](https://claude.ai/code)

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

2025-09-12 14:12:54 +09:00

4.3 KiB

Raw Blame History

Nyash ABI/TypeBox 統合インデックス

このドキュメントは、分散しているNyash ABI関連ドキュメントへの統合入口です。

🎯 現在の実装状態（Phase 15）

実装済み

TypeBox FFI基本構造 - TLVベースの統一invoke_id
struct_sizeフィールド - 前方互換性確保
プラグインローダーv2 - 7個の基本Boxプラグイン動作中

計画中

専用関数追加 - create/destroy/get_type_info
パフォーマンス最適化 - 直接関数ポインタ呼び出し
C ABI完全互換 - 他言語との相互運用性向上

📚 主要ドキュメント

1. コア設計ドキュメント

NYASH_ABI_MIN_CORE.md

最小コアABIとエボリューション戦略

NyrtValue 16B固定表現
struct_sizeによる前方互換性
feature_bits交渉メカニズム
エボリューション・ハッチ（将来拡張への逃げ道）

typebox-api-reference.md

統一TypeBox APIリファレンス

NyashTypeBox C構造体仕様
NyValue型システム
関数ポインタ仕様（create/destroy/invoke_id）
エラーハンドリング・所有権ルール

NYASH-ABI-C-IMPLEMENTATION.md

Nyash ABIをTypeBoxとして実装する革新的設計

"Everything is Box" → ABIもBox
3段階実装戦略（C Shim → フルC → Nyash再実装）
Tagged Pointers・セレクターキャッシング
3大AI（Gemini/Codex/ChatGPT5）による評価

2. 実装詳細

unified-typebox-abi.md

Phase 12統一TypeBox ABI実装計画

移行ロードマップ
パフォーマンス目標（33倍高速化）
互換性維持戦略

PLUGIN_ABI.md

プラグインABI概要

現在のTLVベース実装
プラグイン開発ガイド

3. 現在のソースコード実装

Rust側（ランタイム）

// src/runtime/plugin_loader_v2/enabled/types.rs
#[repr(C)]
pub struct NyashTypeBoxFfi {
    pub abi_tag: u32,
    pub version: u16,
    pub struct_size: u16,    // 前方互換性キー！
    pub name: *const c_char,
    pub resolve: Option<extern "C" fn(*const c_char) -> u32>,
    pub invoke_id: Option<extern "C" fn(u32, u32, *const u8, usize, *mut u8, *mut usize) -> i32>,
    pub capabilities: u64,
}

プラグイン側（C/Rust）

plugins/nyash-string-plugin/
plugins/nyash-array-plugin/
その他基本Boxプラグイン

🔄 ABI拡張方法

1. 構造体末尾に新フィールド追加

pub struct NyashTypeBoxFfi {
    // 既存フィールド...
    
    // 新規追加（末尾に！）
    pub create: Option<extern "C" fn(*const u8) -> u32>,
    pub destroy: Option<extern "C" fn(u32) -> i32>,
}

2. struct_sizeで互換性チェック

let actual_size = (*tb).struct_size;
if actual_size >= expected_size {
    // 新機能使用可能
}

🚀 移行タイミング検討

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

メリット：

LLVMの最適化機会を考慮した設計可能
JIT/AOTでの関数ポインタ直接呼び出し最適化
実行パスが確定してからの最適設計

デメリット：

移行が遅れる
現在のTLVオーバーヘッドが継続

Option 2: 今すぐ段階的移行