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

●まずは、パリティフラグについて、少しだけ

ことのついでにパリティフラグについて、ざっと説明しておきたいと思います。
パリティの本当の意味については、よく知りません。
コンピュータの世界では…、

あ、やっぱりこういういいかげんなことは、良くありません。
ｐａｒｉｔｙについて辞書で調べてみると…。
同等、等価、等しいこと、均衡…、などということのようです。
うーん。なんだ、辞書を引いても、よくわからんではないか。

コンピュータの世界では、パリティとは、１であるビットの数が偶数個であるか奇数個であるかをチェックするときに用いられる言葉です。たとえば１バイトのデータ（８ビット）で、１のビットの数が、０、２、４、６、８個のときが偶数（ｅｖｅｎ）で、１、３、５、７個のときが奇数（ｏｄｄ）です。

あ、数値が偶数であるか、奇数であるかではありませんから、お間違えなく。
２進数の場合には、最下位ビット（ビット０）が１なら奇数、０なら偶数ですから、数値の奇数偶数はわざわざフラグを用意するまでのことはありません。

では、どういうときに、パリティフラグがセット、リセットされるかというと、８０８０やＺ８０では、論理演算命令（ＯＲ、ＡＮＤ、ＸＯＲ）の実行時に、結果によって、セット、リセットされます（このことをよーく覚えておいてください）。

そんなもの、何に必要なの？

普通はまず、使うことはありません。たいていはシリアル通信などで、誤り検査に利用したりする程度です。
シリアル通信の代表格はＲＳ２３２Ｃですが、いまどきはＵＳＢにお株を奪われてしまい、ずっと影が薄くなってしまいました。

ある装置から別の装置にデータを送るときに、４ビットとか８ビットとかのデータをそのまま送るのが一番簡単です。シリアル通信に対してパラレル通信といいます。プリンタケーブルがよい例ですが、これも最近はＵＳＢになってしまいました。

以前はＲＳ２３２Ｃ通信は、通信環境がよくないところで使われることがよくあって、データが化けてしまう（本当は１なのに０になってしまうとか、逆に０なのに１になってしまう）ことがありました。シリアル通信の場合には、電波と同じでノイズが乗ったり、送信のタイミングがずれたりということで、簡単に１と０がひっくり返ってしまうことがあります。
そのようなときに、本来のデータにさらに１ビットを追加してそのビットも含めてつねにパリティが偶数になるようにして送信し（偶数パリティ）、またはつねに奇数になるようにして送信します（奇数パリティ）。こうすることによって、受信側で、データが化けたりしていないかどうかを知ることができます。
この追加されたビットをパリティビットといいます。
もっともたまたま１個だけ、１と０がひっくりかえってくれればこの方法でエラーが発見できますが、２個とか４個とかひっくりかえったりすると、もう、どうしようもなくなります。

まあ、それほどひどい状態なら、通信すること自体が困難ということかもしれませんが。

●コンピュータで使われる文字コードのお話

またまた、話は脱線してしまいます。しばしお付き合いを。

いままでは十進数を２進数に置き換える話をしてきましたが、文字もコンピュータで扱えるようにするために、２進数に置き換えてしまいます。
十進数と違い文字は言葉のもとですから言語圏の違いによってさまざまなバリエーションがあります。日本ではひらがな、かたかな、漢字を使います。
同時に英語圏にもかかわりが深いのでアルファベットも一般的に使用します。

そこでまずアルファベットのお話です。
文字Ａを２進コードでは、０１０００００１（４１）を割り当てて使うことが一般的です（十進数→２進数とは違って、絶対的なルールではありません）。

前に十進数と２進数のお話の時に、十進数の０〜９を２進数的なコードで表すものとしてＢＣＤコードというものがある、という説明をしました。
ＢＣＤコードは１桁の数字０〜９を２進４ビットで表します。１バイトは８ビットですから、ＢＣＤコードなら十進数２桁を入れられます。
一般にコンピュータ、ＲＳ２３２Ｃ通信などでは、文字情報データを７ビットまたは８ビットで示します。
漢字は種類が多いので１バイト８ビットではとても表すことができません。漢字を２進コードで示すためには２バイト１６ビットが必要になります（まあ、それは別のお話です）。

アルファベットＡ〜Ｚ２６文字（およびａ〜ｚ）は合わせても５２文字ですから、１バイト８ビット全部をまるまる使わなくても７ビットで十分間に合います。７ビットあれば１２８種類の文字を表すことができますから、アルファベットだけではなくて、ついでに数字の０〜９も一緒にこの７ビットのコードに割り当ててしまいました。
それがＡＳＣＩＩコードです。７ビットしか使わないので、７ビットコードとも言います。厳密にはＡＳＣＩＩコードと７ビットコードとは同じ意味ではありませんが（と思いますが）、まあ、普通には、同じことだと考えてもよいと思います。

●ＡＳＣＩＩコード

参考までにＡＳＣＩＩコードを下に示します。

［表の見方］表は１バイト８ビットの２進コードを上位４ビット下位４ビットに分けてそれぞれ１６進数で表示しています。
たとえば文字Ａは上位４ビットが４の行と下位４ビットが１の列の交点にあります。ＡのＡＳＣＩＩコードが４１であることを示しています。
同様に、数字の０のＡＳＣＩＩコードは３０であることがわかります。
文字が表示されていないところは、国によって異なる文字が割り当てられたりしているか、特殊な制御コードとして使われます。
コード５Ｃには￥があります。日本では用いられることが多いのでここに入れてありますが、当然のことながら世界共通ではありません。
コード２０はスペース（空白）です。
コード００〜１Ｆは特殊な制御コードとして用いられます。

●７ビットコードと８ビットコード

ＡＳＣＩＩコードではコード８０〜ＦＦは使いません。つまりアルファベットは１バイト８ビットのうち実質７ビットしか使用していません。
そこで英語圏でははじめから文字として８ビットのうち７ビットのみを使い、残った最上位ビットは使わないで捨ててしまうか、別の目的に使ったりします。これが７ビットコードです。

わが国ではＡＳＣＩＩコードで使われていない８０〜ＦＦに半角のカナ文字を割り当てて使用することが一般的です。つまり８ビットコードです。
インターネットは日本国内だけではなく、さまざまな国の人たちと情報を共有しています。８ビットのうちコード８０〜ＦＦに半角カナを割り当てているのは、当然日本だけで、外国の人たちは、「そんなことは、知らないよ」というわけで、それぞれ別の文字や制御を割り当てています。

文字コードについてはこれ以上詳しいことは知りません。だから、以下はただの想像、推測です。
多分７ビットコードか、それ以外のコード（８ビットとか１６ビット）かの切り替えマークとして７ビットコードでは使われていない８０〜ＦＦが利用されているのだと思います。
メールの見出しや送信人の名前などに「半角カナは使ってはいけない」などといわれているのは多分そういう理由からだと思います。
半角カナを区別できない、世界共通のソフトなどでは、半角カナコードを見つけると、別の文字コードや別の特殊処理への切り替えスイッチがＯＮになってしまい、文字化けしたり、暴走したりしてしまうことになったりします。

●お話をもとに戻します。７ビットコードと８ビットコードの、別の切り口です

なんだか、どんどん別の軌道を走っていってしまいます。
お話をちょいと元に戻します（戻してもすぐに、脱線してしまいます）。

ＡＳＣＩＩコードは７ビットなのだ、という説明をしました。
でも１バイトは８ビットですし、メモリもたいていは８ビットか１６ビットなのですから、７ビットコードだからといって、８ビットのうちの１ビットを使わないことにしても、何のメリットもないように思えます。

しかしこれがシリアル通信ということになると、大いに関係してくることになります。
ひとつの文字をパラレルからシリアルに変換して、並列ではなくて直列に伝送するわけですから、８ビットコードならば８回パルスを送らなければならないところを、７ビットコードならば７回で済んでしまいます。１割以上伝送速度が上がるわけですから、これは無視できません。

なおこれも厳密に言うと、８ビットコードの代わりに７ビットコードを使っても、単純に８／７倍のスピードアップにはなりません。
ＲＳ２３２Ｃ通信（非同期、調歩同期式）などでは、文字コードをサンドイッチにするようにその前後にスタートビットとストップビットを送りますから、８ビットコード１文字を送るのには最低でも１０パルスは必要になります。
文字コード本体が８ビットから７ビットになったとしても、スタートビットやストップビットはそのまま必要ですから、１０／９倍のスピードアップということになります。
それはともかくとして、ＲＳ２３２Ｃ通信をマシン語やＢＡＳＩＣなどで使う場合に、通信速度（ボーレート）とともに、文字コードが７ビットなのか８ビットなのかを指定しなければならないのは、このあたりの事情からなのです。

●７ビットコードとパリティチェックは相性がいい

文字を通信で扱う場合に、７ビットコードを使ったとしても、１バイトは８ビットで８ビットＣＰＵはこの単位で動くのだから、通信速度以外には、それほどメリットはない、いうならばいつも１ビットが使われないで、無駄な状態で残っている、とも考えることができます。
そこで、どうせ空いている１ビットならばパリティチェックのために利用してしまおう、というわけです。

たとえば、さきほどの例で文字ＡはＡＳＣＩＩコードでは、０１０００００１（４１）でした。７ビットコードでは、１０００００１ということになります。そこでここに１ビットのパリティビットを追加して、合計８ビットのパリティがつねに偶数になるようにしたのが、偶数パリティ方式です（ｅｖｅｎ）。
文字Ａのコードには１が２つあって、もともと偶数個ですから、パリティビットは０のままにして、０１０００００１として送信します。
逆にパリティビットを含めた８ビットの中の１のビットが奇数個になるようなルールにしたのが、奇数パリティ方式です（ｏｄｄ）。
奇数パリティ方式ならば、文字Ａは１１０００００１として送られることになります。

●やっとパリティフラグの登場です

受信側ではこれをどうするか、というと、ここでやっとパリティフラグ君の登場です（ここまでくるのが、長かった！）。

一般的にはシリアル受信のバッファはＣＰＵの外の外部Ｉ／Ｏとして設計されていることが多いので、その受信バッファから受信データを引き取るのには、通常は、ＩＮ命令を使います。

ＩＮ　受信バッファアドレス

の実行で、受信データ（８ビット）がＡレジスタに読み込まれます。
そこで、

ＯＲＡ　Ａ

を実行すると、ＡレジスタとＡレジスタ（つまり同じ値）のＯＲなので、この命令を実行しても、Ａレジスタの中身は全く変化せず、そのときの値によって、フラグだけが変化します。
パリティフラグもＯＮ、ＯＦＦするので、この命令を実行するだけで、簡単にパリティチェックができてしまいます。

パリティチェックが済んで、受信コードに誤りがないことがわかったら、もう、送信元で追加したパリティビットは不要なので、

ＡＮＩ　７Ｆ

を実行すれば、簡単にパリティビットだけを削除して、もとの（０）１０００００１に戻すことができます。
ＡＮＩ　７Ｆ　という命令は、Ａレジスタの値と７ＦとのＡＮＤをとって、結果をＡレジスタに戻す命令です。
このようにＡＮＡ（またはＡＮＩ）命令は８ビットのうちの特定のビット（１ビットだけに限りません）を０クリアする目的でよく用いられます。

●しかし、８ビットコードではこうは都合よくはいきません

こうやって見てくると、なんだか非常に都合良くできているように見えますが、それはあくまで７ビットコードでのお話です。
もとの文字コードを半角カナまで含めて８ビットコードにした場合には、パリティビットを追加すると、全体では９ビットになってしまいます。

すると、受信バッファから受信データを引き取る場合でも、パリティビットを含めた９ビットは一度に読み込むことはできません。
わざわざパリティビットの処理だけのために、なにもかも二度手間になってしまいます。
７ビットコードの場合には、どうせ空いている１ビットだから、ということで気安く追加した、パリティビットだったのですが、わが国の特殊事情で８ビットコードにした途端に、なにもかもが食い違ってしまい、余計なお荷物をしょいこんでしまったかのような、ゴテゴテしたプログラムになってしまうのです。

こんなときには、自分が英語圏に生まれず日本に生まれてしまったことを、ちょいとうらめしく感じてしまいます。
ひらがなもかたかなもない、中国の人たちは、もっと大変だろうなぁ、と思ってしまうのですが、それにしては、彼らは実に元気で、アグレッシブなことに、心底感心してしまいます。

●お話はさらに脱線してしまいます

パリティフラグからだんだんお話が横にそれてきてしまって、もう完全に脱線状態ですけれど、ついでなのでもう少し。

マシン語プログラムでＲＳ２３２Ｃ通信を行うような場合に、勘違いをしてしまう方がいます。
文字を送受信する場合は、アルファベットならば、プログラムの中でもＡＳＣＩＩ（アスキー）コードで扱っているはずですから、たいていはそのコードをそのまま送るので問題は生じません。
しかし、数値データを送ろうとすると、はてな？ということになってしまいます。

●ＢＣＤ数と十進数と２進数、その上さらに今度は文字コードです！

ＢＣＤコードならばまだなんとかなりそうな気がするのですが、２進数となると、いったいこれはどうすればよいのでしょう。
そこで、たとえば８ビットだとか１６ビットだとかの２進数のデータをそのままＲＳ２３２Ｃなどで、パソコンに向けて送信してしまう方などがでてきてしまいます。

えーっ。だめなんですかぁ？
だって、コンピュータは十進数ではなくて、２進数で計算したり処理したりするって言ったじゃないですか？
メモリに記憶するのだって、いまどきはＢＣＤなど使わないで、全部２進数で記憶したりしてるんでしょ？

それは、そうなのですが、データを送信するときは、別なのです。
さきほど説明したＡＳＣＩＩコードの表をもう一度よく見てください。
コード０Ａとコード０Ｄのところに、ＬＦ、ＣＲと書いてあります。
これがＲＳ２３２Ｃ通信などでは重要なコードなのです。

●ＬＦとＣＲ

ＬＦはラインフィード、改行です。ＣＲはキャリッジリターン、復帰です。ＣＲＬＦと２つを続けて使います。復改などと言います。
これはもともとタイプライターで使われていた用語（だったと思います）で、プリンタヘッドが用紙の左端に戻るための命令がＣＲで紙送り命令がＬＦです。
ＲＳ２３２ＣはもともとＴＴＹ（テレタイプだったかな？）を制御するために使われた通信方法で、そのために、１１０ボーというえらく中途半端なボーレートが存在したと記憶しています。あ、なにか、化石のような、お話になってしまいました。

いまどき、そんな太古の昔の装置のようなものを制御するなどということはありませんが、どっこい、制御コードだけは生き残っていて、今でも使われているのです。
いまでも、ｎｏｔｅｐａｄ（メモ帖）などで作成されるスタンダードの、拡張子がｔｘｔのファイルは、行の終わりにこのコードを使っています。行の最後は０Ｄと０Ａを続けて使います。ＣＲ・ＬＦです。

さてそこで、問題のシリアル通信です。
ＲＳ２３２Ｃも行の終わりには０Ｄ・０Ａコードを送ることが一般的なルールになっています。
あれえ、０Ａって、どこかで見たような…。

そうです。１０進数の１０を２進数に変換すると、０Ａになりました。０Ｄは十進数の１２です。
そうすると１０とか１２に相当する２進数データをそのまま、ＲＳ２３２Ｃでパソコンに送ったとしても、パソコンはそれをデータとしては認めてはくれません。

なんじゃい。データかと思ったら、ＣＲとＬＦか？

ということになってしまいます。
それだけではありません。２進数のデータはそのままで計算に使うことができますが、その値そのものをプリンタに送っても、数字を印刷してはくれません。ＲＳ２３２Ｃ通信でも、全くその通りなのです。
せっかく計算しやすいように２進数に直して記憶しているのに、通信したりプリンタに出力したりするためには、またもとの十進数に戻して、その十進数をＡＳＣＩＩコードに直してやらなければいけないのです。

●例をあげて説明します

ここに十進数で９６４５というデータがあります。
これを２進数に直すと、２５ＡＤ（１６進数表記）になります（２進表記では、００１０　０１０１　１０１０　１１０１になります）。
１６ビットですから２バイトの数です。
このデータをパソコンなどにＲＳ２３２Ｃを使って送信する場合に、最初に２５、次にＡＤなどと送信してはいけません。
どうするか、というと、２進数→１０進数変換ルーチンを使って（インターネットを検索するとライブラリルーチンが見つかるかもしれません。でも本当は自分で書いてみないことには、なかなか上達することはできませんよ）、もとの１０進数のＡＳＣＩＩコード表現のデータを作成します。９６４５をＡＳＣＩＩコードで表現すると、３９・３６・３４・３５になります。この４バイトを送って、最後に０Ｄ・０Ａを送ります。

なお、今説明した通信のルールはごく一般的なルールで、なにがなんでもこの通り、ということではありません。
送信側と受信側で、同じルールのプログラムを動かすことができるのでしたら、いちいちせっかくの２進数を十進数に変換して送信し、受信側でまた十進数から２進数に戻して…などという面倒くさいことをしなくても、２進数のまま送信することも可能です。

（以上ここまで、２００８．７．２９大幅に加筆いたしました）

●それでは、やっと、オーバフローフラグのお話です

Ｚ８０では同じフラクビットをパリティフラグとオーバフローフラグで共用していますけれど、パリティとオーバーフローとは全く何の関係もかかわりもありません。むしろ、全くかかわりがないからこそ、同じビットを共用することができたのかもしれません。
そのことについては後ほど説明することにいたしましょう。

オーバーフローフラグとは、計算で扱える数値の限界を超えて計算をさせようとした場合にセットされるフラグです。
しかしその言い方はあいまいです。コンピュータはあいまいなことが苦手なので、もっと具体的にはっきり教えてやらなければ、何もしてくれません。
残念なことに、どうも８０８０には、オーバーフローフラグがなかったようですので、８０８０に対してオーバーフローについて定義してあげても、無意味かもしれません。

そうか。８０８０はオーバーフローしても、素知らぬふりで計算を続けてしまうんだ。

ですから、ここはＺ８０のお話になってしまいます。８０８０とは関係がないお話ですから、まあ、言ってみれば、一般教養のようなものです。

そこで、では、具体的にどういう場合にオーバーフローフラグがセットされるか、ということですが、その前に、Ｚ８０では、どのような命令でオーバーフローフラグがセット、リセットされるかをお話しておきます。
Ｚ８０では、ＡＤＤ、ＳＵＢなどの数値演算命令とＩＮＣ（ＩＮＲ＊注）、ＤＥＣ（ＤＣＲ＊注）命令を実行したときに、その結果によって、オーバーフローフラグがセット、リセットされます（実はＺ８０では、計算に関係のない特殊な命令でもこのフラグを使っています）。

８０８０にはオーバーフローフラグがなかったことがわかってしまったので、その関係の回路は削除してしまいますが、今回製作中の、ＴＴＬでＣＰＵをつくる組立キット、の２番目の基板には、まだ数値演算（ＡＬＵ）の回路は入りません。それは３番目の基板になります。
２番目の基板でオーバーフローフラグに関係するのは、ＩＮＲ、ＤＣＲ回路だけです。

ＩＮＲはｉｎｃｒｅｍｅｎｔのことで、レジスタやメモリの値を＋１増やす命令です。ループカウンタなどによく使います。これに対してＤＣＲはｄｅｃｒｅｍｅｎｔのことで、ＩＮＲとは逆にレジスタやメモリの値を−１減らします。

＊注８０８０ではアセンブラニーモニックでＩＮＲ、ＤＣＲと表記しますが、Ｚ８０ではＩＮＣ、ＤＥＣと表記します。８０８０とＺ８０でアセンブラの表記は異なりますが、マシン語コードは同じです。

●８０８０はオーバーフローなどいたしません（？）

８０８０にはオーバーフローフラグがありませんから、どんな計算をさせても、オーバーフローはしません、
というような、ことはありません。

８０８０でもできない計算を無理にさせれば、立派にオーバーフローしてしまいます。しかし何度も説明しましたように、８０８０にはオーバーフローしてしまったことを知らせるフラグがありませんから、プログラムを工夫してそのような計算にならないように注意する必要があります。

余談ですが、先日インターネットで、中国についての記事を読んでいたら、中国の某銀行のＡＴＭで、うっかり預金残高がマイナスになってしまうような引出し操作をしたところ、マイナスにならないで、逆に、現金を引き出せば引き出すだけ、預金残高がどんどん増え続けるという、前代未聞（果たしてそうかな？意外とよくあるプログラムミスなのでは）の出来事についての記事を目にしました。
その銀行プログラムのどこに誤りがあったのかは知りませんが、本来マイナスにならなければならないはずの残高がプラスになって増え続けるなどというミスは、人間ならば滅多にしそうもない誤りですけれど、コンピュータは、よほど注意してプログラムを書かないと、このテの信じられないミスをいとも簡単にやってくれてしまいます。

余談は置いて、オーバフローフラグのお話に戻ります。
ＡＤＤ命令、ＳＵＢ命令でオーバーフローフラグがセットされる条件は、ちょっと考えてみなければいけません。
でもＩＮＣ命令、ＤＥＣ命令では意外に簡単です。

ＩＮＣ命令では実行後に結果が８０になったときに、オーバーフローになります。
ＤＥＣ命令では実行後に結果が７Ｆになったときに、オーバーフローします。
なぜでしょう？

前に、符号付２進数のお話をしたときに、１バイト（８ビット）の符号付２進数の取り得る値の範囲は、０および正数値は００〜７Ｆ（０〜＋１２７）で、負数値はＦＦ〜８０（−１〜−１２８）である、という説明をしました。
ＩＮＣ（ＩＮＲ）命令を実行すると、そのレジスタまたはメモリの値を＋１しますから、実行後の値が８０ということは、実行前は７Ｆだったということになります。
符号付数の８０は−１２８ですし、７Ｆは＋１２７です。
つまりＩＮＣ（ＩＮＲ）命令の実行によって、＋１だけカウントアップしたはずが、なんと＋１２７からいきなり−１２８になってしまったことになります。これを十進数の計算式で表すと、＋１２７＋１＝−１２８という式になってしまいますから、これはありえない計算をしてしまったことになります。

さすがのＣＰＵも実行してしまったあとで、
わー！わて、えらいこと、して、しもうた！

と自分でもびっくりしてしまい、オーバーフローフラグをセットするのです。
わてが悪いのとちゃいまっせ！みーんな、あんさんのせいやから、あとはなんなとすきなようにしときー。

逆にＤＥＣ（ＤＣＲ）のときは、実行後に７Ｆになったということは、実行前は８０だったわけです。
これは−１２８−１＝＋１２７と言う計算ですから、これもいかにもむちゃくちゃな結果を出してしまったことになって、オーバーフローフラグがセットされます。

●そんな話は、おかしいよー！それじゃＩＮＣ（ＩＮＲ）命令は１２７を超えて実行はできないと言うの？

あー、これは、Ｚ８０のお話で、８０８０にはオーバーフローフラグはありませんから、ご安心を。
いや、そういう問題では、ないでしょう！

これも前に、符号付２進数と符号無し２進数の区別は、「プログラマの勝手」だとお話したことがありました。
そういうことなのです。

さきほどの余談のように、プラスの値とマイナスの値の両方が存在するような数の計算をする場合には、プラスの数＋プラスの数＝マイナスの数、になってしまったり、マイナスの数−マイナスの数＝プラスの数、になってしまったりしてはいけませんから、そうならないように、オーバーフローに注意するなどの工夫が必要になります。
当然ＩＮＣ（ＩＮＲ）によって、７Ｆ（＋１２７）の次が８０（−１２８）になってしまうような計算は絶対に禁止、です。

これに対してイベントの入場者数を数えるような場合には、マイナスの数値は存在しませんから、７Ｆの次に８０になっても、全く問題はありません。当然この場合には、７Ｆ＝（十進数の）１２７で、８０＝（十進数の）１２８になります。

８０を−１２８とするかそれとも符号無し数の１２８と考えるかは、プログラマの勝手で、ＣＰＵの関知するところではありませんから、プログラマがどう考えていようと、Ｚ８０なら、ＩＮＲ（ＩＮＣ）命令の実行によって、結果が８０になってしまったら、オーバーフローフラグを立ててしまいます。

どうしましょう？
ですか。正解は、「気にしなければ良い」のです。

どのようなフラグが立ったとしても、フラグはただのフラグです。
オーバフローしたからといって、ＣＰＵが勝手にプログラムの実行を中止することは、決してありません。
ＣＰＵはプログラマの忠実な僕（しもべ）ですから、プログラムを離れて勝手には動きません。

ここでオーバーフローしたなら、こちらの命令を実行させたい、という場合には、オーバーフローフラグの結果によってジャンプする命令を書くことになりますし、さきほどの入場者数をカウントするときのように、７Ｆの次が８０になっても全くかまわないならば、オーバフローフラグが立っていても無視してしまえば良いのです。

こういうところが、アセンブラ（マシン語）の自由なところで、アセンブラに慣れると、自由なプログラムが書けるようになります。ほんとうにプログラマの勝手です。逆にＢＡＳＩＣとかＣなどの高級言語は、そうは簡単にはいきません。
いろいろ面倒で細かい約束事があって、それをおろそかにすると、思うように動いてはくれません。

ここは、お願いだから、目をつぶっててよ！
などと言っても聞いてはくれません。

「不正な処理です」と言って、いきなり、勝手に実行を終了してしまいます。

●Ｚ８０でパリティフラグとオーバーフローフラグが同じビットで共存できるわけ

今までの文章を注意深く読んでいただければ、その答えはすぐにわかります。
パリティフラグとオーバーフローフラグはそれぞれ別の命令でしか使われないので共存が可能なのです。

パリティフラグはＡＮＤ、ＯＲ、ＸＯＲといった論理演算命令によってセット、リセットされます。これに対してオーバーフローフラグはＡＤＤ、ＳＵＢなどの数値演算命令によってセット、リセットされます。

だから、いま立っているフラグはパリティフラグなのかオーバーフローフラグなのか迷ってしまうようなことはないのです。
これはまあ当たり前の話で、ＩＮＣ（ＩＮＲ）、ＤＥＣ（ＤＣＲ）やＡＤＤ、ＳＵＢで計算の結果、１のビットの数が偶数なのか奇数なのかを調べることに、多分意味はないと思いますし、逆にＡＮＤやＯＲ命令の実行とオーバーフローがかかわりがあるなどとは考えられません。


☆前回お見せした回路図を使って、オーバーフロー回路の説明をする予定でしたが、時間がなくなってしまいました。
それについては、申し訳ありません。次回に持ち越し、とさせていただきます。
２００８．７．２８ｕｐｄａｔｅ
２００８．７．２９加筆修正
前へ
次へ
ホームページトップへ戻る