一応今回をもってSC61860 & SC62015のシリーズは最後となります。
前回予告したようにテストデータ作成についてです。
ASにはtestsディレクトリ以下にソース（*.asm）と期待値（*.ori）を配置しておいてmake testを実行すると自動テストを行なう機能があります。特にSC62015のようなアドレッシングモードの複雑なものでは新たなモード追加の際に以前のものを壊すリスクがそれなりにあるので、追加のたびに全モードをテストできることは重要です。
で、このテスト用データの作成なのですが......
網羅性の高いテストソースの作成はそれだけで大きなテーマではありますが今回はそこには触れません。
もう一方の期待値のファイルはソースをハンドアセンブルするだけなのですが、（バイナリファイルなこともあり）意外に面倒なものです。
今回は予告通り、SC61860の公式ドキュメントを教えていただいてちょっと修正した件を書きたいと思います。
その1のコメントとしてenakaさんより教えていただいたSC61860のドキュメント、正確にはPC-1350の機械語のドキュメントですが、CPU SC61860の記述がメインになっています。PC-1350も持っているので残りも興味深いのですが、今はあくまでもCPUのマニュアルとして読むことにします。
そもそもこのSC61860というCPU、当初は仕様は非公開だったはずです。PC-1250の時代だと思いますが実機の動作から解析された方がいて、わかってしまったのならということで後から情報が出てきたという経緯だったとどこかで読んだような。今回参考にしている『ポケコン・マシン語ブック』の前の『ポケコン・マシン語入門』だった気がするのですが、残念ながらこの本が行方不明でして確認できていません。今度永田町に読みに行こうかな。
ということで『ポケコン・マシン語ブック』とシャープの資料を比較してみたところ、ちょっとした相違点はあるものの大きな違いはありませんでした。
SC61860対応ができたので、続いてSC62015の対応を進めます。
SC62015はSC61860から一転かなり厄介です。ニーモニック数が少ないのに対し、アドレッシングモードが複雑だからです。
ASはアーキテクチャ共通の動作としてソースの1行をラベル部・ニーモニック部・オペランド部に分割し、さらにニーモニック部によって各デコードルーチンに分岐してくれます。IM6100のようにこのフォーマットが特殊な場合はちょっと面倒ですが、そうでなければお任せにすることができます。
一方でオペランドのパースは自分で書かなくてはなりません。
SC61860のオペランドは定数のみで、定数式の評価ルーチンは用意されているのでほぼ呼び出すだけですみました。
先月、古い友人と食事をしたのですが、そこで話題になったものの一つにシャープのポケコンのCPUがあります。
PC-1261, PC-1350などに使われたSC61860と、PC-E500シリーズに使われたSC62015です。
その後、そういえばASは対応してたかな? と思って確認したところどちらも未対応でした。
するとまた対応作業してみたくなってしまい、資料を探し始めたのですが......
この辺りのアセンブラは最後に弄ってから既に30年以上経過しています。『I/O』『The BASIC』『ポケコンジャーナル』あたりに掲載されていたと思うのですが、目次の公開されていたI/Oはともかく他はどの号に掲載なのか探すのは結構大変です。
そんな中『ポケコン・マシン語ブック』がかろうじて出てきました。SC61860の命令表はこれに記載されていますが、PC-E500発売前のものなのでSC62015は当然載っていません。
先日買っちゃったRX621ボード、Universal Monitorの移植するにはアセンブラASが使いたいところですが対応していません。どうしようかと思っていましたが......
結局コードジェネレータを書き始めてしまいました。
IM6100対応のような難しさはありませんが、ただひたすらに面倒くさいというのが正直な感想です。
ASのコードジェネレータを書く場合はニーモニック毎にデコーダを用意する必要がありますが、それでは大変なのでオペランドやオブジェクトのビット構成のパターンが似ているものをまとめて楽をするのが一般的です。このまとめたグループ毎にデコーダを書くわけですが、この数がやたらに多いんですね。
私がこれまでに書いたものでは以下のようになります。
前回の最後に複合命令の処理がイマイチと書いたのは次のようなことです。
SNL MQASNLはグループ2ですから次のMQAは共通命令テーブルとグループ2の命令テーブルを探すことになります。ところがこれはグループ3なので当然見つかりません。
結果として"unknown instruction"エラーになるわけですが、MQAは存在する命令でただSNLとグループが違っているだけです。"invalid instruction combination"エラーの方がより親切というものでしょう。
そこですべてを1つの命令テーブルに入れることにしました。各命令ごとに複合命令にできるか、できるならどのグループかの情報を付加して組み合わせられるか判定します。
ASでは数多くのエラーメッセージが用意されており大抵はその中から選べるのですが、新たなプロセッサへの対応をしているとどれもしっくりこないことがあります。
そこで3回目の今回はエラーメッセージの追加方法を書いてみます。
IM6100には元になったミニコンPDP-8のコンソールパネルを再現するための特別なモードがあり、そのモードでしか実行できない命令あるいは逆に通常モードでしか実行できない命令があります。これは他のプロセッサにはない概念なので適当なエラーメッセージは存在しません。
これを例にエラーメッセージの追加方法について書いていきます。
まずはエラーの名称（表示内容ではなくプログラム中から参照するときの識別子です）とエラー番号を決めます。ちなみにエラー番号は1000未満だと"Warning", 1000以上だと"Error"として扱われます。
最初はどう決めてよいかわからないと思いますので既存のものを参考にするのが良いでしょう。
これをerrmsg.hに追加します。
第2回目はメモリ参照命令についてです。
IM6100のメモリ参照命令は6つ（うち2つはジャンプ系）しかありません。フォーマットも単純です。
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Op Code (0-5) | IA | MP | Page Relative Address | ||||||||
Op Code部が6の場合は入出力のIOT命令、7の場合はOperate命令（前回の複合命令はこれ）です。
前回楽ではなさそうと書きましたが、基本機能は動くようになりましたのでIM6100対応について数回に分けて書いていきたいと思います。
第1回目は複合命令の処理です。
前回3種類のアイデアを書きましたが最終的にはオリジナルのアセンブラ書式に近い3番目を採用しました。
ASの一般的な処理を知らないとわかりにくいと思いますので、簡単に説明しておきます。
まずSwitchTo_xxxx()関数（これはCPU疑似命令で切り替わったときに呼ばれます）で必要な命令を登録します。特殊な疑似命令が必要ならそれもここで登録します。
AddMR("AND", 00000);
AddMR("TAD", 01000);ここでAddMR()は同じ引数を繰り返すのが面倒で用意したラッパーなので、例えば1行目は以下のように書いたのと同じです。
Nanoprocessor対応はAS-users MLに投げて無事本家にマージされました。
で次は何をやろうかなと考えているわけですが、V60は作者のAlfredさんが取り組んでいるような書き込みがありましたし、TRONは気軽に手を出せるようなシロモノではありません。
HD1-6120ボード（ソフトウェア編）で短ループのテストしただけになっているIM6100 / HD1-6120がASで使えるようになればUniversal Monitor移植も視野に入ってきます。
やってみたいのですが... IM6100系のアセンブラは結構特殊なところがあって楽ではなさそうです。気になる点について実現方法を考えてみました。
やはりIM6100系の特徴といえばこの複合命令でしょう。通常、命令語は機能を表す部分が一つとその対象を表す部分がいくつか（0のこともある）で構成されていますが、IM6100系には機能を表す部分が複数あるのです。
例えばOperate Instruction (Group 3)というグループの命令は以下のようになっています。