ISAオペコード---どこから来たのですか?


13

エンジニアが命令セットアーキテクチャを設計するとき、特定のバイナリコードを命令として指定する場合、どの手順またはプロトコル(存在する場合)を使用します。たとえば、10110がロード命令であるというISAがある場合、その2進数はどこから来たのでしょうか?ロード操作を表す有限状態マシンの状態テーブルからモデル化されましたか?

編集:さらなる調査を行った後、さまざまなCPU命令のオペコードがどのように割り当てられているのかを懸念していると思います。ADDは、オペコード10011で指定される場合があります。ロード命令は10110として指定される場合があります。これらのバイナリオペコードを命令セットに割り当てるには、どのようなプロセスが考えられますか。


8
Monte Dalrympleの「Verilog HDLを使用したマイクロプロセッサ設計」は、Z80 CPUの非常に詳細な設計アプローチを提供します。それから、あなたはあなたの質問について多くを学ぶと思います。しかし、他の命令セットの統計分析、コンパイラーの出力など、特定の選択に関する多くの考慮事項があります。しかし、その本から始めることをお勧めします。それは既知のデザインから始まりますが、彼はそれについて詳細に説明します。あなたはいくつかのことを取り上げると思います。良書。
ジョンク

または、おそらく、実行エンジンの設計について尋ねており、命令のビットがそれに対してどのように機能するのか疑問に思っていますか?あなたの言葉遣いからはわかりません。
ジョンク

2
他の誰かがこの質問をします。火曜日でなければなりません。
イグナシオバスケス-エイブラムス

5
@Stevenそれについて考えてください。場合あなたが ISAを設計しなければならなかった、何でしょう、あなたが考えますか?あなたの指示がすべて同じ長さではない場合、どの指示のために短いまたは長い指示語をどのよう選びますか?あなたが設計しなければならなかった場合はデコードステージを、あなたは何でしょう望むように見えるようにあなたのISAのために?質問は不必要に広範だと思います(したがって、完全に答えることはほぼ不可能です)が、自分自身の考えを入れて、答えるために本を書く必要のない正確な質問をすることで、多くのことを改善できますそれ。
マーカスミュラー

4
RISC-Vの仕様は、機械語命令のエンコーディングについての公平なビットを含む、彼らはすべてのレベルで作られたデザインの決定、について話しています。(これはプロセッサマニュアルでは珍しいことです
。RISC

回答:


6

多くの場合、選択はかなりtime意的であるか、ISAが時間とともに成長するため、「最適な場所」に基づいています。ただし、MOS 6502は、限られたトランジスタから可能な限り絞り出そうとすることによってISAデザインが大きな影響を受けたチップの素晴らしい例です。

チェックアウト6502がリバースエンジニアリングされた方法を説明するこのビデオは特に以降34:20からを。

6502は1975年に導入された8ビットマイクロプロセッサです。Z80より60%少ないゲート数でしたが、2倍の速さでした(レジスタなどの点で)制約はありましたが、エレガントな命令セット。

わずか3510個のトランジスタが含まれています。これらは、後で光学的に収縮して6502のさまざまな層を形成するいくつかの大きなプラスチックシートの上をcう小さなチームによって手で引き出されました。

以下に示すように、6502は命令オペコードとタイミングデータをデコードROMに渡し、次に特定の複雑な状況でROMの出力を無効にすることを目的とする「ランダム制御ロジック」コンポーネントに渡します。

6502ブロック図

ビデオの37:00では、デコードROMのテーブルを見ることができます。この表には、特定の制御出力に対して「1」を取得するために入力が満たす必要がある条件が示されています。このページでも見つけることができます

この表のほとんどのものには、さまざまな位置にXがあります。例を見てみましょう

011XXXXX 2 X RORRORA

つまり、オペコードの最初の3ビットは011、Gは2でなければなりません。他には何も関係ありません。その場合、RORRORAという名前の出力がtrueになります。すべてのRORオペコードは011で始まります。しかし、011で始まる他の命令もあります。これらは、おそらく「ランダム制御ロジック」ユニットによって除外する必要があります。

したがって、基本的に、オペコードが選択されたため、互いに同じことを行う必要のある命令が、ビットパターン全体で共通点を持っています。これは、オペコードテーブルを見ればわかります。すべてのOR命令は000で始まり、すべてのストア命令は010で始まり、ゼロページアドレッシングを使用するすべての命令はxxxx01xxの形式です。もちろん、一部の命令は「適合」していないようです。なぜなら、目的は完全に通常のオペコード形式ではなく、強力な命令セットを提供することだからです。そして、これが「ランダム制御ロジック」が必要だった理由です。

上記のページには、ROMの出力行の一​​部が2回表示されると書かれています。「これは、希望する行の出力をルーティングする方法がないため、同じ行を別の再び場所。」エンジニアがこれらのゲートを1つずつ手書きし、突然設計の欠陥に気づき、プロセス全体の再起動を回避する方法を考え出そうとしているのを想像できます。


22

ISAの年齢によって異なります。

ハンドデザインの初期、さらにはCPUがディスクリートロジックから組み立てられた場合、ロジックデザインが最初になり、大幅に最小化され、ISAビットパターンはその最小化に必要な値でした。ロジックワーク。

そのため、いくつかのマルチプレクサーがALU出力をGPレジスタファイルの入力に接続できるようにする制御信号の特定のパターン、ALUに加算、減算、AND、ORなどを指示する制御信号がいくつかあり、レジスタファイルへのアドレスビット。これら3つの信号グループは、命令内のフィールドを形成します。各グループはまとめられ、その詳細な意味はそのユニット(ALUなど)の設計から生じますが、命令デコーダーを設計するまで、グループは任意の順序で配置できます。(x86は十分に古いので、適切な場所を見るとこの一部を検出できます。これはまったく新しい設計ではなく、古い8080から派生したものです)

後のISAは、「クリーンアップ」され、より定期的かつ簡単に使用できるようになります。ハードウェアを使用して、ISAと実際のハードウェアレベルの制御信号を変換することもあります。これらは、「CISC」または「Complex Instruction Set Coding」と呼ばれます。x86の "Rep"命令プレフィックスはこの単純な例です。FORループを記述する必要をなくすために、次の命令が何度も繰り返されます。

その後(1980年代)、ARMプロセッサで見られる直接エンコード(RISC-Reduced Instruction Set Coding)のシンプルなスタイルに戻りました。これは当時のASICのサイズが小さいことと、32ビットCPUを搭載したいという願望によって推進されました。そのため、複雑な命令セットデコーダーの余剰容量がなく、CPUを約20,000ゲートまで下げることができました。(一時的にパフォーマンスが向上しました。なぜなら、人々はまだCISCデコーダを高速化する技術を開発していなかったからです-それは1995年にPentium Proで実現しました)

そして今日では重要ではありません-CPUはいくつかの命令を一度に読み、何百万ものトランジスタをデコード、並べ替え、可能な限り多くの実行に費やして、最古の人のために書かれたプログラムを高速化しますISAのスタイル。


2
本当にCISCを「使いやすい」と呼ぶかどうかはわかりません。それは当初の意図だったかもしれませんが、30年後、彼らは「少なくとも使いやすい」というアンチテーゼです(少なくともRISC ISAと比較して)。
tonysdg

2
それらが使いやすい点があります...コンパイラが比較的些細なプログラムだった頃の規則性(直交性が大きなトピックでした)、またはコンパイラからのより少ない変換を必要とするより高いレベルの操作を直接サポートすることによって。しかし、それはかなり前のことであり、現存するCISCには、元の命令セットの上に非常に多くの修正層があります。コンパイラもすべての認識から変更されました-gccによって実行された1000程度の最適化パスは、当時は考えられなかったでしょう。それで、当時「今」「簡単」だったものは、ほとんど関係がありません。
ブライアンドラモンド

4
この区別は侵食され(「RISC」セットにより命令が追加される)、VLIWなどの新しいさらに複雑なアーキテクチャに取って代わられました。本当に唯一のコンセンサスは、x86(16ビットおよび32ビット)を使用するのは難しいということです
pjc50

1
@tonysdg:RISCとCISCは使いにくいです。「プログラマーフレンドリー」の良い比較は、68k対ARMを比較することです。ARMはコンパイラ用に設計されているため、RAMからデータを取得してRAMに書き戻すには、多くの手動作業が必要でした。68kはアセンブリプログラマ向けに設計されており、RAM内のデータを直接操作できます。68k ISAを見ると、最近のRISC ISAに非常によく似ていることがわかります。1つ例外があります-RAMで直接操作できるのに対し、RISCではレジスタのみ操作できます。
スリーブマン

1
マイクロコードは、主にCISC属性です。ただし、マイクロコードなしでCISCを実装することもできます。命令デコーダーはより複雑になります。また、Pentium-Pro以降の一部のCISCが内部的にRISCと記述されています。各CISC命令を1つ以上の内部RISC opsに変換します。マイクロコードの別名(スーパースカラー実行ユニットでは区別がぼやけます)
ブライアンドラモンド

9

同様の指示をグループ化すると、パターンが出現します。これは、ISAマニュアルが実際に命令語のどのビットが機能、レジスタの選択などに対応するかを示しているARMで非常に明白です。しかし、X86についても推論できます。

最終的に、オペコードの「関数」部分は、特定の関数またはパイプライン操作のシーケンスを実際にアクティブにするバイナリーツーワンホットデコーダーに入ります。ステートマシンのデコードを必要とする可変長命令を検討している場合を除き、通常はステートマシンの内容とは関係ありません。


基本的に、チップ上で可能な限り少ないトランジスタ数を求めているということです。私はOPの質問の文脈で完全に同意します。OPの質問では、きちんとした命令セットのために何百もの余分なトランジスタを買う余裕はありません。100万トランジスタのCPUにはあまり気にする必要はありませんが、多くの場合、下位互換性のためにCPUを保持しています。
ハーパー-モニカの復活

@Harperトランジスタは小さくなりましたが、トランジスタのサイズはまだ変わらず、その間にクロックレートが大幅に増加したため、まだ理由があります。したがって、大きすぎる命令デコーダーは、パフォーマンスのボトルネックになる可能性があります(多くのCPUが事前デコード命令を事前に選択した理由の1つ)。それはトランジスタの数だけではなく、ダイ面積と組み合わせたクロックレートに関するものです。情報の伝播にはまだ時間がかかり、最新のCPUは光の速度で実行されていませんが、速度の制限からは程遠いため、大幅な改善が期待できます。
ルアーン

@Luaan:実際、「これらすべてのトランジスタで何をするのか」というのは、今日の本当の問題です。このごろ投げられたすべてのL2 / L3キャッシュを見てください。それは、何百万ものトランジスタすべてに対して、より良い使用法がないという黙認です。最新のXeonのキャッシュには20億個以上のトランジスターがあります!
MSalters

6

ある時点で誰かが座って定義しました。

優れたISAを使用すると、デコーダーが可能な限りシンプルになります。

たとえば、ALU命令を使用すると、オペコードの一部のビットをALUの制御ラインに直接送信できます。


素晴らしい回答をありがとう。あなたは皆、これをもっとよく理解するのを助けてくれました。
スティーブン

4
実際には、デコーダーの単純さ以外にも考慮すべき要素がかなりあります。状況や使用目的に応じて、デコーダーの単純さよりも他の要素(コード密度など)のほうが重要になる場合があります。現代のプロセッサでは、ほとんどの場合、コードの密度がデコーダの単純さを上回る可能性があります。
ジェリーコフィン

5

通常、ISAは機能グループに分割します。相補的なペアが単一のビット変更(ロードvsストア)によって区別され、デコード決定ツリーに影響するビットの階層があることが理にかなっています(論理最適化または単に整頓されているため)。

一日の終わりには、機能ブロックのビットの任意の割り当て(命令に「データ」フィールドを配置するのではなく、全体的な設計効率にわずかな影響しか与えませんが、その方法については多くの選択肢があります)重要なパラメータであると感じるものに応じて、ISAエンコーディングを「最適化」します。


1

命令エンコーディングは、両者の間の見苦しい妥協です。

デコードを簡単にするために、それぞれのフィールドを別々にデコードし、実行エンジンの別の部分にルーティングできる単純なフィールドセットが必要です。

可能な限り多くの機能を限られたサイズの命令語に詰め込む。これは、さまざまな一般的な数値をエンコードできる特別な定数形式などにつながります。

前方および後方互換性。可能なすべてのオペコードに機能を割り当てると、後でアーキテクチャを拡張する余地がなくなります。既存のアーキテクチャに追加する場合、新しい命令を予備のオペコードに挿入する必要があります。


1

Randy Hydeの優れた(多少古くなっている場合)Art of Assemblyは、3.3.4「Control Unit and Instruction Sets and following」で詳細に説明されているx86命令セットに入ります。

初期(フォンノイマン以前)のコンピューターシステムのプログラムは、多くの場合、回路に「ハードワイヤード」されていました。つまり、コンピューターの配線が、コンピューターが解決する問題を決定しました。プログラムを変更するには、回路を再配線する必要がありました。非常に難しいタスク。コンピューター設計の次の進歩は、コンピュータープログラマーが一連のソケットとプラグワイヤを使用してコンピューターシステムを簡単に「再配線」できるプログラム可能なコンピューターシステムでした。コンピュータープログラムは、一連の穴(ソケット)で構成され、各行はプログラムの実行中の1つの操作を表します。プログラマは、目的の命令の特定のソケットにワイヤを差し込むことにより、いくつかの命令の1つを選択できます。

その後、彼は非常にキャッチーで、最初の数個のプラグが命令を表し、次のプラグがソースとデスティネーションをエンコードする方法を示します。もちろん、今日では誰も「プラグ」することはありませんが、本当に古いISAの場合、オペコードのビットは基本的に以前のプラグと同じ仕事をします。

次のような結果になります。

ここに画像の説明を入力してください


ハイドからのリンクをありがとう!それは非常に有益であり、彼は優れた指導スタイルを持っているようです。
スティーブン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.