やはりZ80のセルフコンパイラはBDS Cが最強だった。

ANSI CのソースをKR&Cのソースに変換するasu ansi2kr を開発中ですが、
Windows版だけではなくCP/M、MSX-DOS版も用意したいと思い、
BDS C V1.60、HI-TECH C(CP/M)、Ver 3.90、MSX-C Ver 1.2でもコンパイルしてみたんですが
MSX-Cは論外のような感じ。
式を分解しないとエラーになるし、関数を小さく分けないとエラーになる。
関数名は6文字までしか区別できないので関数名も短く変えまくりました。
それらをやってコンパイルできるところまで持っていっても生成したバイナリは正しく動作しなかった。
後での追記です、ソースの先頭に#pragma noregaloを書いて且つ MSX-Cのcfに、-t オプションを付けたら正しく動作しました。
#pragma noregaloとcfの-tオプションなしのMSX-Cは爆弾抱えたような状態で使うべきではないですね。
大きなソース修正が必要でしたが一応コンパイルはできたのでなんとか使えないこともないです。
MSXエミュレーターのturboRモードでもMSX-Cは遅いです。
HI-TECH Cはasu ansi2krの最初のバージョンはコンパイルできたんですが処理を追加して少しソースが大きくなったら、”$TMP1.$$$:5561: Too many temporary labels”とエラーが出てコンパイルできなくなった。
ソースを分ければいいんだろうけども、BDS CでコンパイルできているのにわざわざHI-TECH Cのためだけにそんなことはしたくない。

MSX-Cは論外と最初思いましたが、生成したファイルサイズがすごく小さいものができました。
BDS Cよりも5000バイトぐらい小さかった。
今はもうHI-TECH Cではコンパイルできなくなりましたが、コンパイルできたVer 1.0ではBDS CよりもHI-TECH Cのほうが2000バイトぐらいファイルサイズが大きくなりました。
メモリが少ないMSXではファイルサイズは結構重要なんです。
ファイルサイズが大きいということはそれだけ使えるメモリが少ないということです。

Leave a Reply