〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
すべてはここからはじまりました。
中日電工も。
４０年前を振り返りつつ新連載です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
［第１８回］
●入力バッファとＴＥＸＴエリア（３）
前回の終わりのところで、「（入力バッファの先頭の）３１がそのまま残ってしまうのは、ＴＥＸＴエリアにコピーする段階で先頭の２バイトは行番号（１６進数）になり、その後ろは余分なスペースを外してすぐにプログラム命令が続くように入力バッファで整えたあとＴＥＸＴエリアにコピーするため」と書きました。
しかしそのすぐあとに続けて、「それではまずい点がある」ことに気が付きました、と書いてそこで終りました。
気が付いた「まずい点」とはこういうことです。
前回の例では入力バッファの先頭には
３１ ３０ ２０ があってその後ろに命令の本体が続いていました。
先頭の３１ ３０ を０Ａ ００ に置き換えてその後ろの２０を取って後ろに詰めた結果、３１がそのまま残って
３１ ０Ａ ００
になったのでした。
先頭の行番号は必ず１６進数２バイトに置き換えられます。
それではもし置き換え前の行番号部分が１バイトしかなかったなら？（そんなことがあるのでしょうか？ー実はあるのです）
Ａ）その場合には１バイト不足してしまうため、１６進数に変換するためには入力バッファの中身全体を１バイト後ろにシフトしなければならないのではないか？（これはノーマルな対処ですがプログラム的には余り賢くはありません）
Ｂ）あるいはひょっとすると「構わずそのまま前に１バイトはみ出させてしまう」のではないか？（逆転の発想ですが、こちらのほうが賢いやり方です）
そこのところがどうなっているのか、前回と同じ方法で確認してみました。
今回は
５ＰＲＩＮＴ Ａ，
と入力してブレークしたあと入力バッファを確認してみました。
入力バッファの先頭は
３５ ５０ ５２ …
なので先頭の３５を１６進数２バイトに変換するためにはやっぱり１バイト不足します。
続いて変換後にどうなったかを確かめてみました。
すると。
入力バッファの中身は前回の例とは逆に前に１バイトはみ出していました。
上に書いたＢ）の方法が使われていました。
しかしこれで本当によいのでしょうか？
今度はブレークポイントを設定せず、そのままＲＴコマンドを入力してＴＩＮＹ ＢＡＳＩＣに戻りました。
そのあとＬＩＳＴコマンドを入力してみました。
入力したプログラム行が正しく表示されました。
これでやっと合点がいきました。
実はシステムのワークエリアのアドレスで一箇所疑問に思っていたところがありました。
アドレス１３６６が ＤＳ ５５ になっていて、その下に入力バッファ（１３９Ｄ〜）が続いています。
ＤＳは必要なバイト数のメモリ範囲を確保するためのアセンブラの擬似命令です（ＮＤ８０Ｚ３．５などに附属のアセンブラにはＤＳはありません）。
１３６６にはＶＡＲＢＧＮのラベルがついています。
ここは配列＠（０）と変数Ａ〜Ｚの格納エリアです。
Ａ〜Ｚは２６文字でそれに＠（０）を加えると合計２７変数です。
各２バイトですから必要なメモリは５４バイトです。
それなら ＤＳ ５４ でよいではないか？
なぜに５５バイト？（１バイト余分？）
ということが疑問だったのですが、ようやく謎が解けました。
今回の例のように入力バッファの前に１バイトはみ出すことがあるということを考慮して、そのための１バイトが確保されていたのでした！
なるほど。
ガッテン、です。
復活！ＴＩＮＹ ＢＡＳＩＣ［第１８回］
２０２０．６．１１ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る