Design and implementation of Gauche
Shiro Kawai
Scheme Arts, LLC
Gaucheとは (1)
- Scripting用途を重視したScheme処理系
- Embedded scheme engineとしても使用可
Gaucheとは (2)
- R5RS, SRFI
- pthread
- マルチバイト文字
- CLOS風OO w/MOP
開発の背景
ゲーム/CGプロダクションでの経験
- Perlの気軽さ、便利さ、OSとの親和性
- Common Lispの頑健性、スケーラビリティ
- アプリ組み込みの容易さ(Tclとか)
Why Scheme?
- "Bottom to top"
- 上のほう
- 下のほう
- Unixシステムコール
- バイナリ操作
- 性能チューニング
Why 俺処理系?
- 全てのニーズを満たす処理系が無かった
- 既存の処理系をいじるには根本的な変更が必要
開発の経過
- 2001-2002はじめ (〜version 0.5)
- プロダクション内でSTkの置き換え
- R5RS, Module system, Unit testing, Object system, Regexp,
Multibyte handling
- -2004半ば (〜version 0.8)
- Gaucheで実用アプリを書くための基盤
- Documentation, Multithreading, Libraries, Performance tuning
- -2008はじめ (version 0.8.x)
- 実用コードを書きつつ仕様整備
- C API, more libraries
どのくらい使っているか
- Gaucheそのものでサービス提供、納品
- サーバサイド - kahua案件
- 納品の場合、Gauche一式をソースサブツリーに添付
- 開発のワークフローサポートツールとしてGauche使用
- PS2アセンブリチューニング
- ゲームデータフォーマット変換
- 仕様からコードやテストデータ生成
- 日常の使い捨てスクリプト
トレードオフ (1)
- GCはBoehm GC
- 性能と移植性/メンテナンス可能性の両立
- Cルーチンとの親和性
- 実行時にコンパイル+VM
トレードオフ (2)
- コアのランタイムはC
- コンパイラはGauche自身
- 最適化コンパイラ自体を書きやすい
- 当初はCだったがGauche自身の性能が上がってGaucheで書けるようになった
- VMはC
- 性能を出しやすい
- いずれ仕様記述からCを自動生成 (複合insn等)
Cとのインタフェース
- TCO
- 2種類のAPIで対応 (Call-returnとCPS)
- 型変換
- APIはC向け
- stub generatorでScheme界とつなぐ
- いずれはdynamic ffiも (c-wrapper)
VM
- Stack VM
- Frames allocated on stack
- Environment frames moved to heap when captured (closure)
- Continuation frames moved to heap when captured (call/cc)
- No heap-to-stack pointers
コンパイラ
- 3 pass
- Pass 1 - S式→IForm (tree)、マクロ展開
- Pass 2 - 最適化
- Pass 3 - コード生成
性能チューニング
- コンパイラ
- クロージャ変換
- プリコンパイルによるオーバヘッド削減
- VM
- 複合インストラクション (CISC的)
- レジスタスピルに注意
- allocation/GC避け
- アロケートしないプリミティブ
- fast flonum extension
落とし穴
- multiple GC
- signalとfinalizer
- forkとthread
今後の方向性
- ライブラリは全然足りてない
- 機能を上げつつコード量を減らす
- CPAN的ライブラリ集積所
今後の野望
- 型推論 + compiler macro
- method cache
- fast structure access
- arena allocation
宣伝