UCSD-PASCALは確かに素晴らしいのですが、これを動かすためにはLanguageCardと呼ばれる拡張カードも必須となりますし、同じApple][で動作するとはいえ、DOSではなくてUCSD-PSystemと呼ばれた独自OSの世界で使う必要があります。PASCALで作ったプログラムをDOSの下で使うという訳にはいきません。

ちょうどUCSD-PASCALを手に入れる頃だと思うのですが、共立出版の月刊誌であるbitの1980年7月号で「Tiny PASCAL 移植のすすめ」というタイトルでTinyPASCALの処理系が記載されました。

bit誌 80/7

基本的にはBYTE誌に記載された記事を元にTinyPASCAL一式をApple][のDOS環境で動作するように移植したものです。

ここでTinyPASCALと呼んでいる処理系はUCSD-PASCALのサブセットで、やはりP-CODEという仮想CPUのマシン語で動作するPASCALコンパイラです。実数型はサポートされておらず整数型のみの処理系です。標準PASCALと比べるとCASE文にELSE節が使えたり、マシン語のサブルーチンを呼ぶことが出来たり、アドレスを指定してメモリに直接アクセスできる機能などが追加されていました。

ところでPASCALを紹介するときには、必ずと言ってもいいくらいPASCALコンパイラはPASCAL自身で記述されているという説明が出てきます。実際このコードがあちらこちらに記載されていたのですが、最初に動作するPASCALコンパイラが無いので、コンパイラの処理を知るために読むだけでした。

この処理系が凄いのは、まずBASIC(AppleSoftBASIC)で動作するPASCALコンパイラとP-CODEインタプリタを用意したことです。これでTinyPASCALを使うことが出来るのですが、インタプリタで動作するコンパイラなんて遅いことこの上ありません。そこでPASCALで記述されたコンパイラをインタプリタで走らせてP-CODEで動作するコンパイラを作るのです。同様にP-CODEインタプリタ自身もコンパイルします。さらにP-CODEをマシン語に変換するプログラムを用意することで、最終的にシステム一式がマシン語で動作するものになるのです。

少々入り組んでいますが、この手順を順に進めればDOS上で動作し最終的にマシン語で動くバイナリを生成するPASCALコンパイラが動作するようになる訳です。専用のエディタがスクリーンエディタではなくて、端末で使われていたような行ベースのものであることは慣れないと使いにくいのですが、慣れてしまえば強力な検索、置換機能はむしろ便利でした。結局、大きなプログラムはBASICのスクリーンエディタでは限界があって使いやすいテキストエディタが望まれていたのですが、今では当たり前のメモ帳の機能であっても当時はなかなか実装するのが大変で、行エディタで我慢というところではありました。

よく出来ていたのがP-CODEデバッガで、仮想CPUのコードを逆アセンブルしたり、シングルステップ実行をすることができました。このあたりは標準のUCSDではサポートされていなかったので、P-CODEを理解するにはとても役立ちました。

この記事にはP-CODEをApple][で動作する6502に変換するだけではなく8080への変換コードも含んでいたのですが、まだZ-80は動かしていなかったこともあり、この時点ではそちらには触れずじまいでした。

さてさて記事は素晴らしいのですが、当時の常としてメディアの配布というのは行われておらず、印刷されたリストをひたすらキーボードから打ち込む必要があります。コンパイラだけでも3段組で3ページ半に及ぶBASICのリストだけではなく、エディタやマシン語変換ルーチン、バイナリのランタイム、そして動作検証用のサンプルコードなど20ページ以上に及ぶコードを入力しなければなりません。これらを友人と手分けして打ち込んだ覚えがあります。手分けと言っても分担するのではなくて、同じ打ち込みをして、結果を比較することで、入力間違いを見つけやすくするのです。三人でやればミスはほぼ無くなります。ひとりで打ち込んでミスを探すのはなかなか絶望する作業で、だいたいにおいて自分でやらかしたミスほど見つけにくいものはありません。

何せソースコードがあるのですから、仕様書なんて無くても動作は確認できます。後は動かしてみれば良いのです。この時点ではDOSで動くコンパイラは他に無かったので、いろいろなプログラムを書いてみた記憶があります。いくつかバグがあったような気もするのですが、分かる範囲で修正していた記憶があります。

ただ書けば書くほど、ハードウェアに対するきめ細かなアクセスや文字列処理の柔軟さ、エラー処理の充実などBASICの良いところを痛感したのも確かです。素敵なプログラミング言語も大事ですが、書いているプログラムがだんだん大きくなり複雑になるにつれ、言語仕様よりもデバッグ環境とライブラリや世の中にある資産の使い回しが大事だと思うようになりました。この後、実に多くのプログラミング言語を使っていきましたが、このあたりは変わっていないように思います。

ヘッダ写真は、以下から使わせていただきました。
https://commons.wikimedia.org/wiki/File:Ouroboros.png