システムアーキテクチャ-2-3 命令オペコードの最適化:ハフマン符号化

2020 システム アーキテクチャ シリーズの記事


長い間試験を受けた後、私はまだこのトピックに取り組んでおり、自分自身を賞賛しています.

コマンド形式

命令は、オペコードアドレス コードの2 つの部分で構成されます。

命令の最適化

命令フォーマットの最適化に関する限り、プログラム内の命令の平均ワード長が最短になるように、最短数のビットを使用して命令の操作情報とアドレス情報を表す方法を指します。 .
オペコードの最適化、つまり、命令の操作情報を表す最小ビット数。

固定長オペコードの編成スキーム

固定ビット数: たとえば、オペコードは 6 ビットに固定されています。
命令語の最上位部分に一定数のビットを割り当てて操作コードを表すことは、コンピュータ ハードウェアの設計を簡素化し、命令のデコードと認識の速度を向上させるのに役立ちます。
例: 1BM360 マシン、ティーチング コンピュータ

可変長オペコードの編成スキーム

不定ビット数: オペコードは 6 ビットまたは 7 ビットまたは 8 ビットにすることができます。
固定長フィールドは、命令ワードの最上位部分で基本的なオペコードを表すために使用されます。オペランド アドレスが少ない一部の命令では、オペ コードは命令のオペランド アドレス フィールドに展開されます。操作コードが長くなる可能性があります。
この方法では、命令語の長さを増やさずにより多くの命令を表現できますが、デコードと分析が難しくなり、より多くのハードウェア サポートが必要になります。

命令オペコード部分の最適化

最適化する方法は?
まず、オペコード部分の最適化とは、可変長オペコードの最適化を指すことを知っておく必要があります。固定長のオペコードには最適化の余地がないためです。
最適化の考え方は、命令のオペコードのビット数を減らす方法を見つけることです。

実行する方法?
命令の使用頻度に応じて、最もよく使用される命令をできるだけ短いビット数で表現する必要があります。これには、ハフマン圧縮の概念が含まれます。

ハフマン圧縮の考え方の基本的な考え方は、さまざまな事象の発生確率が等しくない場合に、最適化技術を用いて最も発生確率の高い事象を最短の桁数(時間)で表現(加工)するというものです。 )、および発生確率が最も高いイベントを表現 (処理) する. 低いイベントは、より多くのビット (時間) を表す (処理) ことを可能にし、「(処理) を表すビットの平均数 (時間) を短縮する.オペコード表現の最適化は、
主に命令語長を短くし、プログラムの総ビット数を減らし、命令語で表現できる演算情報とアドレス情報を増やすことです。コードを作成するためには、プログラム内の各命令の確率(使用頻度)を知る必要があります. 一般に、多数の統計計算の代表的な手順が存在します.

ハフマンコーディング

ハフマン符号化の概念はすでに知っています。次に、例題に沿って適用してみましょう. トピックは次のとおりです:
ここに画像の説明を挿入
まとめのアイデア: 1. ハフマン アルゴリズムを使用して、ハフマン木を構築します。
ハフマン ツリーを作成するのは非常に簡単です. すべてのノードをキューに入れ、頻度が最も低い 2 つのノードを 1 つのノードに置き換えます。新しいノードの頻度は、2 つのノードの頻度の合計です。このように、新しいノードは、置き換えられた 2 つのノードの親ノードになります。これは、キューにノード (ツリーのルート) が 1 つだけ残るまでループします。2. 描画されたハフマン ツリーによると、次の表に示すように、ルート ノードから開始して、各周波数命令までの線に沿ったコード シーケンスが、周波数命令のハフマン コードを構成します。 3. コーディングテーブル
ここに画像の説明を挿入
に従って計算されます。
ここに画像の説明を挿入
ヤードの長さ。
下の図に示すように、計算された平均コード長は 2.2 ビットで、これはタイトルで与えられた H に非常に近く、このエンコードの情報の冗長性はわずか 1.36% であり、これは H の情報の冗長性よりもはるかに小さいです。 3 ビットの固定長コード (28 %)。したがって、完全ハフマン符号化が最適な符号化です。
ただし、このエンコーディングにはコード長の種類が多すぎます。上記の表にあるように、7種類の命令に対してコード長は4種類あり、長さは1、2、3、5と不規則でエンコードが困難ですこのため、一般的なバイナリコーディングと組み合わせて、ハフマンコーディングに基づいて拡張されています。
ここに画像の説明を挿入

拡張オペコード エンコーディング

拡張オペコード エンコーディングは、固定長のバイナリ エンコーディングと完全なハフマン エンコーディングの間のエンコーディング方法です. オペコードは固定長ではなく、限られた数のコード長しかありません。上記のトピックのように、7 つの命令を表すのに2 つの固定コード長のみが必要な場合、どのエンコード方式を使用する必要がありますか?

最良の場合、それはできるだけ短くする必要があります。それでは、最短のコード長から始めましょう。

コード長が 1 の場合、この時点では 2 命令 (2 の 1 乗: 0 と 1) しか表現できず、そのうちの 1 つは拡張に使用されます。
1 桁、2 項目を表すことができます、(2-1)+2=3<7、表現不足;
2 桁、4 項目を表現できます、(2-1)+4=5<7、表現不足;
3 桁、1 +8=9>7、条件を満たす。
最初の方式が出てきて、1 の符号長が 1、4 の符号長が 6 あり、平均符号長=1 0.4 +4 (…)=2.8
注: 表現が不十分な場合、実際には、拡張を続けますが、これは 2 つのコード長の制限を満たしていません。

コード長が 2 の場合、4 命令 (2 の 2 乗: 00、01、10、11) しか表現できず、3 命令が占有され、1 は拡張に使用されます。
(4-1)+2=5<7 の場合、1 桁で 2 項目を表すことができ、表現不足;
2 桁で 4 つの項目を表すことができ、(4-1)+4=7=7 の条件を満たす。
2番目の方式が出てきた. 符号長2の符号が3つ, 符号長4の符号が4つある. 平均符号長=2*(0.4+0.3+0.15)+4*(…)=2.3

コード長が 3 の場合、この時点で 8 命令 (2 の 3 乗: 000、001、010、011、100、101、110、111) を表現できますが、は 2 つのコード長の要件を満たしていません。要件なので、そのまま渡します。また、後続のコード長 > 3 も一致しません。

まとめると、現時点では 2 つの解しかなく、どちらの平均コード長が最も短いかを比較するだけで済みます。
結論、最適なコーディング スキーム: 命令の使用頻度に応じて命令を 2 つのグループに分け、2 ビットのオペコード コードを使用して、使用頻度の高い 3 つの命令 I1、I2、および I3 を表現し、2 ビットのコードを残りの 4 つの命令をより低い頻度でエンコードするために使用される、2 ビットに拡張された拡張フラグ。平均ヤードの長さは 2.3 です。(明らかに、拡張オペコード エンコーディングの平均コード長は、ハフマン エンコーディングの平均コード長より長く、冗長性が高く、無駄がありますが、規則的です。ハードウェア実装の方が便利です)。

具体的なコーディング スキームは次のとおりです。ここに画像の説明を挿入

プログラミングが大好きなリトルウォーターモンスター、ぜひご注目ください。間違いがあれば指摘してください、一緒に頑張りましょう。

おすすめ

転載: blog.csdn.net/changhuzichangchang/article/details/119187648