バイナリがわからない場合、BCD はより直感的なデータ型のようなものです。しかし、このエンコーディングを使用する理由がわかりません.4ビットでの表現が無駄になるため(表現が9より大きい場合)、あまり意味がありません。
また、x86 は add と sub のみを直接サポートしていると思います (FPU 経由で変換できます)。
これが古いマシンまたは他のアーキテクチャに由来する可能性はありますか?
バイナリがわからない場合、BCD はより直感的なデータ型のようなものです。しかし、このエンコーディングを使用する理由がわかりません.4ビットでの表現が無駄になるため(表現が9より大きい場合)、あまり意味がありません。
また、x86 は add と sub のみを直接サポートしていると思います (FPU 経由で変換できます)。
これが古いマシンまたは他のアーキテクチャに由来する可能性はありますか?
BCD算術は、正確な小数の計算に役立ちます。これは、多くの場合、金融アプリケーション、会計などの要件です。また、10の累乗による乗算/除算なども簡単になります。最近はもっと良い選択肢があります。
賛否両論を議論する良いウィキペディアの記事があります。
BCD は、レジスタ内の値が何らかの出力デバイスによって表示される場合、エレクトロニクス スペクトルの非常にローエンドで役立ちます。たとえば、数字を表示する多数の 7 セグメント ディスプレイを備えた電卓があるとします。各表示を別々のビットで制御すると便利です。
最新の x86 プロセッサがこの種のディスプレイを備えたデバイスで使用されるとは考えにくいと思われるかもしれませんが、x86 にはかなりの歴史があり、ISA は多くの後方互換性を維持しています。
BCDは、元の8086プロセッサに搭載されていたため、最新のx86 CPUに搭載されており、すべてのx86CPUは8086と互換性があります。x86のBCD操作は、当時のビジネスアプリケーションをサポートするために使用されていました。プロセッサ自体のBCDサポートは、実際には使用されなくなりました。
BCDは10進数を正確に表したものであり、浮動小数点はそうではありません。また、ハードウェアにBCDを実装する方が、浮動小数点を実装するよりもはるかに簡単であることに注意してください。プロセッサが数メガヘルツで動作するトランジスタが100万個未満の場合、この種のことはもっと重要でした。
BCDはスペース的に無駄ですが、それは事実ですが、「固定ピッチ」形式であるという利点があり、特定の数値のn番目の桁を簡単に見つけることができます。
もう1つの利点は、任意のサイズの数値で正確な算術計算ができることです。また、前述の「固定ピッチ」特性を使用すると、このような算術演算を複数のスレッドに簡単にチャンク化できます(並列処理)。
上記の理由から、BCD は多くのことに役立つと思います。見過ごされているように見える明らかなことの 1 つは、バイナリから BCD への移行とその逆の指示を提供することです。これは、ASCII 数値を算術用の 2 進数に変換するのに非常に役立ちます。
ポスターの 1 つは、数字が ASCII で格納されることが多いという点で間違っていました。また、ASCII をバイナリに変換するのは少し複雑です。BCD は、ASCII とバイナリの間のようなものです。bsdtoint と inttobcd 命令があれば、変換は非常に簡単になります。すべての ASCII 値は、算術のためにバイナリに変換する必要があります。したがって、BCD は ASCII からバイナリへの変換に実際に役立ちます。
最近では、数値を 2 進数形式で格納し、表示目的で 10 進数形式に変換するのが一般的ですが、変換には時間がかかります。数値の主な目的が表示すること、または表示される数値に追加することである場合、2 進数で計算を実行してから 10 進数に変換するよりも、10 進数形式で計算を実行する方が実用的です。数値読み取り機能を備えた多くのデバイスや多くのビデオ ゲームでは、1 バイトあたり 2 桁を格納するパックされた BCD 形式で数値が格納されていました。これが、多くのスコア カウンターが 2 の累乗値ではなく 1,000,000 ポイントでオーバーフローする理由です。ハードウェアがパック BCD 演算を容易にしない場合、代わりに 2 進数を使用するのではなく、パックされていない 10 進数を使用することになります。パックBCDをパックされていない10進数に変換する瞬間 表示は、一度に 1 桁ずつ簡単に行うことができます。対照的に、2 進数から 10 進数への変換ははるかに遅く、全量を操作する必要があります。
ちなみに、8086命令セットは、「除算のASCII調整」と「乗算のASCII調整」の命令で私が見た唯一のものであり、そのうちの1つはバイトを10で乗算し、もう1つは10で除算します。不思議なことに、値「0A」はマシン命令の一部であり、別の数値に置き換えると、それらの命令は他の量で乗算または除算されますが、命令は汎用の乗算/定数除算命令として文書化されていません。 . 便利だったのに、なぜその機能が文書化されなかったのだろうか?
また、パックされた BCD の加算または減算にプロセッサが使用するさまざまなアプローチに注目することも興味深いことです。多くはバイナリ加算を実行しますが、加算中にビット 3 からビット 4 へのキャリーが発生したかどうかを追跡するためにフラグを使用します。次に、コードが結果をクリーンアップすること (PIC など)、加算をクリーンアップするためのオペコードを提供するが減算を提供しないこと、加算をクリーンアップするために 1 つのオペコードを提供し、減算のために別のオペコードを提供すること (x86 など)、またはフラグを使用して最後の演算は加算または減算であり、同じオペコードを使用して両方をクリーンアップします (例: Z80)。BCD 演算に別のオペコードを使用するものもあれば (68000 など)、フラグを使用して加算/減算演算にバイナリまたは BCD を使用するかどうかを示すものもあります (6502 導関数など)。興味深いことに、元の 6502 は BCD 演算をバイナリ演算と同じ速度で実行しますが、
以前にリンクされた Wiki の記事で詳細が説明されていると思いますが、私は IBM メインフレーム プログラミング (PL/I) で BCD を使用しました。BCD は、バイトの特定の領域を調べて個々の数字を見つけることができることを保証しただけでなく (これは便利な場合もあります)、ハードウェアが単純なルールを適用して必要な精度とスケールを計算することも可能にしました。
思い出すと、メインフレームでは BCD のサポートがハードウェアに実装されており、当時は浮動小数点数を表現するための唯一のオプションだったと言われました。(私たちはここに行く18年を話している!)
30年以上前に大学にいたとき、BCD(COBOLではCOMP-3)が優れた形式である理由を教えられました。
これらの理由はいずれも、最新のハードウェアにはまだ関係ありません。高速なバイナリ固定小数点演算があります。各BCD桁にオフセットを追加することにより、BCDを表示可能な形式に変換できるようにする必要はなくなりました。数値を1桁あたり8ビットとして格納することはめったにないため、BCDが1桁あたり4ビットしか使用しないという事実はあまり興味深いものではありません。
BCDは遺物であり、それが属する過去に残しておく必要があります。
現代のコンピューティングでは、いくつかの CPU サイクルをあちこちで最適化するのではなく、設計ロジックをキャプチャするコーディングが強調されています。多くの場合、節約された時間やメモリの値は、特別なビットレベルのルーチンを書く価値がありません。
そうは言っても、BCD は今でも時々役に立ちます。
私が考えることができる 1 つの例は、CSV のような ASCII 形式の巨大なデータベース フラットファイルまたはその他のビッグ データがある場合です。BCD は、制限内の値を探しているだけの場合に最適です。すべてのデータをスキャンしながらすべての値を変換すると、処理時間が大幅に増加します。
16 進数で表した金額を指定できる人はほとんどいないため、中間結果を 10 進数で表示するか、少なくとも表示できるようにすると便利です。特に金融や会計の世界では。