suffixesに気をつけろ

COINS

jarを単体で取り出しても動く、でも、IDE上では正常な動作をしない。追いかけようにもブレイクポイントにも引っかからない。半日悩みましたが、こういうコトでした。

の、最後。

　サフィクス規則とは、「どのサフィクスを持つファイルに対してどの処理を行なうとどのサフィクスを持つファイルが生成されるか」を記述した規則である。 COINS は、 C, Fortran, Java に対応しているデフォルトのサフィクス規則ファイルを提供している。
　デフォルトでは、ライブラリ・ディレクトリの下の `suffixes というファイルがサフィクス規則ファイルとして参照される。サフィクス規則ファイルが見つからない場合は、下記の内容がデフォルトとして使用される。

#SRD, 2, Suffix rule DB file, format version 2
c, C, C source, i,s,o
i, C, preprocessed C source, -,s,o
cc/cpp/cxx/C, C++, C++ source, ii,s,o
ii, C++, preprocessed C++ source, -,s,o
java, Java, Java source, -,class,-
java(native), Java, Java source (native compile), -,s,o
f, FORTRAN, FORTRAN source, -,s,o
S, Assembler, assembly source (need preprocess), s,-,o
s, Assembler, assembly source, -,-,o

　このファイルの文法の詳細は、 coins.driver.SuffixFactory.java に記述されているが、おおむね、
サフィクス, 言語名, 意味, プリプロセス後/コンパイル後/アセンブル後のサフィクスという構造になっている。

おお、ソースをいくら書き換えても反映されないわけだ。jarにアーカイブしたバイナリがソースの側の設定を元に動くのも納得。「suffixes」というファイルを見るのね。コピーしてなかったよ、そのファイル。
というわけでソースを書き換えるのはやめてsuffixesを書き換えるようにしてJavaクラスファイルを読むようなフロントエンドを作成。HIRがdata領域を触ってしまわないよう気をつけながらCのソースをはき出すように。言語名は2カラム目ですね。忘れないようにしないと。あと、ターゲットを全部「-」にすると、全くコンパイルされずにスルーするので気をつけよう。最低限どこかにsを入れておかないとHIRにすらならないという。
JavaだのC++だのあるけど、実際のフロントエンドはないっぽい。ま、あっても使えないけど。
そういえば、しみじみ考えると、直接armのelfはき出すんだよな、このCOINS。もっとも、実機では動くかもしれないけどエミュレータが対応してないのでCのソース止まりで。
あ、HIR2Cに手を入れてヘッダファイルを書かないとプロトタイプ宣言と実際の関数のシグネチャが合わなくなりそうだな。
あと、わざわざ-coins:hir2c=newと-coins:stopafterhir2cを指定しないと、ディフォルトではsparcのアセンブラをはき出すので、あまりに見慣れないマシン語のニーモニックに一瞬頭が白くなりました(アセンブラ、リンカ、プリプロセッサはgccのを流用している)。ああ、sparcね。あったね、むかし、そんなCPUも(昔話扱いかい)。
しかし、

とまぁ、結構いろんなCPUに対応しています。LIRから直接Javaバイトコード吐けそうな感じもするんだけどなー。もっとも、elfの形にリンクされても全然うれしくないか。時間があったらS式のリハビリのために書いてもいいな。リンカの代わりにclassファイル生成器作って。
そういえば、いかにもありそうなIA-64が入っていなかったのは単に「研究するにはハードが高い」という理由なんだろうな。AlphaがあってHP-PARISCがないとか、MC68000やMC88000が無いのは当然としても。むしろ、Alphaがあるのがびっくりというか。
そうそう、LIRからマシン語に落とす際のTMD(Target Machine Description)がS式なのもちょっとびっくり。わざわざシェルスクリプトをかませてJavaのソースに落とし込むという。ついでに教科書にはわざわざ(関数型言語以外ではあまり使わないと思われる)末尾再帰のための最適化に1章割かれているのがLISP好きを物語りますね。