ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
［第１３回］
●ＬＡＴレジスタ
前回はＰＲＩＮＴ文のプログラムの説明のなかでＩ／Ｏポートの出力を確認する方法として出力に設定したＩＯポートから出力値を読むことができることについて書きました。
しかしそれに続けて下記のように書きました。
ＰＯＲＴＣはＩ／Ｏポートですから本来はＰＩＣの端子の外にＬＥＤなどを接続して出力を確認すべきなのですがこのように出力に指定したＰＯＲＴを読むことでも出力値を確認することができます。
しかしこの方法は時として問題が発生する可能性があります。
今回はその問題について書くことにします。
下は前回と同じようなプログラムですが今回はＰＯＲＴＣだけに値を出力してそのあとＰＲＩＮＴ文でＰＯＲＴＣの値を表示させるプログラムです。
／ＲＵＮで実行すると５５が表示されるはずのところ００が表示されました。
問題発生です。
なんじゃこりゃ。
念のために／ＲＤコマンドでＰＯＲＴＣの値を確認してみますとちゃんと５５になっています。
夏にはまだ早いのですけれどまるで怪奇現象です。
実はこれがＩ／Ｏポートの問題点なのです。
初期のＰＩＣ（ＰＩＣ１６など）ではこの問題のためにＩ／Ｏポートに直接ビットセット、リセット命令を実行すると正しい結果が得られないことがありました。
そのためＩ／Ｏポートに対してビット命令を使う場合には直接Ｉ／Ｏポートに対してビット命令を使うのではなくてワークとして別に用意したレジスタに対してビット命令を実行してからそのレジスタの値をＩ／Ｏポートに出力する、という作法が必要でした。
この問題は”ＲＥＡＤ ＭＯＤＩＦＹ ＷＲＩＴＥ問題”として知られています。
この問題の解決法としてＰＩＣ１８などではＩ／ＯポートにＬＡＴレジスタが追加されました。
Ｉ／Ｏポートに出力した値を読む（確認する）にはＰＯＲＴＸを読むのではなくてＬＡＴＸを読むようにすることでこの問題を回避できます。
上のプログラムのＰＯＲＴＣをＬＡＴＣに変更してプログラムを実行しました。
今度は正しく実行されました。
念のためにもう一度さきほどのＰＯＲＴＣのプログラムをＬＯＡＤして実行してみますと。
５５を出力したはずなのにＬＡＴＣに出力した値が読み出されました。
それではということで／ＲＤコマンドで確認してみますとちゃんと５５が読み出されます。
一体どうなっているの？
ということなのですがその理由はＰＩＣのＤＡＴＡ ＳＨＥＥＴを読むとわかります。
下はＰＩＣ１８Ｆ１３Ｋ／１４Ｋ５０のＤＡＴＡ ＳＨＥＥＴのＩ／Ｏ ＰＯＲＴの説明のところです。
［出典］Ｍｉｃｒｏｃｈｉｐ Ｔｅｃｈｎｏｌｏｇｙ Ｉｎｃ． ＰＩＣ１８Ｆ１３Ｋ５０／１４Ｋ５０ Ｄａｔａ Ｓｈｅｅｔ
図の下部にＲＤ ＰＯＲＴがあります。
どこの値をＲＥＡＤしているかというと図の右上のＩ／Ｏ ＰＯＲＴ端子のところを入力しています。
一応出力端子の状態を読んでいるので問題はない、はずなのですが。
その一方で図の左上を見るとＲＤ ＬＡＴと書かれています。
こちらは出力ラッチの出力をＩＣ内部で直接読んでいます。
ＲＤ ＰＯＲＴの場合、外部回路に接続されている端子の状態を読むためにどうしてもその端子の外部のラインの状態に影響されてしまいます。
Ｉ／Ｏポートの出力を０から１に（または１から０に）変化させてもたとえば外部ラインの浮遊容量などの影響で立ち上がりや立ち下がりが短い時間ですがわずかに遅れることが出てきます。
マシン語のプログラムは非常に高速なのでその遅れの影響が無視できません。
ＲＤ ＬＡＴは出力ラッチの出力を直接読むためにそのような外部回路の影響を受けません。
出力ポートの値を読む場合でも出力した直後ではなくて少し間を空けてから読めばこの問題は回避されます。
下は出力と入力の間にＦＯＲ ＮＥＸＴ文を実行して間にわずかな時間を置いて実行した例です。
わずかな時間を置くことで正しい値が読み出せるようになりました。
ＬＡＴレジスタとＰＯＲＴレジスタは別々のものではなくて同一の回路上にありますから、ＰＯＲＴＣに出力してＰＯＲＴＣから読む、ＬＡＴＣに出力してＬＡＴＣから読む、というように区別して考える必要はありません。
ＰＯＲＴＣに出力してＬＡＴＣを読んでも全く問題はありません。
下はそのようにしたプログラム例です。
さて。
毎回のように書いていることですが。
上記の一連の作業ではプログラムをロード／セーブしたり一部を変更したりという作業を行なっていますがいずれも面倒な手続きなどを必要としないでいとも簡単に行なえていることがご理解いただけるかと思います。
ＢＡＳＩＣプログラムの記述そのものも極めて平易ですしプログラムを部分的に書き換えたりプログラム行を追加したりするなどの作業もスクリーンエディタの機能で簡単に行なえます。
今までのコンパイラのイメージからは想像もできないほどではありませんでしょうか。
実際どう見てもまるでＢＡＳＩＣインタプリタではないかとの印象をもたれるのではないかと思います。
でも。
間違いなくＢＡＳＩＣコンパイラなのです。
下はひとつ上の画面のＦＯＲ ＮＥＸＴ文を追加したプログラムを／ＲＵＮコマンドで実行したときに生成されたアセンブラリストファイルです。