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

●ＤＡＡのお話の続きです

前回と前々回は別のテーマを飛び入りでしてしまいましたので、ＤＡＡの説明が中断してしまいました。
今回はその説明の続きです。

これまでの説明で１６進数と見かけ上はよく似たＢＣＤ数というものがあって、ともにその（１６進数、またはＢＣＤ数の）１桁は２進数を４ビット毎に区切ったものに、１６進数は０〜Ｆをあてはめて示し、ＢＣＤ数は０〜９を当てはめて示す、ということを説明しました。
そして、コンピュータは純２進数で計算するが、１６進数は２進数とまったく同値なので、計算結果を２進数として示しても、１６進数として示してもなんら問題は生じない。
しかし、ＢＣＤ数は純粋な２進数とは似て非なるものなので、ＢＣＤ数の２数をコンピュータが２進数だとして加算すると、その結果はＢＣＤ数同士の加算結果として期待する値とは異なってしまう、というお話をしました。
その期待と異なって出てくる値を、ＢＣＤ数の加算結果と同じになるように補正する命令がＤＡＡ（ｄｅｃｉｍａｌ　ａｄｊｕｓｔ）である、というところまでが、前回のお話でした。

●ＢＣＤ数の計算でも、２進数の計算と結果が一致する場合もある

今回はもう少しつっこんで、２進数の加算とＢＣＤ数の加算の相違点をさぐることからスタートしたいと思います。
前回は、２進数の加算結果とＢＣＤ数の加算結果は異なる、と説明しましたが、正確に言うと、一致する場合と異なる場合がある、という方が正しいのです。
２進数とＢＣＤ数で結果が一致する例として、ＢＣＤ数の２３＋４５＝６８という計算を考えてみます。

　　１０　００１１　　　　…１６進数の２３（十進では３５になる）　
　１００　０１０１（＋　　…１６進数の４５（十進では６９になる）
　１１０　１０００　　　　…１６進数の６８（十進では１０４になる）

前回の例とは違い、今回の計算では、２進数としての加算結果であるにもかかわらず、「見かけ上」はＢＣＤ数として加算した結果とも一致しています。
もっともそれはあくまで「見かけ上」のことだけで、計算の対象となる「数値」としては、２進数とＢＣＤ数では、まったく異なる値を扱っていることになります。
つまり上の計算結果は、コンピュータ内部ではあくまで十進数の１０４に相当する２進数（１６進数）の６８（１０進数と同じ表記になって区別がつかないので、６８Ｈとか＆Ｈ６８などと表記したりします）として認識します。
しかし、６８を１６進数として考えるのか、ＢＣＤ数として考えるのかは、コンピュータ（機械）ではなくて、プログラマ（人間）なのですから、プログラマが、ここは２進数値としての６８ではなくて、いわば文字記号として考えたＢＣＤ数の６８なのだ、とはっきり区別して考えていれば、それで何も問題はないことになります。

●一致する計算と不一致になる計算を区別して整理してみよう

さて、そこで、それではいったいどのような場合にＢＣＤの計算と２進数の計算結果が一致し、またどのような場合に不一致となるのでしょうか？また、不一致の場合の差は一定になるのでしょうか？

そのことを表を使って確かめてみることにします。
ＤＡＡは１バイト（８ビット）の数を対象にしています。1バイトの数はＢＣＤ数では２桁、００〜９９の数になります。
しかしいきなり２桁の数について、ＢＣＤ数の計算と２進数の計算を比較しようとすると計算が複雑になりますから、１桁の数同士の計算で考えてみます。
桁上がりの処理を別にすれば、１位の数の計算（加算）も、１０位の数の計算（加算）も、同じ計算（加算）方法ですから、まず１桁の計算について考えてみることができれば、あとは桁上がりについて、考慮すればよいことになります。

具体的な説明に入る前に、計算の前提条件についてまず説明をします。
ＤＡＡ命令はあくまで直前に行われた計算（加算。たとえばＡＤＤ命令）がＢＣＤ数同士の計算であることを前提にしています。
ＢＣＤ数としてはありえない数の計算、たとえば１Ｂ＋２Ｄ＝４８などの計算のあとでＤＡＡ命令を実行したとしても、もともとそれは意味の無い結果を期待していることになりますから、ＤＡＡ命令の結果も、何らかの結果は出てきますが、まったく意味のない結果であると言えます。
したがって、今回のＢＣＤ数と２進数の計算結果の相違に関する整理についても、ＢＣＤ数同士の計算のみが対象になります。それ以外の数の組み合わせは除外して考えます。

そのような前提のもとで考えてみると、ＢＣＤ数同士の１桁の数の加算は、０〜９＋０〜９であるといえます。つまり０＋０からはじまって９＋９の計算までです。これを表にまとめてみます。
九九の表を足し算に直したのと同じような表になります。

足す数の０〜９と足される数の０〜９は、表の上の１行と左の１列で、黄色で表示されています。
計算結果はその行と列ではさまれた部分に１６進数で示されています。
このうち色がついていない部分は１０進数（ＢＣＤ数）として計算しても、１６進数として計算しても、結果は同じになります。
色がついている部分は１０進数（ＢＣＤ数）として計算したときと、１６進数として計算したときとで、結果が異なってきます。じつは、この部分は９の列（↑で示す列）に代表的に示されていますから、その右の行に、１０進数（ＢＣＤ数）としての計算結果を示して、比較できるようにしてみました。

左列（足す数）の一番下がＡになっているのは、足す数が９でさらに下位桁からの桁上がり（キャリー）がある場合の計算を示しています。
左列の一番上の０は、足す数が０で下位桁からのキャリーもない場合の計算を示しています。
左列の０とＡ以外の数は、下位桁からの桁上がりがある場合と無い場合の計算の両方を示しています。たとえば、１は足す数が１でキャリーが無い場合と、足す数が０でキャリーがある場合の計算の両方を示しています。いずれの場合でも結果は同じになるからです。

ＤＡＡ命令は↑で示した９列に代表、表示されている１６進数を、その右側の列に表示されている「１６進数」（注意。１０進数ではありません！）に変換する作業なのです。
９列の数に対してどのような計算を行うと、その右の列の数（１６進数）にすることができるのでしょうか？
話が複雑になりますから、とりあえず、水色で着色された範囲についてのみ考えてみてください。

●ＤＡＡの補正の方法が見えてきた！

すると、おおお！、と思わず声をあげてしまいそうになります。
９の列とその右の列をともに１６進数として考えたとすれば、いずれも９の列の数（つまり補正前の数）に６を加算すれば、見かけ上は期待したＢＣＤ表現の結果になることがわかります！
水色で着色された数は、Ａ〜Ｆですから、補正前の数がＡ〜Ｆならば、それに６を加算してやればよい、ということになります。
そのことを表の右端の列に加算する数として表示してみました。
補正のために６を加算すればよい、ということは、ＢＣＤ加算と２進加算のしくみをよく考えれば理解できることなのですが、このように表にして考えてみることで、難しい計算理論などのお世話にならなくても、正解にたどりつくことができます。

●しかし、それだけでは問題はまだ解決しない！

問題はピンクで着色した部分です。
この範囲にあるのは０〜３です。
これに６を足してやっても、６〜９にしかなりません。それに０〜３は着色されていない範囲にもあります。
ピンクで着色された部分は補正しなくてもよいのでしょうか？
そうはいかないはずです。０〜３を１６〜１９に直さなければいけません（じつはこの表現は正しくありません。でもここではこういう表現にしておきましょう）。
うーん。これは困りました。
着色された０〜３の場合には、単純に考えると１６を足してやる必要がありそうです。
でも着色されていない０〜３は、何も足す必要はありません。
この一見同じにしか見えない、０〜３の２つのグループはどのような理由で区別され、またどのような補正を行えばよいのでしょうか。

じつは、着色された０〜３と着色されていない０〜３はその１桁だけをみれば同じ０〜３なのですが、その結果が出てきた、もとの計算は性質の異なるものなのです。
どのように性質が異なるのでしょうか？

着色されていない０〜３は、１桁＋１桁＝１桁の計算結果なのです。上の表では左上角の０〜３＋０〜３の範囲にのみ、その計算が行われています。
他方で、着色されている方の０〜３は１桁＋１桁＝２桁の計算結果の下位桁になっているのです。
表では右下角の６〜９＋７〜Ａの範囲でその計算が行われています。言いかえると、ピンクに着色された範囲の計算は、下位桁同士を加算した結果、上位桁に桁上がりが生じる計算である、と言えます。

ＤＡＡ命令では、結果として示された同じ０〜３に対して、着色されていない０〜３に対しては、何の補正も行わず、ピンクで着色された０〜３に対してだけ、補正をしなければならないのです。

では、同じように見える、０〜３をどのようにしたら区別することができるのでしょうか？
もう、おわかりですよね（ここまでの説明のなかに、ちゃんとその答えは書いてありますよ）。

念のために言っておきますが、コンピュータの計算結果には、色はついていませんよ！

●しかし、計算結果に「色」がついていた！

じつは、計算結果にも、「色」がつけられていたのです。
８０８０を考えた人たちは、まあ、なんと賢い人たちだったのでしょう！

その「色」とはＨフラグ（ｈａｌｆ　ｃａｒｒｙ　ｆｌaｇ）のことなのです。
ＡＤＤ命令などで、８ビットの数の加算を行うときに、その計算の過程でビット３からビット４への繰り上がり（キャリー）が発生すると、Ｈフラグがセットされます。
２進数を４ビットごとに区切ったとき、ビット３は、その２進数を１６進数表現で考えたときの下位桁の最上位ビットになります。
つまりビット３からビット４へのキャリーとは、言い方を変えれば、１６進数２桁同士の加算において、下位桁から上位桁へ繰り上がりが発生したことを示している、「色」であると言えるのです。

ピンクで着色された０〜３を、着色されていない０〜３と区別するには、Ｈフラグが立っているかどうかを見ればよい、というのが正解なのです。

●では、どのように補正するのか？

これでやっと補正すべき０〜３と補正が不要な０〜３を区別する方法がみつかりました。補正前の数が０〜３で、かつＨフラグが立っているときだけ、補正を行えばよいのです。
１６を加算すればよい？
そうではありません。この場合にも６を加算すればよいのです。

なぜでしょうか？
そのことを理解するために、ＢＣＤ数２桁同士の加算なのですけれど、実は、０９＋０７という実質的に１桁同士であるような、計算を考えてみます。この２数の間で２進数の加算を行うと、結果は１０になります。上位桁に桁上がりが発生するために、上位桁が１になります。この１０を１６に補正するのですから、１６を加算するのではなくて、６を加算すればよいのです。（�@）

ところで、あれっ？と気になりませんか？

なんだか、だまされてしまったようだけれど、すると、水色の部分の＋６の計算は本当にそれで大丈夫？
今の説明とは逆に、なんだか補正によって、新たな桁上がりが発生してしまうように思えたのだけれど…。

念のために確認してみましょう。
今と同じように、実質１桁同士の計算で確かめてみることにします。
水色の部分の計算の例として、０９＋０６を考えてみます。この２数の間で２進数の加算を行うと、結果は０Ｆになります。まだ上位桁は０のままです。この０Ｆを１５に補正するために６を加算すると、結果的に上位桁に繰り上がりが生じて、ちゃんと期待通りの１５になって、この場合には補正のための計算の過程で発生する上位桁への桁上がりも、補正の一部として必要であったことがわかります。（�A）

いやあ、ずいぶん長い説明だったけれど、やっと終わりました。めでたし、めでたし。

●まだ、説明は終わりません！

じつは、まだ終わりにはできないのです。まだ２つ問題があります。
そのうち１つは単純なものです。まずそちらの方から片付けてしまいましょう。

●キャリーフラグが問題！

今までは、ＢＣＤ数２桁同士の加算に対して、その下位桁にのみ注目してきました。
下位桁と上位桁は本当にまったく同じに扱ってよいのでしょうか？

さきほどの補正方法の検証を行った部分（�@と�A）が、上位桁だった場合について考えてみます。
ともに＋６をすればよい、ということでした。
注目したいのは、この補正のための加算を行う前と後のフラグについてです。
問題はピンクに着色された範囲の計算で発生します。
上の例で�@の場合です。
�@の場合、０９＋０７＝１０が補正前に行われた計算でした。同じことを今度は上位桁に移し変えて考えてみることにします。
すると、７０＋９０という計算について考えることになります。２進数の計算では７０＋９０＝１００になります（話を簡単にするために、この場合の下位桁は足す数も足される数も、ともに０であるとします）。
この計算結果の最上位桁の１は、何なのでしょうか？
ＢＣＤ数は１バイト８ビットで２桁ですから、３桁目はありません。
そうなのです。このような計算が補正前に行われたとすると、この上位桁の１は、実は上位桁への桁上がりが発生したことを示す、Ｃフラグ（ｃａｒｒｙ　ｆｌaｇ）なのです。
ところが、この１００（じつはｃａｒｒｙ　ｆｌaｇがついた００）を６０に補正するために、上位桁に６を加算すると、それは上位桁での０＋６の計算をすることなので、その場合には加算後に上位桁への桁上がりは発生しません。
ということは、補正のための加算によって、Ｃフラグ（ｃａｒｒｙ　ｆｌaｇ）がクリアされてしまうのです！
�@の場合、つまり下位桁の場合には、この１はＣフラグではなく、Ｈフラグであると同時に、補正前の計算の過程で、すでに上位桁に加算されてしまっていますから、補正のための加算によってＨフラグがクリアされてしまっても、支障はありません。
もともとＨフラグはこのＤＡＡ命令のためにあるフラグですから、ＤＡＡ補正が済んでしまえば、クリアされようがどうしようがまったくかまわないのです。
しかし、Ｃフラグは上位桁への桁上がりの情報を保持していなければならないのですから、ＤＡＡ補正によってＣフラグがクリアされてしまっては困ります（まだ上位桁の計算はこれからあとで行われるはずです。そのときまで、桁上がりの情報は維持していなければなりません）。
そこで表のピンクで着色した範囲の数が上位桁である場合（つまり上位桁が０〜３でかつＣフラグが立っている場合）には、補正前の上位桁に６を加算するだけではなくて、補正によってクリアされてしまうＣフラグをセットし直しておく必要があるのです。

�Aの場合はどうなのでしょうか？
これも上位桁の計算に置き換えて考えてみます。
９０＋６０＝Ｆ０という計算が行われたあとの補正で上位桁に６を加算します。補正前の計算ではＣフラグはまだ立ってはいません。補正によって上位桁のＦに６を加算すると、上位桁は５になって、さらにその上の桁への桁上がりを示すＣフラグが立ちます。このＣフラグは結果を１５０にするために上位桁（上位バイト）への桁上がりに必要なものですから、この場合のＣフラグの動作は補正によってかえって正しくなった、ということが言えます。したがって上の例とは異なり、補正計算のあとでＣフラグの内容を変える必要はないことがわかります。

さてもうひとつの問題は少し面倒です。
この問題は補正前の数が９Ａ〜９Ｆのときに発生します。
下位桁に注目すると、Ａ〜Ｆですから、下位桁に６を加算する必要があります。上位桁は９です。表では色はついていませんから、補正のための加算は必要ありません。
ところが！

百聞は一見にしかず、です。
実際に補正のために、例として９Ａに６を加算してみましょう。補正前の数が９Ａになる計算の例としては、幾通りもありますが、なるべくわかりやすい計算例として、４６＋５４＝９Ａという計算が行われたことにします。するとこの場合ＤＡＡ命令に求められるのは、９Ａを１００に換算すること、であるということがわかります。
その換算結果を求めるために、今まで考えてきたルールにしたがって、９Ａに６を加算してみます。

　１００１　１０１０　　　９Ａ
　００００　０１１０（＋　０６
　１０１０　００００　　　Ａ０

あれえ？おかしいですね。１００、つまり結果が００になって、上位バイトへのＣフラグが立たなければいけないはずなのに、Ａ０などという予期しない結果になってしまいました。
なぜこのようなことになってしまうのでしょうか？
補正前の９は本来ならば、補正の必要の無い数なのですが、この９が上位桁にある場合に、下位桁がＡ〜Ｆの時はその下位桁に対する補正計算によって、上位桁への桁上がりが発生するために、９だったものがＡになってしまうのです。
したがってこの場合には、Ａになってしまった上位桁に対して、さらに６を加算する必要があるのです。
つまり、補正する前の数が、９Ａ〜９Ｆの場合には、結果的に上位桁にも下位桁にも補正が必要となるため、６６を加算しなければならない、ということになります。
そのことを２進数の加算で確認してみます。

　　１００１　１０１０　　　９Ａ
　　０１１０　０１１０（＋　６６
１　００００　００００

正しく補正が行われることがわかりました。

●以上のまとめ

以上をまとめてみると、次のようになります。
補正前の数の、
１）下位桁がＡ〜Ｆの場合は、下位桁に６を加算する
２）下位桁が０〜３で、かつＨフラグが立っているときも、下位桁に６を加算する
３）上位桁がＡ〜Ｆの場合は、上位桁に６を加算する
４）上位桁が０〜３で、かつＣフラグが立っているときは、上位桁に６を加算後、Ｃフラグをセットする
５）上位桁が９で下位桁がＡ〜Ｆの場合には、６６を加算する

やっと、終わりました！以上で宿題は終わり！

●まだ、宿題は全然終わりではありません！

わー、もう、いいかげんにしてほしいよー！

ですが、まだ、肝心のＮフラグの話が全然できていません。
じつは、これからが、やっとお話の本論なのです！

いままでしてきたＤＡＡ（十進補正）の説明は全部、補正前の計算が「加算」であった、と仮定して説明してきました。
では、補正前に行われた計算が、減算だったとしたら、どうなのでしょうか？
その場合にも、６を加算すればよいのでしょうか？

説明がずいぶん長くなってしまいましたので、減算のあとのＤＡＡ（十進補正）については、次回にすることにいたします。

えー。正直なところ、いまどきＤＡＡなど使う人は多分いないと思います（まだ、いらっしゃいますか？）
いまどきは、プログラムをアセンブラで書く人自体が減ってしまって、ＰＩＣのプログラムだってＣで書く人が増えたとかと聞きます。
Ｃではないにしても、最終的に計算結果をＢＣＤで表示したいようなプログラムだった場合に、途中の計算の過程も全部ＢＣＤで通すっていうのは、ちょっとどうか…と思います。
まずはＢＣＤ数を全部２進数に変換しておいて、計算は純粋の２進数として行って、最後にＢＣＤで表示することが必要になった時点で、はじめてＢＣＤに変換する、というのが常道だと思います。
その場合でもＤＡＡ命令を使うのではなく、２進数から１０進数への変換ルーチンを作って、それによって変換を行うようにします（多分、普通は、です）。

すると、いまどき、ＤＡＡ命令など使わないので、そんなかびの生えたような命令にこれだけ長々と説明するのは、まったくムダ、ということになります。

かって、私が高校生の時、大学を出たての現代国語の教師が新任としてやってきました。彼は非常にアクが強い先生で、新任であるにもかかわらず、なかなかにクセの強い授業をすることで、一躍有名になってしまいました。
その彼の授業でいまだに印象に残っていることがあります。
高校の教科書ともなると、いろいろな現代文の中で、原文に当用漢字以外の漢字が使われている場合でも、それをひらがなに直すのではなくて、読みを括弧でつけたりルビをつけて、そのまま載せていることがあります。
彼は、授業中に、教科書の中に、そのような漢字を見つけるたびに
「これは、当用漢字ではない。だから、覚えなくてもよい！」
と口癖のように言うのが常でした。

うう。それは、そうなのかもしれないけれど、それって、ちょっと…。

いや、別に、ＤＡＡ命令とは、まったく何の関係もないお話です。ただ、なんとなく、思い出してしまっただけです。
（いやー、とにかく、疲れた！）
２００８．７．２０ｕｐｌｏａｄ
２００８．７．２２加筆訂正

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