復活！ＣＰ／Ｍ　ワンボードマイコンでＣＰ／Ｍを！
ＣＰ／ＭがＴＫ−８０互換のワンボードマイコンの上で復活します
ＮＤ８０Ｚ�VとＭＹＣＰＵ８０の上でＣＰ／Ｍが走ります！

［第８１回］


●ファンクションコール０６（Ｅ＝ＦＥ）のデバッグ（２）

前回からの続きです。
ブレーク中にレジスタを書き換えるにはＣＲ（チェンジレジスタ）コマンドを使います。
この操作はちょっとログファイルでは再現がむつかしいので、画面コピーで説明をすることにいたします。

ＣＲ［Ｅｎｔｅｒ］と入力すると、ブレークしたときと同じようにレジスタダンプが行なわれます。



一見すると全く同じように見えます。
上側がブレーク後のレジスタダンプで、下側がＣＲコマンドによるレジスタダンプです。
しかし、ブレークしたときのレジスタダンプと違って、ＣＲコマンドによるレジスタダンプの場合には、表示後にプロンプトマーク（＞）が表示されません。
カーソルマーク　＿　だけが表示されています。
ＣＲ（チェンジレジスタ）モードの実行中であることを示しています。

［↑］［→］キーを使ってカーソルを変更したい値のところまで移動します。



今回はＡレジスタの値を書き換えますから、Ａレジスタの値２０のところまでカーソルを移動します。

そこで数値を入力します。



’ａ’の文字コード６１を入力しました。

書き換えが済んだら、そこで［Ｅｎｔｅｒ］を入力します。



下に変更後のレジスタダンプが表示されます。
今度はその下にプロンプトマーク＞が表示され、ＣＲモードを終了したことを示しています。

今回はＡレジスタを書き換えましたが、他のレジスタも同じようにして変更することが可能です。
また同時に複数のレジスタを変更することもできます。
２つ以上のレジスタの値を変更するときは、１レジスタ毎に［Ｅｎｔｅｒ］を入力する必要はありません。
必要な変更を全て行なった後、最後に［Ｅｎｔｅｒ］を入力すれば、そのときに表示されているままの値が全て入力されます。
ＰＣ（プログラムカウンタ）やＳＰ（スタックポインタ）も変更することができますが、不用意に変更すると、ＲＴ［Ｅｎｔｅｒ］を入力したときに暴走してしまうこともありますから、十分理解した上ですることが必要です。

さて、これでＡレジスタの内容を変更して、文字’ａ’が入力されたことにしましたから、次のブレークポイントを設定します。
前回はアドレスＤ２９７でブレークしました（下にプログラムリストを再掲します）。

; ;CONSOLE STATUS ; D28F 3E07 CONSTJ:LD A,07 D291 CDAB10 CALL SOUT D294 CDAE10 CALL SIN D297 FE20 CP 20H D299 C29ED2 JP NZ,CONSTJ2 D29C AF XOR A D29D C9 RET D29E 3207BB CONSTJ2:LD (CONSTDT),A D2A1 F601 OR 01 D2A3 C9 RET ;

ブレーク中にＡレジスタの値を２０から６１に書き換えました。
Ｄ２９７ではＡレジスタの内容と２０Ｈが比較され、不一致ならばその次のＪＰ　ＮＺ命令が実行され、一致すればパスされます。
そこで次のブレークポイントをＤ２９９に設定します。

>bp d299 >rt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC 6122 00FE D1FE C6D4 0044 0000 0000 0000 D299 C73F 0044 F1A1 FF 00100010

ＢＰ　Ｄ２９９［Ｅｎｔｅｒ］で、次のブレークポイントをアドレスＤ２９９に設定しました。
ＲＴ［Ｅｎｔｅｒ］と入力すると、実行が再開され、直後に次のブレークポイント（アドレスＤ２９９）でブレークして、レジスタダンプが行なわれました。
ＰＣには現在のプログラムカウンタの値が表示されています。
Ｄ２９９になっています。

Ｄ２９７のＣＰ　２０Ｈが実行された直後にブレークしましたから、Ａレジスタの６１Ｈと２０Ｈが比較された結果、Ｚ（ゼロ）フラグはオフ（０）になっています。

ということはこのあとＤ２９９のＪＰ　ＮＺ，ＣＯＮＳＴＪ２が実行されますから、ＣＯＮＳＴＪ２（アドレスＤ２９Ｅ）にジャンプするはずです。

ここでまずいことをしてしまったことに気が付きました。
そのあとのＤ２Ａ１ではＯＲ　０１が実行され、その結果Ａレジスタのビット０が１にされます。
しかしさきほどＡレジスタの値を変更して設定した６１Ｈはもともとビット０が１になっています。
６１Ｈは０１１００００１です。
せっかくのデバッグですから、そのようにＡレジスタの値が書き換えられるところもお見せすることができるといいなあ、と思いました。

この時点ならまだ間に合いますから、Ａレジスタの値を６１Ｈから６２Ｈに再変更することにしました。
６２Ｈは０１１０００１０ですから、ビット０は０です。

さきほどと同じようにしてＣＲコマンドでＡレジスタの値を６１Ｈから６２Ｈに書き換えました。



そうしておいて、次のブレークポイントをＤ２Ａ３に設定します。
もう一度プログラムリストをお見せします。

; ;CONSOLE STATUS ; D28F 3E07 CONSTJ:LD A,07 D291 CDAB10 CALL SOUT D294 CDAE10 CALL SIN D297 FE20 CP 20H D299 C29ED2 JP NZ,CONSTJ2 D29C AF XOR A D29D C9 RET D29E 3207BB CONSTJ2:LD (CONSTDT),A D2A1 F601 OR 01 D2A3 C9 RET ;

今はアドレスＤ２９９でブレークしています。
ゼロフラグがオフですからこのあとＤ２９９のＪＰ　ＮＺ，ＣＯＮＳＴＪ２が実行され、ＣＯＮＳＴＪ２（アドレスＤ２９Ｅ）にジャンプします。
そのあとの最後のＲＥＴ命令のアドレスＤ２Ａ３にブレークポイントを設定します。

>bp d2a3 >rt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC 6324 00FE D1FE C6D4 0044 0000 0000 0000 D2A3 C73F 0044 F1A1 FF 00100100 >cm bb07 BB07 62-

ＢＰ　Ｄ２Ａ３［Ｅｎｔｅｒ］で、次のブレークポイントをアドレスＤ２Ａ３に設定しました。
ＲＴ［Ｅｎｔｅｒ］と入力すると、実行が再開され、次のブレークポイント（アドレスＤ２Ａ３）でブレークして、レジスタダンプが行なわれました。
ＰＣには現在のプログラムカウンタの値が表示されています。
Ｄ２Ａ３になっています。
Ａレジスタは、ＯＲ　０１が実行された結果６３になっています。
そのように変更される前の値は、ＬＤ　（ＣＯＮＳＴＤＴ），Ａの実行でＣＯＮＳＴＤＴ（アドレスＢＢ０７）に保存されたはずです。
ＣＭ（チェンジメモリコマンド）でアドレスＢＢ０７の値を確認してみました。
ＣＭ　ＢＢ０７［Ｅｎｔｅｒ］です。
ＢＢ０７の値は６２になっています。

さて、ここから先なのですが。

●ＲＥＴ命令を実行したときの戻り先は？

今ブレークしているのは、アドレスＤ２Ａ３です。
このあとはＲＥＴ命令が実行されることになりますが…。

ＪＰ命令なら次にどこにいくのかがわかります。
しかしＲＥＴ命令の場合、どこに戻るのか（どこからコールされたのか）がわからなければ、次のブレークポイントをどこに設定したらよいのかわかりません。

どうしたら、ＲＥＴ命令を実行したときの戻り先がわかるでしょうか？

それはＲＥＴ命令の動作を理解すれば見えてきます。
ＲＥＴ命令の動作は、スタックから戻り先のアドレスをプログラムカウンタに戻して、そこにジャンプします。
これはＣＡＬＬ命令の動作と対になった動きです。
ＣＡＬＬ命令は、その次のアドレス（つまりサブルーチンから戻ってくることになるアドレス）をスタックに入れて、指定先にジャンプします。
そこがＣＡＬＬ命令とＪＰ命令の違いなのです。

もう、おわかりのことと思います。
そうです。
スタックを調べれば、戻り先がわかるのです。

レジスタダンプのＳＰを見てください。
スタックポインタです。
Ｃ７３Ｆになっています。

あれえ？
でも、マシン語モニタのデバッグでも、スタックを使ってしまっているのではないの？
それじゃスタックの内容が変えられてしまっているのでは？

いいえ。
ブレークポイントでブレークしてユーザープログラム（ここではＣＰ／Ｍシステムプログラム）からマシン語モニタに制御が移った直後に、スタックアドレスもマシン語モニタ用のスタックアドレスに切り換えて、その直前のＣＰＵレジスタの全ての内容とともに、ユーザースタックの内容もそのまま保存するように、マシン語モニタはプログラムされているのです。
ですからブレークしたあとで、マシン語モニタのコマンドを使ってデバッグ作業を行なっても、ユーザープログラムのそれまでの実行環境は破壊されずにそのまま残っているのです。
よく考えてありますでしょう。

さて、それでは、そのスタックの内容を見てみることにいたします。
スタックはメモリに置かれていますから、ＤＭコマンドを使います。
ダンプメモリです。
ＳＰ（スタックポインタ）はＣ７３Ｆになっています。
そこでＣ７３Ｆ前後のメモリ範囲として、アドレスＣ７３０からＣ７４Ｆをメモリダンプしました。

ＤＭ　Ｃ７３０，Ｃ７４Ｆ［Ｅｎｔｅｒ］の実行です。

>dm c730,c74f C730 10 A6 06 81 11 10 10 A6-06 81 11 FE 00 D4 C6 74 .ｦ.....ｦ.....ﾔﾆt C740 D1 00 00 FE D1 00 00 21-0B C4 5E 23 56 EB E9 0C ﾑ...ﾑ..!.ﾄ^#V...

現在のスタックポインタの値がＣ７３Ｆですから、ここでＲＥＴ命令が実行されると、Ｃ７３ＦとＣ７４０の内容がＰＣ（プログラムカウンタ）に入れられます。
Ｃ７３Ｆは７４、Ｃ７４０はＤ１です。
ＲＥＴ命令の実行後はアドレスＤ１７４にリターンするということがわかりました。

そこでＤ１７４に次のブレークポイントを設定することにします。

>bp d174 >rt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC 6324 00FE D1FE C6D4 0044 0000 0000 0000 D174 C741 0044 F1A1 FF 00100100 >cm d1de D1DE 00-

ＢＰ　Ｄ１７４［Ｅｎｔｅｒ］で、次のブレークポイントをアドレスＤ１７４に設定しました。
ＲＴ［Ｅｎｔｅｒ］と入力すると、実行が再開され、次のブレークポイント（アドレスＤ１７４）でブレークして、レジスタダンプが行なわれました。
ＰＣには現在のプログラムカウンタの値が表示されています。
Ｄ１７４になっています。

ところで、Ｄ１７４にはどのようなプログラムが書いてあるのでしょうか？
アセンブルリストＣＰＭ２２Ｊ．ＰＲＮの、その部分です。



Ｇｅｔ　ｈｅｒｅ　ｔｏ　ｒｅｔｕｒｎ　ｔｏ　ｔｈｅ　ｕｓｅｒ．
というコメントがついています。

なるほど。
ここからユーザーのプログラムにリターンしていくわけです。

ところで。
アドレスＤ１７４の前（Ｄ１７３）の命令はＣＡＬＬ命令ではありません（ＲＥＴ命令）。
さきほどは、「ＣＡＬＬ命令は、ＣＡＬＬ命令の次のアドレスをリターン先アドレスとしてスタックにＰＵＳＨし、ＲＥＴ命令はそれをＰＯＰしてプログラムカウンタにセットすることでリターン先に戻ってきます。」という意味の説明をしました。
しかしＤ１７４を見ると、その前にはＣＡＬＬ命令は無いことがわかります。

おそらく。
ファンクションコールのいろいろなルーチンは、ＣＰ／Ｍ内部ではＣＡＬＬ命令で呼び出されるのではなくて、ＪＰ命令を使った特殊な分岐で処理されていると思われます。
そしてユーザープログラムへの戻り先として、Ｄ１７４をスタックにＰＵＳＨしてから、それぞれのファンクションにジャンプしていると思われます。
それはたとえば、
ＬＤ　ＨＬ，０Ｄ１７４Ｈ
ＰＵＳＨ　ＨＬ
で実現できます。

それはそうとしまして、Ｄ１７４のプログラム内容は？

●コンソールステータスが得られなかった理由

なんと、思わず、あっと驚いてしまうようなプログラムでありました。

Ｄ１７４　３ＡＤＥＤ１　　　ＬＤ　Ａ，（ＡＵＴＯ）

何をやっているのでしょう？
ＡＵＴＯの内容をＡレジスタに入れています。
Ａレジスタ？

ちょっと待って。
Ａレジスタには、コンソールステータスが入っていたはず…。
駄目じゃないの。
これじゃあ、Ａレジスタにセットされている、せっかくのコンソールステータスの値が、破壊されてしまうじゃありませんか。

これで、やっとコンソールステータスが取得できないわけがわかりました。

ま。
しかし。
せっかくここまでブレークポイントを設定しながらデバッグしてきたことでもありますから、念の為に、この先まで進めてみることにいたします。

その前に。
ＡＵＴＯの中味を確認しておくことにいたしましょう。
ＡＵＴＯは、上のリストで見るとアドレスＤ１ＤＥです。

>cm d1de D1DE 00- >bp d177 >rt A F B C D E H L A'F' B'C' D'E' H'L' PC SP IX IY I SZ H PNC 0024 00FE D1FE C6D4 0044 0000 0000 0000 D177 C741 0044 F1A1 FF 00100100 >

ＣＭ　Ｄ１ＤＥ｛Ｅｎｔｅｒ］で確認をしました。
００が入っています。
むむ。
これがＡレジスタに入れられてしまうので、いつも「キー入力無し」になってしまうのですね。

ＢＰ　Ｄ１７７［Ｅｎｔｅｒ］で、次のブレークポイントをアドレスＤ１７７に設定しました。
ＲＴ［Ｅｎｔｅｒ］と入力すると、実行が再開され、次のブレークポイント（アドレスＤ１７７）でブレークして、レジスタダンプが行なわれました。
ＰＣには現在のプログラムカウンタの値が表示されています。
Ｄ１７７になっています。
そしてＡレジスタの値は、００になってしまいました。

これはおそらくＣＰ／Ｍ２．２のバグだと思います。
地図を頼りにドライブしていたら、その先が突然池になっていた、ようなものです。
この問題は、ＣＰ／Ｍ　３　では解消されているようです。

ワンボードマイコンでＣＰ／Ｍを！［第８１回］
２０１２．４．４ｕｐｌｏａｄ

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