libffi

NetWalkerがすごく素晴らしい*1ので、x86以外でのmoshをそろそろ真剣に考えるフェーズになってきたように思う。
現状のmoshは、MIPS/PPC32/PPC64/ARMでFFI以外は動く。特にPPC64(というかPS3)ではそれなりに利用実績が有る。
FFIの代わりに、手元のブランチではInternal Function Interfaceを追加している。これは、--enable-developerなしで*2手続きを追加するためのhookで、MinGW版の実験などもすべてこれに依存して行っている。もっとも、Windowsでは既にFFIがサポートされているのでリリースまでにこのhookは廃止される予定。
困るのは、このhookを廃止してしまうとFFIに対応していないアーキテクチャでcairoやlibspe*3等を呼び出せなくなること。hookを残したブランチをメンテナンスしつづけるのも手だが、hookではDynamic bindingが行えないという重大な問題が有るので、libffiを使ってこれらのアーキテクチャでもFFIを使えるようにする。
もっとも、libffiへの移行は既に却下されているので、別ブランチかパッチでのリリースになる予定。

libffiはgccの利用しているFFIパッケージで、基本的には"gccを利用しているOSならほぼ全てパッケージが存在する"といっても過言ではない。(gcj等が依存しているため)

http://repository.readscheme.org/ftp/papers/sw2004/barzilay.pdf

libffiは多くのインタプリタ(PLT Scheme、Python、...)でも採用されている。
libffiはmoshのFFIセマンティクスと互換性が無い。libffiは一旦呼び出しコンテキスト(ffi_cif)を確保する必要が有る。もっとも、呼出し毎にこれらを確保しても大きなオーバーヘッドにはならないように思える(どっちにせよオブジェクトの確保が起きるため)。
moshは単体で自分を完全にビルドできるわけではない*4ため、base libraryやfree-varsの異なる2つのブランチを管理するのは本当にすごく面倒*5な作業になる。そこで、Internal Functionのhookを残したままにし、hookでlibffi関連の機能だけを提供することにする。
原理的にはFFI::Openのような機能は流用できるが、moshのFFIモジュールはファイル名をトランスコードしない*6のでdlopen等もhookによる同様の手法で提供する(パス名のトランスコードなどは全てSchemeのライブラリ側で行う)。一般的なデスクトップ環境が用いるパス("デスクトップ"や"ダウンロード")は日本語を含むことがある*7ので、少なくともdlopenで使うpathは正確にトランスコードされる必要がある。