CISCの実装を選択する理由は多数あります。最も顕著な理由は、既存のCISC命令セットとのバイナリ互換性です。ソフトウェアバイナリ翻訳技術は改善されましたが、ハードウェアベースの互換性にはいくつかの技術的な利点(翻訳キャッシュが少ないという欠点もあります)と、信頼性が高いという技術的な利点が少ないことがあります。
コード密度は、おそらくCISCを選択する2番目に重要な理由です。ルネサスRXは、コードメモリサイズが重要なコスト要因であるマイクロコントローラーをターゲットとするため、コード密度専用のCISCとして設計されました。可変長命令、複雑な命令(主にアドレス指定モードの増加)、暗黙的なオペランド、およびレジスタ数の削減はすべて、コード密度にメリットがあります。
CISCを選択した歴史的な(そして、私の考えでは見当違いの)理由は、より高いレベルの言語を使用するプログラマとプロセッサの間のセマンティックギャップを埋めることでした。一般に、複雑な命令はより単純な命令のシーケンスで置き換えることができるため、RISCの高レベル言語コンパイラの複雑さは、言語に一致するCISCの場合よりもはるかに複雑である必要はありません。RISCは、「セマンティッククラッシュ」(プロセッサ命令が対応する言語ステートメントよりも多かれ少なかれ処理する場所)を回避し、強度の削減とスケジューリングの最適化を促進します。(詳細については、「CISCとRISCに関連するコンパイラ開発作業のトレードオフは何ですか?」を参照してください。)
命令の実行に関連する大きな固定費が発生する可能性があります。これにより、比較的複雑な命令を使用して、このオーバーヘッドを実際の作業に分散させることができます。動的な命令数を減らすと、パフォーマンスが向上します。ロジックとRAMのコストがROMのコストよりもはるかに大きい場合、命令はマイクロコードを検索してデコードされたため、複雑な命令に対するインセンティブは重要でした。
おそらく歴史的証拠と矛盾するCISCを使用する理由は、マイクロライブラリを各マイクロアーキテクチャに対して最適化できる一方で、標準ライブラリは新しい実装の機能を活用するのに時間がかかる可能性があるためです。REP MOVSBのマイクロコードの最適化レベルに対するmemcopyのソフトウェア実装の最適化レベルは、ライブラリがマイクロコードよりも注意を引くことができることを意味します。これの一部は、より広範なユーザーベースを対象とするプロセッサベンダーからもたらされる可能性があるため、開発者またはユーザーの局所的な関心が実装作業にバイアスをかけることができるオープンソースまたは内部ソフトウェアと比較して、作業の正当化がより難しい場合があります
プロセッサで最適化された標準ライブラリを出荷できることには大きな魅力があります。プラットフォーム標準ライブラリの保存と実行は、ソフトウェアとハードウェアのコードサインによって大幅に最適化できます。複雑な命令とプラットフォームアブストラクションレイヤーコールの違いは微妙な(または存在しない)場合があります。RISC設計では、一般的な命令セットで提供されていない操作を特殊なハードウェアで使用する、巧妙なキャッシュとデコードを使用する、レジスタオペランドを指定するなど、CISCが複雑な命令に対して行うのと同じ実装手法を使用できます(ただし、CISCは多くの場合、機能ごとのABIと同様の専用レジスタを使用します)。CISCに関連付けられているメンタルモデルは、このような最適化を促進できます。さらに、ユーザーが「
比較的複雑な命令のデコードは、命令のシーケンスがセマンティックユニットとして認識される同等のイディオム認識のRISC手法よりもオーバーヘッドが少なくなります(そして、おそらくより確実に意図を正確に修正できます)。このオーバーヘッドの違いは、小規模な実装で最も顕著になりますが、この情報を使用するオーバーヘッドにより、デコードの節約の重要性が低下します。
追加のコンテキスト情報は、ハードウェアの最適化を促進できます。たとえば、メモリ内の値をインクリメントするとき、ハードウェアはメモリアドレスが2回(ロードとストアに)使用されることを認識し、キャッシュ方法のメモ化と変換キャッシュの機会を提供します。複雑な命令は、そのような情報を明示的に提供できます。複雑な命令では、中間値には明示的な有効期間(命令の有効期間)があります。従来のRISCレジスタでは、活性の終了を示すために値を明示的に上書きする必要があります。(注:RISCは、各使用後に常にゼロになるレジスタを指定できます。これにより、使い捨ての一時的な値を指定する手段が提供されます。このような命令はやや複雑になります。)
実装の詳細が抽象化レイヤーの背後に隠されていない場合、異なるマイクロアーキテクチャを使用して異なるトレードオフを最適化することがより困難になります。マイクロアーキテクチャの詳細をアーキテクチャの保証として公開すると、マイクロアーキテクチャが互換性の保証に固定されます。PALソフトウェアは複雑な命令と同じように最適化できますが、そのためにはハードウェアとソフトウェアのコードサインが必要です。組織の分離と多様性により、コード署名がより困難になります。
複雑な命令は、特権状態への保護されたアクセスを提供できます。たとえば、複雑な命令は多くの場合、割り込みに関してアトミックです。RISC命令セットは、割り込みを一時的に中断するユーザーレベルのメカニズムを提供できますが、ソフトウェアは割り込みが発生した場合に明示的に操作を再試行するため、リンクロードのようなものもあります。
同様に、複雑な命令は、制御されたアクセスや特権情報の使用を提供できます。実行された操作はセマンティクスを制御しているため、実際の特権違反は回避できます。RISC指向の代替には、PALコード(通常、かなりのオーバーヘッドがあります)や、特権状態を持つ構成レジスタ(またはレジスタのシャドウコピー)へのマスクアクセスが含まれます。一般的なソリューション(RISC)を提供することは、1つまたはいくつかの特殊なケース(CISC)にソリューションを提供するよりも困難ですが、より強力で、特殊なケースの蓄積に対して脆弱ではありません。重要な特別なケースが少数であると考える場合、CISCはより魅力的です。
複雑な命令は、ソフトウェアから状態を隠すこともできます。そのような顕著な利点の1つは、コンテキストの保存と復元です。状態を保存および復元する命令を使用すると、アーキテクチャは、状態をメモリに転送するための特定のメカニズムではなく、コンテキストサイズをOSに伝えるだけで済みます。これにより、レガシーOS上で実行されるアプリケーションは、状態を追加するISA拡張機能を使用できます。(再び、PALソフトウェアは同じ機能を提供できます。)
x86の複雑さの多くは、多くの拡張機能間の互換性に起因しています。複雑で直交性の低い命令(コード密度に有用)で、一般に必要ではないことが判明した作業を削除し、不必要な依存関係チェーン(たとえば、キャリービット1つ、動的シフト量レジスタ1つのみ)を回避し、一般的に使用され、複雑な命令内で最適化することができます-これらのいずれも、新しい命令を追加し、ISAの美的満足度を下げる必要があります。
多くの場合、RISCではこのような問題は発生しません。これは、命令が非常に直交的でプリミティブだからです。場合によっては、RISCで新しいプリミティブを追加する必要があるかもしれませんが、そのようなものは通常、複数の用途に適用できます。
さらに、複雑な命令をサポートするためのインフラストラクチャが整ったら、追加の複雑な命令に対する障壁が軽減されます。つまり、非反復の複雑な命令のコストの大部分。RISC ISAには、CISCy機能の導入を補完する障害が強くあります。
また、x86の拡張頻度は、汎用コンピューティングおよびマーチャントプロセッサモデルの人気に一部起因している可能性があります(これらはバイナリ互換性の重要性も高めます)。RISC ISAは多くの場合、システムのベンダーに結び付けられており、アプリケーションに焦点を絞り、特定のRISC ISAの実装をめぐる競合がないため、命令セットの拡張機能をマーケティングに使用することをやめさせています。また、人気により、新しい拡張機能の開発コストはそれほど重要ではありません(量が多い場合、非経常的な費用はそれほど重要ではありません)。
x86互換性の哲学は、おそらく、よりクリーンなブレークを提供するのではなく、既存のメカニズムを拡張する方向に偏っています。つまり、新しい機能は既存の機能の影響を受けます。拡張の頻度が高くなると、インクリメンタルな変更も促進され、メカニズムの再利用が促進され、直交性が低下する傾向があります。
古典的なMIPS(最新バージョンのMIPSのサブセットであり、さまざまなオプションのISA拡張を除く)のアカデミックプレゼンテーションと最新のx86(バイナリ互換性を16ビット8086まで遡り、さらにアセンブリレベルの準互換性をさらに遡る)の比較過去のすべての手荷物については、CISCの最良のケースでも、RISCの現実的なケースでもありません。