LLVMを使った自作言語に例外を入れることを考えてた。結論からいうとCrystalのソースを真似するのでよさそう。

• Crystal → libunwind → _Unwind_RaiseException
• C++ → __cxa_throw → libunwind → _Unwind_RaiseException

_Unwind_RaiseException等の仕様はここ。http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html

「Itanium C++ ABI」という名前ではあるけれど、Level I, II, IIIのうちのLevel I部分(_Unwind_RaiseException等)はC++に限らない言語独立なAPIになっている。__cxa_throwはLevel IIで、C++用のもの(であるけれど、場合によってはこれが使えることもあるかも)。

先月のエントリでEsquisというプログラミング言語を作っていると書いたが、あれからいろいろ機能を足して、レイトレーシングのプログラムが動くようになった。

できたもの

https://github.com/yhara/esquis/releases/tag/v0.0.1

実行結果

このブログはSinatraで作っていて、テストはRack::Testで書いてたのだけど、思い立ってCapybaraで書き直した。

Rack::Test vs Capybara?

というのはある種のバグがRack::Testだと漏れちゃうんですよね。例えばフォームをsubmitしたときにビューのtypoで正しいリクエストが飛ばない、みたいなやつ。Rack::TestだとこういうPOSTリクエストに対しこういう挙動をする、は書けるんだけど、ボタンを押したときにどういうPOSTが飛ぶか、はCapybaraでないと書けない。

もっと規模が大きければRack::Testでコントローラのテストを書いて、Capybaraでintegraiton testを書いて…みたいな構成もあり得るけど、このブログの場合は規模が小さいのでCapybaraによるE2Eテストだけあれば良いかなと思う。

以下、Rack::Testから移行するに当たって「これどうするんだろ？」ってなったことをメモしておく。

• WebGL と GLSL で気軽にレイトレーシングに挑戦してみよう！ - Qiita

これをRubyに移植した。aobenchが自作言語のターゲットとしてまだちょっと大きいなと思ってより小さいサンプルを探していたのだけど、最後のステップまで移植したら結局aobenchとあんまり変わらないようなものになった。ただaobenchのコードはちゃんと理解していなかったので、少し理解が深まった気がして面白かった。あと画像が出るプログラムはやっぱり楽しい。

ソースはgistに上げた。ray5.rbまであり、それぞれ以下のようになっている。

1. 画像を生成する
2. 球を出す
3. 陰影を付ける
4. 床を出す
5. 反射させる

上に貼ったのはray5.rbの出力結果だ。よく見ると元記事と微妙に球の位置が違うことが分かるが、オリジナルは時間tを受け取ってアニメーションするようになっていて、tの値が違うのが原因と思われる(最初、アルゴリズム部分に間違いがあるのかと思って焦った)。

自作のプログラムで画像を出力したいとき、どのフォーマットを選ぶのが良いだろうか。PNGやJPGなどは広く普及したフォーマットだが、マイナーな言語や自作のプログラミング言語の場合、出力するためのライブラリが存在しない場合がある。

そんなときに役立つのが、aobenchでも使われているPPMという画像フォーマットだ。PPMは仕様が極めてシンプルなので、例えばprintfが使えれば出力することができる。

以下はppmファイルの例である(上記ページから拝借)。

P3
3 2
255

昨年から、Esquisという言語を作っている。Rubyっぽい文法の静的型付け言語になる予定で、実行はLLVM IRを経由して行う。

ということで、(クラスベースの)オブジェクト指向言語をLLVM IRで表現する方法について考えていたので、分かったことをまとめておく。既存の実装としては主にCrystalの生成するLLVM IRを参考にした。

オブジェクトをstructに対応させる

LLVMにはstruct型というものがあり、オブジェクトはこれで表現することができる。問題はどのようなstruct型を定義するかだ。

最初に考えたのは、EsObjという型を作って、すべてのオブジェクトを表現するという方法だ。

去年の夏頃から、BiwaSchemeにsyntax-rulesを入れようと思ってぼちぼち調べてたんだけど、どうもこれは本腰入れて調べないと進捗しないなということで、年末からいろいろ文献を読むなどしていた。

その成果がこちら。

orrというマクロを素朴に展開すると、マクロ内で使っているtという変数名が呼び出し側で定義しているtと衝突してしまう。これを自動でt.0とt.1にリネームしている、という図。

ソースコードはブランチにpushしてある。まだhygenic macroに対応したエクスパンダが本体とは独立に存在するという状態で、最終的にはこれで本体のエクスパンダ(Biwascheme.Interpreter.expand)を置き換えるということになる。

メモ。

LLVM IRは基本的に以下のような構造をしている。

; (レジスタ名) = (命令名) (引数 ...)
%2 = mul i64 %0, %1

ところがコンパイラが生成した.llファイルを見ていると、引数の部分に別の命令が入っていたりする。

%4 = mul i32 ptrtoint (i1** getelementptr (i1*, i1** null, i32 1) to i32), %3

プログラミング言語「PPAP」を作りました。

例

I have 80 Pen
I have 65 Apple

R7RSのマクロシステムはsyntax-rulesだけだが、R6RSにあったsyntax-caseや、いくつかの処理系が実装しているexplicit-renaming, implicit-renamingといったマクロシステムでは、マクロ展開時に任意の式が書ける。

では、マクロ展開時にdisplayを使って文字列を出力した場合、それはどのタイミングで評価されるのだろうか？特にインタプリタじゃなくてコンパイラの場合は？

Chicken Scheme

ということで適当なSchemeコンパイラを用意する。Macだとbrew install chickenでChiken Schemeが入る。マクロシステムはexplicit-renamingがあるようなのでそれを使う。

(define-syntax foo