インテルがプロセッサーの内部RISCコアを隠すのはなぜですか？
Pentium Pro（P6マイクロアーキテクチャ）から、Intelはマイクロプロセッサを再設計し、古いCISC命令で内部RISCコアを使用しました。 Pentium Proから、すべてのCISC命令は小さな部分（uop）に分割され、RISCコアによって実行されます。
当初、Intelは新しい内部アーキテクチャを隠し、プログラマに「CISCシェル」の使用を強制することを決定したことは明らかでした。この決定のおかげで、Intelは互換性を損なうことなくマイクロプロセッサアーキテクチャを完全に再設計できたため、合理的です。
しかし、私は1つのことを理解していません。なぜIntelは長年にわたって内部RISC命令セットを隠し続けているのですか？古いx86 CISC命令セットを使用するようなRISC命令をプログラマに使用させないのはなぜですか？
Intelが長い間下位互換性を維持している場合（64ビットモードの隣に仮想8086モードがまだあります）、なぜCISC命令をバイパスしてRISCコアを直接使用するようにプログラムをコンパイルできないのですか？これにより、x86命令セットを徐々に破棄する自然な方法が開かれますが、これは現在では推奨されていません（これがIntelが内部でRISCコアを使用することを決定した主な理由ですか？）.
私が見る新しいIntel 'Core i'シリーズを見ると、AVX、SSE4などを追加するCISC命令セットのみを拡張していることがわかります。
いいえ、x86命令セットは非推奨ではありません。相変わらず人気があります。インテルがRISCのようなマイクロ命令セットを内部で使用する理由は、それらをより効率的に処理できるためです。
そのため、x86 CPUは、x86命令を受け入れ、バックエンドが処理できる最適化された内部形式に変換するフロントエンドに非常に頑丈なデコーダーを持つことで機能します。
この形式を「外部」プログラムに公開することに関して、2つのポイントがあります。
- 安定した形式ではありません。 Intelは、特定のアーキテクチャに最も適合するようにCPUモデル間で変更できます。これにより、効率を最大限に高めることができます。また、内部使用および外部使用のために固定された安定した命令形式を採用しなければならない場合、この利点は失われます。
- それを行うことによって得られるものは何もありません。今日の巨大で複雑なCPUでは、デコーダはCPUの比較的小さな部分です。 x86命令をデコードすることはそれをより複雑にしますが、CPUの残りは影響を受けないので、全体として、特に「レガシー」コードを実行するためにx86フロントエンドがまだ必要なため、ほとんど何も得られません。そのため、x86フロントエンドで現在使用されているトランジスタを保存することすらありません。
これは完全な配置ではありませんが、コストはかなり小さく、CPUを設計してtwo完全に異なる命令セットをサポートするよりもはるかに良い選択です。 （その場合、CPUの内部アーキテクチャに最適になるように自由に調整できるという理由だけで、おそらく内部で使用するthirdセットを発明することになります）
本当の答えは簡単です。
RISCプロセッサの実装の主な要因は、複雑さを軽減し、速度を向上させることでした。 RISCの欠点は、命令密度が低いことです。つまり、RISCのような形式で表現された同じコードは、同等のCISCコードよりも多くの命令を必要とします。
この副作用は、CPUがメモリと同じ速度で実行されている場合、または少なくとも両方が合理的に同等の速度で実行されている場合はあまり意味がありません。
現在、CPU速度と比較したメモリ速度は、クロックに大きな違いを示しています。現在のCPUは、メインメモリよりも5倍以上速い場合があります。
この技術の状態は、CISCが提供するより高密度のコードを優先します。
キャッシュはRISC CPUを高速化できると主張できます。しかし、CISC cpusについても同じことが言えます。
同じサイズのキャッシュがCISCが提供する高密度コードにより多くの影響を与えるため、CISCとキャッシュを使用すると、RISCとキャッシュよりも大幅に速度が向上します。
もう1つの副作用は、RISCがコンパイラの実装により難しいことです。 CISC cpus向けのコンパイラの最適化が簡単です。等.
Intelは彼らが何をしているかを知っています。
ARMにはThumbと呼ばれるコード密度の高いモードがあります。
Intelが長い間下位互換性を維持している場合（64ビットモードの隣に仮想8086モードがまだあります）、なぜCISC命令をバイパスしてRISCコアを直接使用するようにプログラムをコンパイルできないのですか？これにより、x86命令セットを徐々に破棄する自然な方法が開かれますが、これは現在では推奨されていません（これがIntelが内部でRISCコアを使用することを決定した主な理由ですか？）.
これのビジネス上の角度を見る必要があります。 Intelは実際にx86からの脱却を試みましたが、会社にとって金の卵を産むのはガチョウです。 XScaleとItaniumは、x86のコアビジネスの成功レベルにさえ近づきませんでした。
基本的にあなたが求めているのは、開発者からの暖かいあいまいさと引き換えに、Intelに手首を切り裂くことです。 x86を損なうことは彼らの利益にはなりません。より多くの開発者がx86をターゲットにすることを選択する必要がないようにするものはすべて、x86を傷つけます。それは、順番に、彼らを弱体化させます。
答えは簡単です。 Intelはdevelopers！のCPUを開発していません。彼らは購入の決定を下す人々のためにそれらを開発しています。
Intelはずっと前に（当然ですが）CPUの下位互換性を維持することを約束しました。人々は、新しいIntelベースのコンピューターを購入すると、現在のソフトウェアのallが正確に実行されることを知りたい古いコンピューターと同じです。 （ただし、うまくいけば、もっと速く！）
さらに、Intelはexactlyコミットメントがどれほど重要であるかを知っています。 Itanium CPUで知っている人の数youは正確に何人ですか？！？
気に入らないかもしれませんが、x86にとどまるという1つの決定が、Intelを世界で最も有名なビジネス名の1つにした理由です！
@jalfの答えはほとんどの理由をカバーしていますが、言及されていない興味深い詳細が1つあります。内部RISCのようなコアは、ARM/PPC/MIPSなどの命令セットを実行するように設計されていません。 x86-taxは、電力を消費するデコーダーだけでなく、コア全体である程度支払われます。つまり、x86命令のエンコードだけではありません。奇妙なセマンティクスを持つすべての命令です。
Intelは、命令ストリームがx86以外のものであり、命令をより直接uopsにマッピングする動作モードを作成したと仮定します。また、各CPUモデルにはこのモード用に独自のISAがあるため、好きなときに内部を自由に変更でき、命令用に最小限のトランジスタで公開できます。この代替形式のデコード。
おそらく、x86アーキテクチャー状態にマップされた同じ数のレジスターしか持っていないので、x86 OSはCPU固有の命令セットを使用せずにコンテキストスイッチでそれを保存/復元できます。しかし、その実際的な制限を捨てると、通常はマイクロコード用に予約されている隠された一時レジスタを使用できるため、さらにいくつかのレジスタを使用できます。1。
後のパイプラインステージ（実行ユニット）に変更のない代替デコーダーがある場合、this ISAはまだ多くのx86偏心を持っています。これは非常に優れたRISCアーキテクチャではなく、単一の命令が非常に複雑になることはありませんが、x86の他の狂気の一部はまだそこにあります。
例：左/右シフトでは、シフトカウントが1でない限り、オーバーフローフラグは未定義のままになります。その場合、OF =は通常の符号付きオーバーフロー検出です。回転のための同様の狂気。ただし、公開されたRISC命令は、フラグのないシフトなどを提供できます（通常、一部の複雑なx86命令に入る複数のuopの1つまたは2つだけを使用できます）。したがって、これは主な反論としては本当に成り立ちません。
RISC ISA用のまったく新しいデコーダーを作成する場合は、RISC命令として公開されるx86命令の一部を選択して選択させることができます。これにより、コアのx86特化が多少緩和されます。
単一のuopは多くのデータを保持できるため、命令のエンコードはおそらく固定サイズではありません。すべてのinsnが同じサイズである場合、意味をなすよりもはるかに多くのデータ。単一のマイクロ融合uopは、32ビットのイミディエイトと、2つのレジスタと32ビットのディスプレイスメントを備えたアドレッシングモードを使用するメモリオペランドを追加できます。 （SnB以降では、単一レジスタアドレッシングモードのみがALU opsとマイクロヒューズできます）。
uopは非常に大きく、固定幅ARM命令にあまり似ていません。固定幅の32ビット命令セットは一度に16ビットのイミディエイトしかロードできないため、32ビットアドレスのロードにはロード即時の低半分/負荷高-イミディエートペアx86はこれを行う必要がないため、レジスタ内で定数を保持する能力を制限するGPレジスタが15個だけではひどくなりません（15は7レジスタ以上の大きな助けです。しかし、再び31に2倍にすると、はるかに少なくなります。いくつかのシミュレーションが見つかりました。RSPは通常汎用ではないため、15 GPレジスタとスタックに似ています。）
TL; DRサマリー：
とにかく、この答えは「x86命令セットは、おそらくx86命令を迅速に実行できるようにする必要があるCPUをプログラムするための最良の方法」に要約されますが、うまくいけばその理由を明らかにします。
フロントエンドとバックエンドの内部uop形式
フロントエンドとバックエンドのuop形式がIntel CPUで表現できるものが異なる1つのケースについては、 Micro fusion and addressing mode も参照してください。
脚注1：マイクロコードで一時的に使用する「隠し」レジスタがいくつかあります。これらのレジスタは、x86アーキテクチャのレジスタと同様に名前が変更されるため、マルチuop命令は順不同で実行できます。
例えばxchg eax, ecxは、Intel CPUで3つのuopとしてデコードします（ why？ ）。私たちの最も良い推測は、これらがMOVに似たtmp = eax; ecx=eax ; eax=tmp;。その順序で、私は〜1サイクルでdst-> src方向のレイテンシを測定するのに対し、他の方法では2を測定します。そして、これらの移動uopは、通常のmov命令とは異なります。彼らはゼロレイテンシーのmov-eliminationの候補者ではないようです。
http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/ も参照してください。PRFサイズを実験的に測定し、保持するために使用される物理レジスターを考慮する必要があるという記述があります。隠しレジスタを含むアーキテクチャの状態。
デコーダーの後のフロントエンドでは、物理レジスタファイルにレジスタの名前を変更するissue/renameステージの前に、内部uop形式はx86 reg番号に似たレジスタ番号を使用しますが、スペースがありますこれらの隠しレジスタに対処するために。
Uop形式は、アウトオブオーダーコア（ROBおよびRS）内では、バックエンド（別名issue/renameステージ後）とも多少異なります。 int/FP物理レジスタファイル それぞれHaswellに168個のエントリがあります であるため、uopの各レジスタフィールドは、その多くに対応するのに十分な幅である必要があります。
リネームはHWにあるので、静的にスケジュールされた命令を直接バックエンドに供給するのではなく、リネームを使用する方が良いでしょう。そのため、x86アーキテクチャレジスタ+マイクロコードのテンポラリと同じ大きさのレジスタセットを使用できます。
バックエンドは、WAW/WARの危険を回避するフロントエンドの名前変更機能と連携するように設計されているため、必要な場合でもインオーダーCPUのように使用できません。これらの依存関係を検出するためのインターロックはありません。それはissue/renameで処理されます。
Issue/renameステージのボトルネックなしでバックエンドにuopをフィードできるとすればいいかもしれません（Skylakeでの4ワイド対4 ALU + 2ロード+ 1ストアポートなど、最新のIntelパイプラインの最も狭いポイントバックエンド）。しかし、それを行った場合、キャッシュのミスが長時間負荷を停止した場合に、レジスタの再利用と、まだ必要な結果への踏み込みを避けるために、コードを静的にスケジュールできるとは思いません。
そのため、uopキャッシュまたはIDQではなく、デコードをバイパスするだけで、uopをissue/renameステージに送る必要があります。次に、正常なハザード検出を備えた通常のOoO execを取得します。レジスタ割り当てテーブルは、16 +少数の整数レジスタを168エントリの整数PRFに名前変更するように設計されています。 HWが、論理レジスタのより大きなセットの名前を同じ数の物理レジスタに変更することは期待できませんでした。それにはより大きなRATが必要です。