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

●ＤＡＡの続き（その２　減算に対しては？）

前回のＤＡＡ（十進補正）の説明は、直前に行われた計算が加算であった、と仮定してのお話でした。
もしも直前に行われた計算が減算であったならば、その結果に対する十進補正は、加算であった場合に対するそれと同じでよいのでしょうか。それとも違う処理が必要になるのでしょうか？

加算のときと同じようにして、そのことを確かめてみます。
ここでも加算のときと同じように、直前に行われた減算がＢＣＤ数同士に対して行われたことを前提とします。
減算の場合には、さらに条件が加わります。
直前に行われた減算によって、結果が負（マイナス）になっていないこと、という条件です。
じつはこのことは加算の場合でも同じで、ＢＣＤ数の計算は正の数同士でおこないます。ＢＣＤ数に負数の概念はありません（と思います）。余り自信はありません。あるのかも知れませんが、ＤＡＡの十進補正の方法を調べてみると、どうも正の数のみを対象にしているように思われますので、多分そうだと思います。

とにかく（確たる根拠はありませんが）ここでは、直前に行われた減算の結果も正の数であった、という前提で考えを進めます。

●ところで、余談ですが、２進数、１６進数には符号付の数と符号無しの数があります

また少し、余談になりますが、２進数と１６進数の負数について、少しお話をします。
２進数には符号付２進数と符号無し２進数があります（１６進数でも同じ）。しかし、２進数も１６進数も、１０進数のように、−１２３４５というように負号をつけて表現するのではなく、見かけ上は、符号付でも符号なしでも同じ表現の数です。

十進数はマイナスの数は絶対にマイナスの数です（そんなん、当たり前や）。
ところが、２進数（１６進数）は、同じ数が、ある場合には符号無しの数（通常扱っている正の数）であり、ある場合には符号付の数（＋と−の区別がある）になるのです。

たとえば、１１１１１１１１（ＦＦ）という数は、十進数に直すと普通は２５５になります。
しかし、この２進数を、「符号付の数」である、とプログラマが勝手に宣言すると、不思議にも、十進数の−１に化けてしまうのです。
そんな、あほなー、と言われそうですけれど、本当なのです。
２進数の１１１１１１１１（１６進数のＦＦ）を２５５として扱うか、それとも−１として扱うか、は「プログラマの勝手」に任されていますが、しかしそれはでたらめではなくて、２進数の約束事であると同時に計算のルールとしても矛盾のない取り決めなのです。

「そんな、ばかなことは、納得がいかん！」
という方のために、例をもって説明をいたします。

十進数の計算で、４−５は−１です。
そこで同じことを８ビットの２進数（１６進数２桁）で行ってみます。
２進数の引き算も十進数の引き算のルールと同じです。
ビットごとの引き算で、０−０＝０、１−０＝１、１−１＝０、ですが、０−１はできませんから、上のビットから桁下がりして（つまり２を借りてきて）そこから１を引きます。つまり、０−１＝１（ａｎｄ　上位桁からのｂｏｒｒｏｗ）というルールです。

このルールを理解するために、まず十進数の１８−６＝１２という計算を２進数（１６進数）でやってみます。十進数の１８は１６進数の１２です。

　０００１　００１０　　　　１８（１６進数の１２）
　００００　０１１０（−　　　６（１６進数も６）
　００００　１１００　　　　１２（１６進数のＣ）
　　　　　　
ビット３とビット４で上位桁からのボローが発生しています。

計算のルールはわかりましたか？
では、４−５＝−１の計算を２進数（１６進数）でやってみましょう。

　００００　０１００　　　　４（１６進数も４）
　００００　０１０１（−　　５（１６進数も５）
　１１１１　１１１１　　　　−１（１６進数はＦＦ）

この計算では、上位バイトからのボローが発生するためＣフラグが立ちます。

こんな計算は、どうしても、納得がいかん！これは手品だ、どこかにタネがあるに違いない！
と思われる方がいらっしゃるかも知れませんが、これはコンピュータの世界の約束事なのです。
人間の世界では２５５が−１になったり、−１が２５５になることは決してありませんが、コンピュータの世界では、１１１１１１１１（ＦＦ）はふつうは２５５という符号無しの数として扱うけれど、（あなたが、そうしたければ）−１として扱ってもよい、という約束事があるのです。
２進数の１１１１１１１１は十進数の２５５ですけれど、それを十進数の−１だと言っても決して間違いではなくて、両方とも正しいということなのです。

●２の補数（７月２２日追記）

一晩寝たあと、本日あらためて読み直して見て、こういういいかげんな書き方をすると、世の中を惑わせることになって、非常によろしくない、ということに気がつきました。
もしも情報技術科の学生や生徒が私の文を読んで、宿題のレポートに１１１１１１１１を−１にするのは「プログラマの勝手」である、などと書いたりすると、先生に叱られてしまいます。

ことのついでですが、どこかの省のお役人がインターネットの記事を丸写しにして、国会の資料として提出した、などということがあったようですが、レポートの丸写しはよくないですよ、学生生徒諸君。
参考にするのはおおいに結構。しかし、必ず自分の頭で理解することが必要です。
特に科学の分野では、書かれていることが本当にそうなのか（その事実や論理に間違いや欠陥はないか）を、常に、自分で確認する（実際に実験するなどして体験する）ということが最重要だと思います（これは科学の分野だけに限ったことではない、かもしれませんが）。

どうも、いつも余計な話になってしまい、つい脱線してしまいます。
１１１１１１１１が−１であるというのは、コンピュータの世界の約束事である、と書きました。

人間の世界の約束事というのは、ときとしてあいまいな根拠にもとづいています。法律などはその最たるものでしょう。
しかしコンピュータがもっとも苦手なのは、まさにその「あいまいな考え方」なのです。
とにかく理屈通りでなければ承知してくれません。
したがって１１１１１１１１は実は−１なのだよ、とプログラマが勝手にコンピュータに宣言したとしても、そのことが実際に計算を行う上で矛盾が無いものでなければ、正しく計算してはくれません。
２進数というのは、コンピュータのために使われている数の概念ですから、１１１１１１１１が−１である、ということにもはっきりした根拠が必要になります。

その根拠になるのが、補数という考え方なのです。
補数というのは反対の数という意味です。

反対の数？

難しいことではありません。
２進数の１と０をひっくり返せばよいのです。
たとえば、０１０１０１１１の補数は１０１０１０００です。

しかしこの補数は２進数の負数を考えるのには役に立ちません。
うーん、近いのだけれど、もう一息のところでうまくいきません。
ちょうど＋の電気と−の電気を合わせると、０になってしまうようなうまい数の組み合わせはないものか。

１と−１を足すとちょうど０になります。
０００００００１の補数は１１１１１１１０です。
足しても残念ながら０にはなりません。
０００００００１＋１１１１１１１０＝１１１１１１１１になってしまいます。これではコンピュータは納得してくれません。
もう一息、ほんの少しなんだけど…。

ということで、一味違う「補数」が考え出されました。
０００００００１＋１１１１１１１０＝１１１１１１１１にさらに１を加えると、１１１１１１１１＋０００００００１＝００００００００になるではありませんか！（ただし上位桁にキャリーが発生します）。
補数に＋１を加えた数を、元の数のマイナスの数だと考えたとすると、元の数と、この新しい「補数」を足せば、ちょうど０になるので、都合がよいではないか！

●「１の補数」と「２の補数」

そこで、もともとの補数を「１の補数」と呼ぶことにし、その「１の補数」にさらに＋１を加えた数を「２の補数」と呼んで区別するようにしたのです。そしてこの「２の補数」というものを、元の数の負数である、と決めたのです。

以上の説明のように、「２の補数」は、まずもとの数を各ビット毎に１と０を反対にします（「１の補数」を作る）。
たとえば０００００１０１（１０進数の５）の「１の補数」は、１１１１１０１０になります。
つぎにそのようにしてつくった「１の補数」に１を加えます。
１１１１１０１０＋１＝１１１１１０１１です。これが「２の補数」です。１１１１１０１１は１０進数の５に対する「２の補数」ですから、１１１１１０１１（１６進数のＦＢ）は１０進数の−５である、ということになります。
念のため、２進数の加算法で確かめてみます。

　００００　０１０１
　１１１１　１０１１（＋
　００００　００００

間違いなく加算の結果は０になります。
この加算によって上位桁へキャリーが発生します。
このキャリーは、この計算で扱っている数が、８ビット（１６進数２桁）ではなくて、１６ビット（１６進数４桁）とか２４ビット（１６進数６桁）というような多桁の数であるような場合に上位桁まで計算効果を伝えるために必要になります。

●１６ビットの２進数

参考までに多桁における２進数の負数についても、少し触れておくことにします。
いままでは８ビット（１６進数２桁）の数について考えてきました。しかしそれだけでは桁数が不足する計算もたくさんあります。
そこで今度は８ビットではなくて、１６ビット（１６進数４桁）で１つの数を表す場合を考えてみます。

さきほどの１０進数の５は、８ビットの数ならば、０００００１０１（１６進数の、０５）ですが、これを１６ビット（２バイト）の数で示すと、
００００００００　０００００１０１（１６進数の、０００５）になります。
この場合の、負数についても８ビット（１バイト）のときと同じに考えることができます。

まず「１の補数」を考えます。
００００００００　０００００１０１の各ビットの１と０を逆にすると「１の補数」になります。
１１１１１１１１　１１１１１０１０です。次にこの数にさらに＋１を加えると「２の補数」の出来あがりです。
１１１１１１１１　１１１１１０１１が１０進数の−５に対する１６ビット表現の２進数です（１６進数は、ＦＦＦＢ）。

●１６ビットの計算

１６ビットの数を加算したり減算したりするときに、８ビットのコンピュータは一度に計算を完了させることはできません。８ビット（１バイト）ごとに計算を行います。計算は下位桁から行います。
さきほどと同じように、１６ビットの５と−５を加算してみます。

まず最初に下位８ビットについて、加算をおこないます。この部分はさきほどの８ビットの数の加算とまったく同じです。

　００００　０１０１
　１１１１　１０１１（＋
　００００　００００

結果は００００　００００になって、上位桁（上位バイト）へのキャリーが発生します。さきほどの８ビットの説明で触れたように、このキャリーが重要な働きをします。
上位８ビットの加算を行います。

　００００　００００
　１１１１　１１１１（＋
　　　　　　　　　１（＋　…下位桁で発生したキャリーを加算する
　００００　００００

下位桁で発生したキャリーを上位桁の加算に伝えることで、１６ビットの場合にも、
００００　００００　００００　０１０１　…１０進数の５に相当する１６ビットの２進数（１６進数では、０００５）と
１１１１　１１１１　１１１１　１０１１　…１０進数の−５に相当する１６ビットの２進数（１６進数では、ＦＦＦＢ）とを加算して、０を得ることができます。
この上位桁へのキャリーは、その計算が最上位桁に対して行われた結果発生した場合には、使われないで捨てられてしまいます。

●２進数の、正の数と負の数

私の場合、一度お話が脱線してしまうと、なかなか本線には戻れなくなってしまいます。
もう少し、脱線したまま、お付き合いを願います。

以上の説明のとおり、「２の補数」というものを考えることで、うまく負数を表すことができるようになりました。
しかし、ただそれだけでは、じつは困ることが出てくるのです（このあたりが、さきほど私が、「科学には十分な検証が必要である」と言った所以です）。
０００００１０１（十進数では５）の負数は、その「２の補数」、１１１１１０１１（十進数の−５）でよいのだ、ということを説明しました。
本当に、「２の補数」でよいのでしょうか？

十進数の１２９と−１２９を２進数でそれぞれ表してみます。
十進数の１２９は２進数では、１００００００１です。
すると−１２９は、１００００００１の「２の補数」ですから、さきほどのルールでは、まず「１の補数」が、０１１１１１１０なので、「２の補数」はさらに＋１を加えて０１１１１１１１になります。これが２進数の−１２９です。
加算して確認してみます。

　１０００　０００１
　０１１１　１１１１（＋
　００００　００００

間違いありません。０１１１１１１１は確かに−１２９です。

ちょっと、まったぁ！
世の中にたくさんいる悪い人たちは、こうやって善良な市民をだましてしまうのです。皆さん、だまされては、いけません！

０１１１１１１１は、＋１２７ではありませんか！

すると、＋１２７の負数は、０１１１１１１１の「１の補数」が１０００００００だから、さらに＋１を加えて「２の補数」を求めると、１００００００１（！）、これって、＋１２９じゃ、なかったの？
いったいぜんたい、どうなっているのっ！はっきり説明してよっ！説明できなかったら、警察を呼ぶからねっ！

うう…。
ですから、さきほど、それは２進数の約束事で、同じ数が＋の数にも−の数にもなる…と、説明いたしました。あ、ですから、ある場合には＋１２７ですけれども、それを−１２９と考えてもよい、と…。さすれば−１２７が＋１２９でも一向に構わないのでは、と…。

そーか、そーか、そーだった。それならば、筋が通る。よろしい。許してあげましょう。…って、ごまかされてはいけません。

●符号付の２進数には「符号ビット」というものがある

じつは、２進数の負数にはもうひとつ大事な約束事があります。
それは、その数を符号付の数（つまり＋と−の区別がある数）として扱うときには、最上位ビットを符号ビットとみなす、という約束なのです。
ここでいう最上位ビットとは、その数が８ビットなのか１６ビットなのか（あるいはもっと多いビット数なのか）で異なってきます。
その数が８ビットの数ならば、ビット７が符号ビットですが、１６ビットの数の場合にはビット７ではなくて、ビット１５（上位バイトのビット７）が符号ビットになります。

いままで説明に使ってきた数で説明します。

　０００００１０１　　　　　　　　　　８ビットの２進数の５（１６進数では、０５）
　１１１１１０１１　　　　　　　　　　８ビットの２進数の−５（１６進数では、ＦＢ）
　００００００００　０００００１０１　１６ビットの２進数の５（１６進数では、０００５）
　１１１１１１１１　１１１１１０１１　１６ビットの２進数の−５（１６進数では、ＦＦＦＢ）

赤で示した最上位ビットが符号ビットなのです。
符号付２進数ではこの最上位ビットが１のものを負数、０のものを正数（および０）であると定義して扱っています。
この約束に従えば、最上位ビットは数の大きさを示すビットとしては使用できなくなりますから、８ビットの符号付の数は実質７ビットの大きさの数しか扱えないことになります。
つまり符号付８ビット数で扱える正の数は０００００００１〜０１１１１１１１（１６進数表現では、０１〜７Ｆ。十進数の０〜１２７）で、負の数は
１１１１１１１１〜１０００００００（１６進数表現では、ＦＦ〜８０。十進数の−１〜−１２８）ということになります。
１６進数表現では、その数が符号付の数であった場合には、その最上位桁が０〜７のときが正の数（および０）で、８〜Ｆのときが負の数になります。

そこで、さきほどのインチキ問題です。
どこにインチキがあったかと言いますと、＋１２９は符号付２進数では、８ビットでは表現できないところを、ごまかして、そのところだけ、「符号無し２進数」を借用しているところにあったのです。
＋１２９と−１２９は１６ビット（または１２ビット）で考えれば、矛盾なく計算することができます。

１６ビットで考えた１２９は、００００００００　１００００００１（１６進数では００８１）なので、その「２の補数」は、
１１１１１１１１　０１１１１１１１（１６進数ではＦＦ７Ｆ）になります。これが符号付２進数の−１２９なのです。

　００００　００００　１０００　０００１
　１１１１　１１１１　０１１１　１１１１（＋
　００００　００００　００００　００００

加算するとちゃんと０になりますし、１１１１１１１１０１１１１１１１は−１２９以外に、１６ビットで表現できる符号付の数は存在しませんから、さきほどのインチキの例のようにおかしな矛盾は発生しません。

●マイナスのマイナスはプラス、だが…

まだまだ脱線は復旧しません（この勢いではそのうち、地球の裏側まで行ってしまうのでは…！）。

１０進数の計算では、マイナスのマイナスはプラスになります。
さきほどのインチキな説明では、この辺に矛盾がでてきました。
では、符号ビットを考慮した符号付の２進数では、矛盾なく説明できるのでしょうか？

いままで考えてきた「２の補数」の考え方は、なんとなく、正の数に対して、その数の負数が「２の補数」である、とだけ考えているように思えます。
では、負数の「２の補数」を考えることはできないのでしょうか？

考えてみましょう。
０１１１１１１１（十進の１２７）の「２の補数」は１００００００１（十進の−１２７）でした。
そこで、１００００００１の「２の補数」を考えてみます。
まず「１の補数」を求めます。０１１１１１１０です。
これに＋１を加算すれば、「２の補数」が求まります。０１１１１１１１です。
これは十進の１２７に相当する２進数でした。
確かにマイナスのマイナスはプラスになっています。
めでたし、めでたし…なのですが、例外があります。

まず、０についてですが、００００００００の２の補数は、やっぱり００００００００になってしまいます。でもこれは、マイナスゼロはプラスゼロと同値、と考えられますから、まっ、これでいっか、ということにしておきましょう。

問題は−１２８です。
−１２８の「２の補数」を求めてみます。
−１２８は８ビットの符号付２進数では、１０００００００です（なぜか？−１２７は１００００００１ですから、これから１を引いた１０００００００は−１２８なのです。うーん。どうも、どこかでだまされているような…）。

この際そういうことは考えないで、人の言うことは素直に信じましょう。
まず「１の補数」を求めてみます。０１１１１１１１になります。次にこの数に＋１を加算して、「２の補数」を求めてみると…。
１０００００００！
あれえ！またもとの−１２８に戻ってしまいました。

−１２８をマイナスしたものは＋１２８なのですが、よくよく思い出してみると、８ビットの符号付２進数で表すことのできる正の数は＋１〜＋１２７でしたので、＋１２８は８ビットの符号付２進数では表現できないのです。
そこを無理やり押し通そうとすると、このようなおかしなことがおきてしまいます。
うーん。この仕組みを最初に誰が考え出したのか知らないが、実に良く出来ている！と思わずうなりたくなります。
８ビットの符号付２進数の中で１０００００００（十進数の−１２８、１６進数の８０）だけは別格なのです。
１６ビットの符号付２進数では１０００００００　００００００００（十進数の−３２７６８、１６進数では８０００）が別格ということになります。

８ビットの符号付２進数の計算で、無理やり
０−（−１２８）
という計算をさせると、コンピュータが怒ってしまいます。できないよー！というわけです。
オーバーフローフラグが立ちます。

●まだ、納得がいきません

うーん。まだ、納得がいかないなぁ…。
符号付２進数の最上位ビットが符号ビットで、たとえば８ビットの数の場合、ビット７が１のときに、その数はマイナスの数だというのでしょう？
だったら、＋１２７は２進数では０１１１１１１１なのだから、−１２７はその最上位ビットを１にして、１１１１１１１１になるんじゃないの？
どうして１１１１１１１１が−１で、−１２７は１００００００１なの？そんなの、おかしいよー。

失礼しました。説明不足でした。
符号付２進数は最上位ビットを符号として使用します。
ということは数の大きさに使用できるのは、８ビットの符号付２進数の場合には１ビット減るので、７ビットになります。
表現できる数は０００００００〜１１１１１１１の範囲になります。
正の数（および０）の場合には、そのまま十進数の０〜１２７になります。

しかし、最上位ビットが１の場合には、その下にある００００００１〜１１１１１１１はそのまま十進数にあてはめるのではなくて、ある数が０から引かれた結果がここに示されている、と考えるのです（０００００００ではなくて、００００００１としたのは、すでに説明した−１２８に対する配慮からです）。
すると１１１１１１１は１２７ではなくて、７ビットで表現した０００００００−００００００１の計算結果であるということになります。
同様に、００００００１は０００００００−１１１１１１１の結果であることも理解できると思います。

符号付２進数の負の数をこのようなものにすることによって、符号ビットを計算対象から除外せずに、数の最上位ビットとして、そのビットを含めて、２進数の加算や減算を行っても支障が生じない、という、論理の一貫性につながっているのです。

じつは、符号付２進数の最上位ビットが単なる符号なのか、それとも数そのものの一部なのか、という疑問に対しては、私自身、よくわかっていません。
私は、数そのものの一部であると同時に、数の正負も決定しているビットなのではないか、と思っているのですが…。

●本題に戻ります。ＢＣＤ数の減算と２進数の減算の結果の違いについて整理してみましょう

やっと本題に戻ります。
加算のときと同じようにＢＣＤ数同士の減算をするべきところを２進数として減算を行うと結果はどうなるかを、１桁同士の減算について表にしてみました。ＢＣＤ数同士の減算なのですから、０〜９−０〜９の範囲の計算ということになります。

表の一番上の１行が引かれる数０〜９です（黄色）。表の左端の１列が引く数です（緑色）。
左行の一番下がＡになっているのは、引く数が９のときに、さらに下位桁からのボローがある場合を示しています。この場合のみ引く数が結果的にＡになります。
なお引く数が０の行の計算には、下位桁からのボローはありませんが、その他の行は、下位桁からのボローがある場合も含めています（たとえば、１の行は、引く数が１で下位桁からのボローが無い場合と、引く数が０で、下位桁からのボローがある場合をあわせています。ともに結果が同じになるからです。他の数についても同様です）。
黄色の行と緑色の列ではさまれた範囲が計算の結果の値（１６進数）です。

着色されていない範囲の計算は、ＢＣＤ数の計算でも２進数の計算でも、結果が同じになります。ですからこの範囲は補正をする必要はありません。
水色で着色された範囲はＢＣＤ数としての減算と、それを２進数だとして行った減算とで結果が異なっていることを示しています。
一番下の行に、水色で着色された範囲の数の全てが表示されていますから、その下の行に、２進数の減算ではなくて、ＢＣＤ数−ＢＣＤ数＝ＢＣＤ数というように、十進数としての減算を行ったときの結果を表示しました。

たとえば水色７の下は１になっています。
水色の７の元になる減算は、０−９と、１−９−ボロー（１−Ａ）です。
十進数の計算なら、上位桁から１０を借りてきて（上位桁へのボローが発生して）、結果は１になります。ということを示しています。
また水色８の下は２になっています。
水色の８の元になる減算は、０−８、０−７−ボロー（以上２つはまとめて、０−８にしてある）と、１−９、１−８−ボロー（以上２つもまとめて、１−９にしてある）と、２−９−ボロー（２−Ａ）です。
十進数の計算なら、上位桁から１０を借りてきて（上位桁へのボローが発生して）、結果は２になります。ということを示しています。

したがって、減算の場合の補正は、水色の最下行の１６進数をその下の１６進数（加算の場合とは異なり、たまたま１０進数とも一致しますが、ここも扱いは１６進数です）に補正する作業である、と言えます。

ところで加算の場合と同じように、着色付の６〜９と着色されていない６〜９があることがわかります。
表をよく見ると、減算の場合には着色されている範囲の計算は全て上位桁へのボローが発生する計算であることがわかります。
つまり、引かれる数＜引く数という関係が成り立っています。

ここで注意しておきたいのは、あくまでこの関係は、この１桁（４ビット）の数についてのみ成立している関係で、他の桁も含めて、結果が負数になる、という関係を意味しない、ということです。
すでに説明しましたように、ＤＡＡ（十進補正）の直前に行われたＢＣＤ数同士の加減算は、その計算を十進数の加減算として行った場合に、足される数（または引かれる数）も足す数（または引く数）も、そしてその結果の数もすべて正の数である（厳密には符号無しの数である）、という前提条件を忘れないようにしないといけません。

とにかく、上位桁へのボローが発生しているか否かが、減算の場合の十進補正を行うか行わないかの判断の第一の条件になることがわかります。
さらに結果の数をよく見ると、６〜Ｆまでに限られていることもわかります。

説明の途中ですが、本日は時間がなくなってしまいました。
この続きはまた次回にいたします。
２００８．７．２１ｕｐｌｏａｄ
２００８．７．２２加筆訂正

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