言語「GAME」との出会い

私が若いころにした仕事の一つに「GAMEコンパイラの開発」がある。まだPCすら世の中になく、NECのTK-80に代表されるむき出しの基板に8ビットのプロセッサと数KBのメモリを乗せただけの「マイコン」と呼ばれるコンピュータしか一般の人には手に入らなかった時代である。

当時、私は（マイコン専門の月刊誌を出していた）アスキー出版に出入りする高校生のバイトだったが、そこで出会ったのが大西博氏によって作られたGAMEという言語とインタプリタである。BASICを簡略化した非常に簡単な言語だった。それまではアセンブラ[1]で書くしかなかったTK-80 の開発環境を格段に良くするものだったのだ。

GAMEの開発効率の良さに惚れ込んだ私は、さっそく（アセンブラでは到底不可能だった）アクションゲームを作り始めたが、たかだか2MHz 程度のクロック数しかないプロセッサで走らせるGAMEインタプリタは極端に遅かった。そこで、まずはGAMEインタプリタの改良から取りかかったのだが、どう頑張っても2倍程度の速度アップしかできず、このアプローチには限界があることがすぐに見えた。そこで私は「コンパイラを作るしかない」と結論付けたのだ。

当時、ミニコンやメインフレーム向けには、高級言語で書いたプログラムを機械語に変換してくれる「コンパイラ」が存在していたが、マイコンで走るコンパイラは存在しなかった。当時の常識から言えば、数KBしかメモリのないマイコンでコンパイラは動くはずがなかったのだ。

しかし、まだ高校生で情報理論の「じょ」の字も知らなかった私は、コンパイラを作るにはマイコンでは力不足なことなどまったく知らなかったのだ。

常識外れのコンパイラ作り

私のアプローチはかなり強引だった。コンパイラ作成において必須とされる構文解析もレジスタ割り当ても最適化もなく、ただひたすらに「1つのステートメントを機械語に置き換える」ことに集中して開発した。それも、ソースコードを1文字ずつ読み込みながら、バイトコードを1バイトずつ逐次生成していくという常識外れのプログラミングだ。

逐次生成なので、ステートメントをまたいだレジスタの活用は不可能だった（というか、試みもしなかった⁠）⁠。変数ごとにメモリを割り当て[2]⁠、代入文の終わりには必ず結果をメモリに格納するようにした。

括弧を含む計算式には苦労したが、スタックに積んでいくことによりなんとか解決した。for ループは、ループの先頭の番地を実行時にスタックに積み、ループの先頭に戻る際には（サブルーチンから戻るときに使う）機械語のret命令でジャンプする、という荒技でしのいだ。

最後まで問題として残ったのがgoto文による飛び先アドレス問題だったが、これはコンパイラを二度走らせることにより、一度目で見つけたアドレスを二度目に使うという乱暴な方法で解決した。

そんな強引な方法だったが、開発を始めて約3週間後には、れっきとしたコンパイラとして実行可能な機械語を生成するようになった。GAMEで記述されたコンパイラ自身をコンパイルできたときには、密かにガッツポーズをしたことを今でもよく覚えている。

TK-80 向けのGAMEコンパイラは、マイコン上で動く世界初のコンパイラとして「月刊アスキー」1979年7月号にソースコード付きで発表された[3]⁠。コンパイラなど高嶺の花だと思っていたホビイストたちには大評判で、さまざまな人により、Tandy TRS-80、Apple II、SHARP MZ-80などに移植された。

車輪の再発明のススメ

あとから考えてみるとずいぶんと無謀なことをしたものだが、無知で無謀だったからこそ「世界初のマイコンで動くコンパイラ」が作れた、という点はとてもラッキーだったと思う。作る前に「まずコンパイラの作り方を勉強してから」などと悠長なことをしていたら、常識にとらわれて「マイコン上でのコンパイラなど無理」と結論付けていた可能性が高い。

今の時代、ネットのおかげでいろいろと便利にはなったが、自分が作ろうとしていたものがすでにあるのを発見することは多いし、新しいものを作ろうとすると「車輪の再発明だ」「⁠誰も必要としていない」などと否定的な意見を浴びせられることもしばしばある。

それが逆に創作意欲を奪ったり、オープンソースのフレームワークに頼ってしかプログラムの書けない「なんちゃってプログラマ」を生み出していることは事実である。フレームワークを使うのもよいが、やみくもに使うのではなく、一度ソースコードを読みこなしたうえで、必要であればよりコンパクトなものを再実装するぐらいの気概で取り組むのがよいと私は思う。必要に応じて車輪の再発明はすべきだし、それによって学べることはたくさんある。