ＴＴＬでＣＰＵを作ろう！

~~標準ＴＴＬ~~だけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５３６回］

●デバッグ作業の続きです

前回は、ＰＲＩＮＴ命令の動作をデバッグするために、まずアドレス２３９７にブレイクポイントをセットして、テストプログラムを実行したところ、ちゃんとブレイクしました、というところまで書きました。
アドレス２３９７はＰＲＩＮＴ命令のエントリポイントです。

前回はＢＡＳＩＣプログラムの構造についても簡単に説明をいたしました。
テストプログラムはアドレス８００４から８０Ｄ５にあります。
最初のＰＲＩＮＴ文が書かれている、行番号４０は、８０６８から始まります。

>dm 8000,80d5
8000  41 55 54 4F 00 80 FF DF 10 80 0C 00 B3 53 44 94  AUTO...ﾟ....ｳSD.
8010  40 F4 41 25 00 00 00 85 0A 00 02 00 42 F4 42 25  @.A%........B.B%
8020  00 00 00 85 14 00 02 00 44 F4 43 25 00 00 00 85  ........D.C%....
8030  1E 00 02 00 F0 DF 41 00 00 00 00 85 50 00 04 00  .....ﾟA.....P...
8040  0A 00 08 F2 0C 00 9A FA 7B 00 0D 0B 14 00 08 F2  ........{.......
8050  18 00 9A FA C8 01 0D 0B 1E 00 0C F2 24 00 9A F2  ....ﾈ.......$...
8060  0C 00 2B F2 18 00 0D 0F 28 00 1F 81 22 61 25 3D  ..+.....(..."a%=
8070  22 3B F2 0C 00 2C 22 62 25 3D 22 3B F2 18 00 2C  ";...,"b%=";...,
8080  22 63 25 3D 22 3B F2 24 00 0D 22 32 00 0D 84 F2  "c%=";.$.."2....

前回、ＰＲＩＮＴ命令は中間コードの８１に置き換えられる、という説明をしました。
コード８１はアドレス８０６Ｂにあります。

そこまでを確認していただいたところで、アドレス２３９７でブレイクしたときの、下の画面を見てください。
ＤＥレジスタの値が８０６Ｃになっています。
ＤＥレジスタにはユーザープログラムのアドレスが保持されています。

ユーザープログラムアドレス８０６Ｂのコード８１まで実行が進んで、そこで、ＰＲＩＮＴ命令に分岐してＢＡＳＩＣプログラムアドレスの２３９７でブレイクしたのですが、そのときＤＥレジスタはコード８１の次のアドレス８０６Ｃになっています。
コード８１はすでに「読み終わった」ところなので、ユーザープログラムのポインタの役目をしているＤＥレジスタはその次のアドレスに進んでいるのです。

説明の中で２種類の「アドレス」が出てきます。
ブレイクポインタを設定しながらＢＡＳＩＣシステムプログラムの動作を追いかけるときの「アドレス」は、ＣＰＵが実行する命令アドレスのことでＰＣ（プログラムカウンタ）に入る値です。
下の画面では左側に表示されているＺ８０ＢＡＳＩＣプログラムのアドレスです。

もうひとつの「アドレス」はＤＥレジスタに入れられて、Ｚ８０ＢＡＳＩＣによって解読されながら実行されていくユーザープログラムのアドレスです。
こちらも「プログラム」と表現しますが、Ｚ８０ＢＡＳＩＣから見ると、「データ」に過ぎません。

ＰＲＩＮＴ命令の動作をデバッグする作業は、Ｚ８０ＢＡＳＩＣの実行をトレースしながら、ユーザープログラムが解読され実行されていくところを確認する作業です。

ということで、ここから先はＪＰ命令などの分岐点にブレイクポイントをセットして、少しずつ実行させながら、ＰＲＩＮＴ命令の動作をチェックしていきます。

２３９７でＰＲＩＮＴルーチンにエントリした後の最初の分岐は２３Ａ１のＪＰ　ＮＺ命令です。
下の画面で、
ｂｐ　２３ａ１
でブレイクポイントをセットしたあと、
ｒｔコマンドを入力しています。
ｒｔコマンドはブレイクしたアドレスからデバッグ中のプログラムに戻って続きを実行するコマンドです。
ｒｔはｒｅｔｕｒｎを意味しています。

すると２３ａ１でブレイクしました。
この直前のＣＰ命令でＡレジスタの値が２３であるかどうかを比較しています。
Ａレジスタにはさらにその前のＣＡＬＬ　ＰＲＮＴＥによって、次のユーザープログラムのコード（ＤＥレジスタに入っているアドレス８０６Ｃのデータ）２２が読み込まれています。
コード２２はＰＲＩＮＴ文の文字列データの開始を示す、”（ダブルクォーテーション）です。
いよいよここから、文字列データの検出と表示の動作に入ります。

ブレイクポイントを設定しないでテストプログラムを実行させたときは、画面に何も表示しないでハングアップしてしまったわけですから、これからあとの動作を追及していけば、その原因がわかるはずです。

アドレス２３ａ１はＪＰ　ＮＺ命令ですが、ここでブレイクしたときは、まだＪＰ　ＮＺ命令は実行されていません。
実行される直前にブレイクしています。
そこで右のフラグの詳細を見てみますと、Ｚフラグは立っていません。
Ａレジスタの値は２２で、それを２３と比較したのですから、当然不一致です。
ＣＰ命令では一致したときはＺフラグが立ちますが、不一致のときはＺフラグはオフになります。
Ｎｏｔ　Ｚｅｒｏですから、ここでｒｔコマンドを実行することによって、ブレイクして中断されていたＢＡＳＩＣプログラムに戻って、ＪＰ　ＮＺ，ＰＲＩＮＴ０が実行されると、その結果は、ＰＲＩＮＴ０にジャンプすることになります。

ＰＲＩＮＴ０はアドレス２３Ａ８です。
ここにジャンプすることは間違いありませんから、すると、その次の分岐はアドレス２３ＡＤのＪＲ　ＮＺ，ＰＲＮ３３です。
そこで、
ｂｐ　２３ａｄ
と入力したあと、
ｒｔ
を実行します。

ここでもＡレジスタの値と５Ｃとを比較しています。
不一致ですから、次はＰＲＮ３３にジャンプすることになります。
すると、その次の分岐はアドレス２３Ｃ２のＪＰ　Ｃ，ＰＲＮＴ４ですから、ここにブレイクポイントを設定して、またリターンします。

ｂｐ　２３ｃ２
ｒｔ

です。

すると、今度はレジスタの値が変化しました。
ＤＥレジスタが８０７１になっています。
もう一度ユーザープログラムのダンプリストを見てみましょう。

8060  0C 00 2B F2 18 00 0D 0F 28 00 1F 81 22 61 25 3D  ..+.....(..."a%=
8070  22 3B F2 0C 00 2C 22 62 25 3D 22 3B F2 18 00 2C  ";...,"b%=";...,

さきほどまでのＤＥレジスタの値は８０６Ｃでした。
ＰＲＩＮＴ文の最初の文字列データの始まりを示す　”　の位置にありました。
今回のＤＥレジスタの値は８０７１です。
文字列データの終わりの　”　の次のアドレスです。

ということは、文字列データの”ａ％＝”のところを読み取ったわけです。
ＨＬレジスタを見てみますと、８０６Ｄになっています。
文字列の最初の文字　ａ　のあるアドレスです。
そしてＣレジスタには文字列　ａ％＝　の文字数を示す０３が入っています。
実はこの直前に実行されたＣＡＬＬ　ＬＥＴＳ２は、文字列の処理ルーチンなのです。

ＬＥＴＳ２の実行によって、文字列が検出されなかったときはＣフラグがセットされます。
今回は文字列が検出されましたから、Ｃフラグはセットされません。
アドレス２３Ｃ２のＪＰ　Ｃ，ＰＲＮＴ４はパスされますから、その次のアドレスに進みます。
すると次の分岐はアドレス２３ＣＢのＪＰ　ＮＺ，ＰＲＮ３４ですから、今度はここにブレイクポイントをセットしてリターンします。

ｂｐ　２３ｃｂ
ｒｔ

です。

あれえ？
ａ
が表示されたあと、ブレイクしました。
ＡＤＩＳＰはＡレジスタの値を文字コードとみなして、それを画面に表示するルーチンです。
プログラムを見ますと、ＨＬレジスタで示すメモリの値をＡレジスタに入れたあとでＡＤＩＳＰをＣＡＬＬしています。
そのあとＨＬを＋１して、Ｃレジスタを－１しています。
Ｃレジスタが０になるまで、その動作が繰り返し実行されます。

ブレイクポイントを設定しないで普通に実行させたときは、何も表示しないでハングアップしてしまったのに、ステップ動作をさせて追及してみましたら、画面にポロリ、と文字　ａ　が表示されてしまいました。

プログラムのデバッグをしていますと、こういう信じられない現象に遭遇して悩まされることがよくあります。
さてさてこれはいったいどうしたことでしょう。
むむ。さてはまた、たぬきかあるいはきつねのいたずらか？
２０１０．６．２８ｕｐｌｏａｄ

前へ
 次へ
 ホームページトップへ戻る