中間コードを利用した6800用コンパイラ kumajiri
こんな記事を書いて誰が読むのかさっぱりわからないんだけど、書いておかないと記録も記憶も散逸しそうなのでメモとして書いておく。Wikipediaにあっても良さそうなもんだけど、GAME-80の記事すらないので望み薄。
Kumajiriとは
kumajiriは津田伸秀氏により開発されたプログラミング言語。名前は作者の二人の知人の名前に由来する。
ASCII 1980年1月号 TBN (P.116)に「超高速新言語 “KUMAJIRI”誕生」との投稿。まだ開発途上らしく「予定としては、少なくとも今年中に、まともに動くインタープリタを作ります」「KUMAJIRIを用いてコンパイラに作り変える予定です」と書かれている。
ASCII 1980年1月号 TINY BASIC N (P.116)より引用
雑誌I/O 1980年8月号103-123ページに「幻の68系コンパイラ『KUMAJIRI』全リスト公開」が掲載された。当初はH68/TR+H68/TV用であった。後に BASIC MASTER Level2への移植が I/O別冊システムプログラムライブラリ2 (224-242ページ, 1981/6発行、5月上旬刊行)にて行われた。
追記: BMへの移植はI/O 1981/4 C.CATO氏でも発表されていて、同時期に2つの移植が行われたのだと思う。
I/O 1980年8月号 工学社
前史
当時のマイコンでは利用できるメモリ空間が少ない(32-64KB程度)ため、ソースコード・言語解析部に使うメモリを節約するために、予約語を記号で表現した言語も使われていた。VTL(Very Tiny Language – 1970年代後半?)はそのような言語の先がけであり、わずか768バイトのメモリで動作した。
(当時の外部記憶がカセットテープしかなかったことにも留意されたい。フロッピーディスクが普及するのは1980年代から)
VTLの言語仕様を参考に6800 CPU用インタプリタである GAME III(1978年7月号の月刊アスキーにて公開)が開発され、そのソースコードが公開されたことにより GAME言語は 8080, Z80, 6809, 6502 などのCPUに移植された。後にコンパイラも提供され、GAMEは幅広い分野で活用された。ビジネス分野でも使われていたらしい。
kumajiriはGAME言語の使いにくい部分(行番号依存、構造化構文の不足)を補いつつ、少ないメモリでも動作するように考案された(と思う)。
コンパイラのソースコードは200行程度で極めて小さい。
I/O 1980年8月号 工学社
言語仕様
メモリの節約とGAME言語に慣れた利用者の混乱を避けるため、KumajiriはGAME言語の仕様を継承している。例えば、予約語が記号であること、二項演算子の優先順位がないこと、変数名の長さは任意だが先頭1文字のみを識別すること、変数名に添え字をつけることでCのポインタ変数のようなメモリアクセス(1,2バイト単位)が行えること、などである。
当時流行の構造化プログラミング※1を意識してか、以下の制御構造が追加されている。
(Edsger DijkstraのConsidered harmfulが1968年。日本で構造化プログラミングが流行したのはUCSD Pascal(1978)以降だと思う)
- for var=start,end 〜 next ( var=start,end 〜 ¥ )
- if exp ~ else ~ fi ( ;=exp ~ : ~ ; )
- repeat ~ until exp ( @ ~ @=exp )
- while exp ~ wend ( &=exp ~ & )
- ※1 実際、kumajiriが発表されたASCII誌1980年1月号にも、UCSD-Pascalやmicro Pascalの記事が掲載されている
I/O誌1980年8月号112ページから、津田氏による素数プログラムをサンプルとして引用する。
N,Qがポインタ経由の配列アクセス、 / が改行の出力であることに注意すれば理解できると思う。
[code lang="text"]
* PRIME-1 MAR.14.1980
*
N=$4000 Q=1000*2+N
I=2,1000
N(I)=0
¥
K=0
P=2,1000
;=N(P)<0 #=L90;
K=K+1
Q(K)=P
;=P>31 #=L90;
I=P
@
N(I)=-1
I=I+P
@=I>1000
L90.
¥
* PRINT PRIMES
/"PRIMES (UNDER 1000):"/
I=1,K
?(4)=Q(I)
;=I-((I/9)*9)=0 / ;
¥
>=$F107
[/code]
言語処理系
kumajiri compiler 自体が kumajiri で書かれている。kumajiri にはインタプリタが存在しないため、bootstrapは GAMEにて行われたと推測される。
kumajiriは8bit CPUである6800用のコンパイラである。6800CPUにはインデックスレジスタは1本(IX)しかなく、しかもインデックスレジスタで可能な演算はINC(+1)/DEC(-1)のみであった※2。そのためC言語風のポインタアクセスを伴うコードは冗長になりがちであった。また乗除算もサブルーチンコールが必要であり、メモリの少なかった6800でのコンパイラ作成を困難にするものであった。
kumajiriは上記の弱点を補うべく、Kプロセッサと呼ぶスタックベースの仮想CPU(命令体系はK-Codeと命名)と、それを実行する K-Code インタプリタから構成されている。これによりコンパイラのバイナリの大きさは わずか 5KBに押さえられてる。 そのため32KB程度のメモリ空間でコンパイラ自身をセルフコンパイルすることが可能となっている。
(それでもメモリサイズについては、作者によると「とてつもなく大きなもの」(I/O 1980/8 P.103)と書かれている)
また、コンパイルされたオブジェクトの先頭にはインタプリタへのJSR命令が書かれており、筆者によると「見かけ上はコンパイラがあたかも6800のマシン・コードに落としているかのような錯覚におちいります」と書かれている。shell scriptの先頭に #!/bin/sh と書かれているようなもので、先見の明があると思う。
- ※2 これではあまりにも不便なので、後の6801ではABX命令(IX←IX+B)が追加され、6809にも引き継がれた。
Kプロセッサ
Kプロセッサは、プログラムカウンタ・スタックポインタ・アキュムレータの3レジスタを持つ。古典的なスタックマシンだが、スタックトップをアキュムレータとすることで、不要なメモリアクセスを減らしている。
命令は56種類。全て1バイト命令である。命令一覧はI/O誌1980/8 P.108にある。
なお命令のバイト表現については「始めっから命令を1つおきに定義しておけば」(I/O 1980/8 P.106)との記述がある。弘法も筆の誤りというべきか。
バイナリ表現については、I/O誌の記事ではスレッデッドコードを意識していたと思われるが、バイナリコードの互換性・メモリ効率を考えると、スレッデッドコードにしなくて正解だと思う。
参考資料
以下、2ch.netのFORM,WICS,GAME,TL/1..8ビット機の独自言語の投稿から。この手の情報が2chにしか存在しないのが日本的だなーと思う。
66 :ナイコンさん:02/03/25 15:26
KUMAJIRI…
ASCIIの読者コーナー(TBN)でベンチマークが語られて
実際はI/Oに出てたような気がする
津田さんだっけ?作者
6809用でしたっけ…それであまり記憶がないのかな67 :ナイコンさん:02/03/26 02:10
kumajiriの作者は津田さんです。K compilerのKはたぶんKumajiriのK。
で、kumajiriの語源は…内緒 :)I/Oに出てました。文法は構造化GAME言語。6800用で、
コンパイラ-インタープリタ型です。結構画期的だったと71 :ナイコンさん:02/03/30 23:11
>>80KumajiriとK-compilerは別物です。
発表はI/O誌1980年8月号103ページ。
表紙では「幻の68系コンパイラ『KUMAJIRI』全リスト公開」と
紹介されています。作者は津田伸秀さん。文法は構造化っぽいGAME言語。行番号の代わりにラベルを使い、
構造化構文(if-else-then、for-next、repeat-until、while-wend)を
追加したような言語です。72 :ナイコンさん:02/03/30 23:15
71です。ごめん、さっきのは >>70 の間違い。K-compiler って、Kumajiriをちゃんと設計しなおした言語、だったと
記憶しているんですが、資料がでてこないので、もしかしたら
私の記憶違い?73 :ナイコンさん:02/03/31 05:30
KUMAJIRIに関する津田さん本人の投稿がASCII誌80年1月号のDMAにあるんだけど
どうしてI/Oに逝っちゃったんだろ。(結果的には良かったかも)
例によって何ヶ月も投稿を未チェックのまま積んでおかれたのか?174 :津田:2010/09/12(日) 21:18:37
>>67
> K compilerのKはたぶんKumajiriのK。
そのとーり186 :1:2010/09/22(水) 14:26:19
>>184
回答ありがとうございます。
結構いろいろな雑誌に言語を発表されていたと思うのですが、なぜなのでしょうか。
上の方で Kumajiri は ASCII で話が出たけど発表は I/O という書き込みもあり
ました。基本的には全て投稿で、雑誌のカラーに合わせていた等なのでしょうか。さらに質問ですが、K Compiler の文法は BASIC ベースで構造化構文を追加
した感じだと思うのですが、文の区切りはなぜセミコロンにしたのでしょうか。
当時押されていた Pascal の影響?あと、ご自身のページに言語関連の記述がないのが寂しいです。
188 :津田:2010/09/22(水) 15:31:04
>>186
Kumajiri が動き始めたときは、中間言語のインタプリタを作成しただけで、
コンパイラやランタイムなどが不整備だったんです。(ASCII で紹介されたのはこの段階)んで、6809 エミュレータ(on 6800)を開発したんだけど、そのモニタ部分を Kumajiri で
作って、IOに投稿したんですよ。そひたら Kumajiri を是非発表してくれと言われて、
それからコンパイラやランタイムなどを整備して I/O で発表したという次第です。189 :津田:2010/09/22(水) 15:33:34
>>186
> 文の区切りはなぜセミコロンにしたのでしょうか。
C言語の影響だと思います。> ご自身のページに言語関連の記述がないのが寂しいです。
気が向いたら書くけど、当時のソースなど何も残ってないし
若気のいたり(謎)ってことで見逃してくだされ。
リンク
- 30年ほど前のマイコン環境 | ず@沖縄
- 日立ベーシックマスターが帰ってきた | ず@沖縄
- リモートなお仕事募集中でござるぞ (@vivisuke) | Twitter
- History of Very Tiny Language
- 西部労働レストラン
- イスカンダルのトーフ屋ゲーム
お願い
I/O誌1981年4月号にKumajiri/BMの記事があったようです。捨ててしまったようで手元にありません。どなたかお譲りいただけませんか?
無事入手できました。読み返してみるといろいろ忘れていることも多いなあ。昔のラジオの製作や初歩のラジオ、子供の科学も読み直してみたいものだ。
ディスカッション
コメント一覧
これ、高校当時実は結構遊んだんですよ。
当時 PC8001 コンパイラなどが殆どの中で、自分は MB6881 で周囲には仲間はないかった。
で、どのパソコンが早いかって、同じソフト、単純な for next や、5桁の素数を求めるなど、問題を与えて各自でソフトを書く。
同じ思考で処理するにもかかわらず、6800 が Z80 の10倍とかで圧倒したのです。
そりゃそうでしょう。コンパイラですし。
周囲が騒然となったのを今でも詳細に覚えています。
とても懐かしいものの紹介ありあがとうございます。
おいらが読んで、昔を懐かしみ喜んだりします>「こんな記事を書いて誰が読むのかさっぱりわからないんだけど、」