ILogScriptはコンパイラを書くためのスクリプト言語である。多分。大きな特徴は以下のふたつ。
こういうのを使って、楽にコンパイラが書けたらいいなぁ…っていう、そういう物。
今のところ、こういうので実際に確認できるかと。
ILogScriptが他の言語と一味違うのが、これ。
変数内部の値の表現をGCCの値の内部表現に極限まで(予定)近付けることによって、 GCCのインターフェースが直接使えるようになっている。
GCCのインターフェースが直接使えるということは、世界一安定してて、かつ世界一移植性が高くて、 そして、それなりに最適化が賢いGCCのバックエンドの力を存分に発揮できるということなのである。 これさえあれば、何も考えなくても、 ポータブルな最適化コンパイラとなんて、ひょろっとひとひねりなのである。
あと、GCCの内部構造がそれなりにわかって嬉しい。
が、しかし、これには大きな罠があった。GCCのインターフェースはあんまり単純じゃないので、 当初の目的だった、「簡単にコンパイラが書ける」というのは、かなり嘘になってしまったのである。
が、でも、まあ、それも仕方ないと思う。ネタとしては面白いので、僕は構わない。
世界一コンパイラを簡単に書ける言語を目標にして、それなりに色々悩んだパーサのライブラリとかが実装済み。 パーサコンビネータやら、boost.spiritなんかから影響を受けたっぽいものが、一応。
あー、そうです。あなたの言いたいことはわかりますよ。ええ、わかりますよ。 よーするに、 「今のマシンはなんたらかんたらだし、わざわざパフォーマンス上げるために開発効率悪い機械語なんか使う必要ねーよ。むしろ、 動的最適化技術とかの発達でJITコンパイラのほうが速かったりするんだよ。いまさらネイティブコンパイラなんて流行んねーんだよ。」 っていうような話なんだろ!!
それは確かに、遠い未来においては正しいと思うんだけど、その意見に至るにはまだちょっと時期尚早で、 今のところは、まだ、ネイティブコンパイラっていうのは十分に必要かと思う。
まず、一番大事なのは、効率うんぬんではなく、移植性である。 機械語というのは、他のどんな言語よりも移植性が高くなる、可能性がある。ということだ。
まず、問題をデスクトップWindowsだけに絞った場合、機械語実行バイナリにしておけば、 どんな環境でも動く可能性が非常に高い。これは、Javaやら、その他諸々スクリプト言語の比ではない。 exeファイルになってれば、誰でも、実行するだけで、実行できる。これは、重要な点だとは思わんか。
あと、まあ、色々。制限の多いハードウェア上でも動くようにしようと思ったら、 機械語以外に選択肢は無いだろう。
デスクトップ上でも、組み込みでも、移植性を求めるためにはネイティブ実行プログラムにする、 というのは今のところ現実的な答えだと思うのだが。
名前マングリングのルールさえ合わせれば、Cの関数をそのまま呼び出せる。
これって重要だよね。
JITコンパイラが技術の発展で生機械語よりも勝てるようになったとしても、 使用メモリ量で機械語に勝てるわけなんかない。
生機械語というのはね、それがね、電気信号になってね、シリコンがね、半導体がね。そういう話。
と、そんな感じ。あと、 ネイティブ機械語になるDSLがあってもいいんじゃないか、とかそういう後付けの理由も。
ILogScriptはJavaScriptから、わけのわからないプロトタイプのルールを抜いて、 その部分にIO Languageのプロトタイプみたいな考え方を埋めた言語である。
todo: あとで書く
遊ぶ前にコンパイル。
GCCのソースとGCCがコンパイルできる環境が必要。
GCCのバージョンは3.4.xで確認。
ILogのソースを展開、で、ilogっていうディレクトリをGCCソース内のgccディレクトリの中に突っこむ。 で、configureしてmake
./configure --enable-languages=ilog --enable-checking=tree make
enable-checkingは無くても大丈夫だけど、それだと色々厳しい。
で、makeすると、ilog1とilogcができる。これが、ILogScriptインタプリタと、その実行ドライバ。
あとは、適当に実行できるかと。
ILogScriptのチュートリアルみたいなものが書きかけであるので、 そちらも参考までに。