現在地

プログラミング

BASICの拡張法

カテゴリー:

以前68000 Tiny BASICの予約語で書いたように独自の命令を追加していました。

でもソースコードもあり自由に変更できたTiny BASICなどだけでなく、マスクROMが使用されソースコードも無い市販パソコンのBASICの命令拡張も良く行われていました。ちょっとした数十バイト程度のものから本格的なものまで当時の雑誌には頻繁に掲載されていたものです。

以下はある程度知っているN-BASIC, N80-BASICを例に書いてみます。

ところでマスクROMのBASICをどうやって拡張するのでしょう?

BASICによっては要所要所でRAM上の特定番地をCALLするようになっていました。そこは起動時にはRET命令が置かれているので、これを用意したルーチンへの分岐命令に書き換えることで動作に介入することができるのです。これを「フック」と読んでいました。

介入したい個所にピンポイントでフックが無い場合は少し手前のフックから目的個所までのROM内の処理を自分のルーチン内で行ない、さらに戻り番地を調整するなどを行ないます。

SC61860 & SC62015 (その4)

カテゴリー:

一応今回をもってSC61860 & SC62015のシリーズは最後となります。

前回予告したようにテストデータ作成についてです。

ASにはtestsディレクトリ以下にソース(*.asm)と期待値(*.ori)を配置しておいてmake testを実行すると自動テストを行なう機能があります。特にSC62015のようなアドレッシングモードの複雑なものでは新たなモード追加の際に以前のものを壊すリスクがそれなりにあるので、追加のたびに全モードをテストできることは重要です。

で、このテスト用データの作成なのですが......

網羅性の高いテストソースの作成はそれだけで大きなテーマではありますが今回はそこには触れません。

もう一方の期待値のファイルはソースをハンドアセンブルするだけなのですが、(バイナリファイルなこともあり)意外に面倒なものです。

SC61860 & SC62015 (その3)

カテゴリー:

今回は予告通り、SC61860の公式ドキュメントを教えていただいてちょっと修正した件を書きたいと思います。

その1のコメントとしてenakaさんより教えていただいたSC61860のドキュメント、正確にはPC-1350の機械語のドキュメントですが、CPU SC61860の記述がメインになっています。PC-1350も持っているので残りも興味深いのですが、今はあくまでもCPUのマニュアルとして読むことにします。

そもそもこのSC61860というCPU、当初は仕様は非公開だったはずです。PC-1250の時代だと思いますが実機の動作から解析された方がいて、わかってしまったのならということで後から情報が出てきたという経緯だったとどこかで読んだような。今回参考にしている『ポケコン・マシン語ブック』の前の『ポケコン・マシン語入門』だった気がするのですが、残念ながらこの本が行方不明でして確認できていません。今度永田町に読みに行こうかな。

ということで『ポケコン・マシン語ブック』とシャープの資料を比較してみたところ、ちょっとした相違点はあるものの大きな違いはありませんでした。

SC61860 & SC62015 (その2)

カテゴリー:

SC61860対応ができたので、続いてSC62015の対応を進めます。

SC62015はSC61860から一転かなり厄介です。ニーモニック数が少ないのに対し、アドレッシングモードが複雑だからです。

ASはアーキテクチャ共通の動作としてソースの1行をラベル部・ニーモニック部・オペランド部に分割し、さらにニーモニック部によって各デコードルーチンに分岐してくれます。IM6100のようにこのフォーマットが特殊な場合はちょっと面倒ですが、そうでなければお任せにすることができます。

一方でオペランドのパースは自分で書かなくてはなりません。

SC61860のオペランドは定数のみで、定数式の評価ルーチンは用意されているのでほぼ呼び出すだけですみました。

SC61860 & SC62015 (その1)

カテゴリー:

先月、古い友人と食事をしたのですが、そこで話題になったものの一つにシャープのポケコンのCPUがあります。

PC-1261, PC-1350などに使われたSC61860と、PC-E500シリーズに使われたSC62015です。

その後、そういえばASは対応してたかな? と思って確認したところどちらも未対応でした。

するとまた対応作業してみたくなってしまい、資料を探し始めたのですが......

この辺りのアセンブラは最後に弄ってから既に30年以上経過しています。『I/O』『The BASIC』『ポケコンジャーナル』あたりに掲載されていたと思うのですが、目次の公開されていたI/Oはともかく他はどの号に掲載なのか探すのは結構大変です。

そんな中『ポケコン・マシン語ブック』がかろうじて出てきました。SC61860の命令表はこれに記載されていますが、PC-E500発売前のものなのでSC62015は当然載っていません。

モニタのFPU対応

カテゴリー:

NS32081を追加してみたで書いたように、マンデルブロのデバッグ中に必要に迫られてモニタのFPU対応を書き始めたわけですが、一段落したのでここで簡単にまとめておきたいと思います。

トラップとダンプ

最初は当面のデバッグに必要な、トラップが発生したらレジスタを保存し、その内容をダンプする、機能を作りました。

NS32000ファミリはFPUのレジスタを直接メモリに書き込む命令が存在するので保存は簡単です。CPUのレジスタを保存した後にFPUレジスタも保存します。

ダンプも16進で表示するだけなら特に難しいことはありません。NS32081にはステータスのFSRレジスタの他に単精度の浮動小数点数を格納できる32ビットのレジスタがF0~F7の8本あります。これはF0とF1を連結して倍精度の64ビットのL0として使用することもでき、同様にL2, L4, L6と合計4本の64ビットレジスタとしても使用可能です。ダンプ時はF0~F7として表示します。

NS32016ボード(ソフトウェア編)

カテゴリー:

前回プログラムが動き始めたので、例によってUniversal Monitorの移植を行なっています。似ているプロセッサとしてMC68000をベースに、HEXファイル関係については長いアドレスに対応したH8/300Hが元にしています。

現時点でD(ump), G(o), S(et), L(oad), P(unch)の各コマンドが動作するようになっており、引き続きR(egister)の実装を進めているところです。

ということで気付いたことを書いてみようかと思います。

バイトオーダー

NS32000のバイトオーダーはリトルエンディアンなのですが、命令語に含まれる即値やディスプレースメントなどはビッグエンディアンで格納されます。

面白いのはディスプレースメント(絶対アドレッシングのアドレスも含む)は可変長で、最初のバイトの最上位ビットが"0"なら符号付7ビット、上位2ビットが"10"なら符号付14ビット、"11"なら符号付30ビットになることです。

私のOS遍歴(実行環境編)

カテゴリー:

このシリーズは久しぶりですね。

以前私のOS遍歴では使った操作環境について書きましたが、今回はどんな環境向けのプログラミングをしてきたかについて書いてみたいと思います。今回は組み込みOSも含めています。

  1. N/N80 BASIC 【家】
    自宅のPC-8001mk2です。BASICの他、GAME, TL/1, アセンブリ言語などで書いたものも含みます。
  2. N88 BASIC(86) 【学】
    中学のときマイコン部部室(技術科準備室)にあったPC-9801F2向けです。
    当時書いていた程度のものなら十分な速度で実行できたのでこれはBASICのみでした。
  3. CP/M-80 【家】
    これも自宅のPC-8001mk2、アセンブリ言語がメインで、末期にCを少しといった感じでした。

RXの命令を眺めて

カテゴリー:

アセンブラを書いているとどんな命令があるのか全体が見えてきます。

アセンブリ言語で書いても同じではと思うかもしれませんが、その場合はこんな命令無いのかなと探しに行くことはあってもどんな命令があるのか見ることはあまりないように思います。少なくとも私はそうで、新しいプロセッサを初めて触るときはニーモニック一覧を眺めて使い慣れたプロセッサの命令に相当するのはどれかといった探し方をしてしまいます。

そうすると汎用的な命令はわかりますが、知らなくてもプログラムは書けるけど使えば便利(速い)命令は置き去りになります。

一方でアセンブラを書いていると全部の命令に一通り目を通すことになります。動作は知らなくても書けますが、マニュアルに一緒に載っていれば目に入りますし、今回のRXのように別になっていても気になって調べてしまいます。まぁ好奇心の少ない人が仕事として黙々とやったらだめかもしれませんが......

そんなわけでRXの命令を見ているとつくづくC言語(とその派生)を意識した命令セットだなぁと思えるものがあります。

RX用のコードジェネレータ

カテゴリー:

先日買っちゃったRX621ボード、Universal Monitorの移植するにはアセンブラASが使いたいところですが対応していません。どうしようかと思っていましたが......

結局コードジェネレータを書き始めてしまいました。

IM6100対応のような難しさはありませんが、ただひたすらに面倒くさいというのが正直な感想です。

ASのコードジェネレータを書く場合はニーモニック毎にデコーダを用意する必要がありますが、それでは大変なのでオペランドやオブジェクトのビット構成のパターンが似ているものをまとめて楽をするのが一般的です。このまとめたグループ毎にデコーダを書くわけですが、この数がやたらに多いんですね。

私がこれまでに書いたものでは以下のようになります。

ページ