はじめてのにき

_ 抽象化レイヤを重ねる

tcfm聞いてて、beflispの時はLLVM bitcodeからbefungeへの変換を書いてあまりうまくいかなくて

https://github.com/shinh/beflisp/blob/master/bc2bef.cc

8cc=>ELVMの後でLLVM=>ELVMのLLVMバックエンドを書いたので、ふたつの話が混じってるんかなと思った

https://github.com/shinh/llvm/tree/elvm/lib/Target/ELVM

さて、等価な変換でレイヤを重ねてくと、2枚くらい重なったあたりから、1レイヤずつでしか検証してないにも関わらず、2レイヤ一気に重ねても思った通りに動いたりして嬉しい、みたいなことがあると思う。コードのコンパイラなんてのは割とそんな感じで、C言語とマシン語なんて結構抽象度が離れてるのに、なんか動いたりして感動するっていう

ELVMの時のことを考えると、僕が思うに抽象度は

C++ > C > 8cc > マシン語 > ELVM > BF

みたいなイメージだった。抽象度が離れてるところをいきなり直結するのは大変なので、さらにレイヤを重ねたり、既存のプロジェクトにうまく乗っかると割とうまくいく。

そんなわけで最初は8ccに乗っかってセルフホストまでは楽ができた。でもその後、8ccは残念ながらCのフルセットが正しく実装されてるとはいえない感じだったので、もっと色々動かしたいとなると問題が出てきた。

というわけで、やっぱりC言語の処理系としてはだいぶまともな、tinyccあたりからELVMに落とすのが正解だったかな、と思ったけど、しかしどうせならC++とかも動くと楽しいよね、ってことでLLVM=>ELVMをやってみたのだった。

これはまあ、できたと言っていい状態にはなって、一応C/C++のコードを普通にELVMひいてはBFとかで動かせたりするようになった。でももっと色々なプログラムを動かすとなると、8ccの時からあったもうひとつの問題が出てきた。ELVMのヘンな制約、sizeof(char)=sizeof(int)=1みたいなものを考えに入れて既存のコードが書かれてないので、なんかそのままコンパイルしてもあんま動かないじゃん、てなった。

こういう抽象化の漏れってのはレイヤ重ねる時は結構致命的で、C/C++のレイヤなのにsizeof(int32_t)==1とかになってると、まあありとあらゆる問題が出てくる。実際、LLVMより上のレイヤであるところの、clangの方にELVM用のアドホックな変更がいくつか必要になったあたり、この漏れがわかりやすく出てた感じだったかなあと思う

https://github.com/shinh/clang/commits/elvm

もちろん抽象化が漏れてるヘンな環境はそのままにしておいて、移植するソフトウェアをヘンな環境に適合させるのもそれなりに楽しくはあるけど、まあ結構大変。これはなんか方針をミスったかなぁと思っている。実際最初のELVMで8ccを動かした時とかは8cc側への変更が結構大きかった。その後でELVM側に__builtin_xorとかを足す感じで、8ccへの変更を減らしていったりした。下っかわの変アーキテクチャぷりが強すぎると上がすごく不安定になる、ってのはまぁNaClとかもそんな感じだった。まあアレは上に巨大なもの乗せようとしてたってのがあるが

やりなおすとすると、やっぱりレジスタとかは32bit/16bit/8bitの3種類くらいの幅があるべきだったと思う。サポートできないバックエンドではエミュレーションを用意すれば良いだけだし、肝心の(?)BFはサポートできるし。ていうかなによりLLVMへの変更がたぶんすごく小さくなるってのが良いように思う

でも、思い出してみると、maloaderとかもlibcレイヤなんていう抽象化漏れまくるレイヤで切ってるのでガタガタだし(特にFILE構造体が悲劇的)、NaClもずいぶんと不安定な土台だった。なんか不安定だけどバランス取れてるもの作ったり、その不安定なものの上になんか乗せるのが僕は好きなんだろうな……トランプタワー的な

(01:27)