マイクロコード

ハードウェアレベルでは、プロセッサはさまざまなタスクを実行する複数の独立した回路領域、つまり「ユニット」で構成されています。一般的に見られるユニットには、加算や2つの数値の比較などの命令を実行する算術論理演算ユニット（ALU）、外部メモリへのデータの読み書きを行う回路、および処理中にこれらの値を格納するためのオンボードメモリの小さな領域などがあります。ほとんどの設計では、レジスタファイルと呼ばれる追加の高性能メモリが、現在の命令に必要な値だけでなく、一時的な値を格納するために使用されます。^{[ 3 ]}

命令を正しく実行するには、さまざまな回路を順番にアクティブ化する必要があります。たとえば、メモリからロードされていない2つの数値を加算することはできません。RISC設計では、これらの命令の適切な順序は、主にプログラマ、または少なくともプログラマが使用するプログラミング言語のコンパイラに依存します。たとえば、メモリ内の2つの数値を加算して結果をメモリに格納するには、コンパイラは、一方の値を1つのレジスタにロードし、もう1つの値を別のレジスタにロードし、ALUで加算関数を実行して結果をレジスタに格納し、そのレジスタをメモリに格納する命令を出力する場合があります。^{[ 3 ]}

このより高レベルの概念である「メモリ内のこれら 2 つの数値を加算する」を実行するために必要な命令のシーケンスは、複数の命令を必要とする場合があり、これらの命令がメイン メモリに格納されている場合は、これがパフォーマンスのボトルネックとなる可能性があります。これらの命令を 1 つずつ読み込むには、実際のデータの読み書きに使用できる時間が費やされます。このため、RISC 以外の設計では、データの格納場所が大きく異なるさまざまな命令が多数あるのが一般的です。たとえば、MOS 6502には、加算命令 の 8 つのバリエーションがあり、ADCこれらは 2 つのオペランドを探す場所だけが異なります。^{[ 4 ]}

最終的な操作に最も近い命令のバリエーション、つまり「オペコード」を使用することで、命令数を1つに減らすことができ、プログラムコードで使用されるメモリを節約し、データバスを他の操作のために空けておくことでパフォーマンスを向上させることができます。ただし、内部的には、これらの命令は個別の操作ではなく、ユニットが実際に実行する操作のシーケンスです。メモリから読み取った単一の命令を内部動作のシーケンスに変換するのは、プロセッサ内の別のユニットである制御ユニットの役割です。 ^{[ 5 ]}

マイクロコードの基本的な考え方は、命令シーケンスを実装するカスタムハードウェアロジックを、プロセッサ内の「マイクロコードエンジン」で実行される一連の単純な命令に置き換えることです。カスタムロジックシステムでは、さまざまな制御線に一連の電圧を出力するダイオードやゲートが複数あるのに対し、マイクロコードエンジンはこれらの線に接続され、エンジンがマイクロコード命令を順番に読み込むにつれて、これらの線がオン/オフされます。マイクロコード命令は、多くの場合、これらの線にビットエンコードされます。たとえば、ビット8が真であれば、ALUがデータ待ちで一時停止することを意味します。この点において、マイクロコードは、穴が押すべき鍵盤を表す自動演奏ピアノの紙ロールにいくらか似ています。

カスタムロジックとマイクロコードの違いは些細なものに見えるかもしれません。一方はダイオードとゲートのパターンを用いて命令をデコードし、一連の信号を生成するのに対し、もう一方は信号をマイクロ命令としてエンコードし、それを順番に読み取ることで同じ結果を得ます。決定的な違いは、カスタムロジック設計では個々のステップを変更するとハードウェアの再設計が必要になる点です。マイクロコードを使用する場合、変更されるのはマイクロコードを格納するメモリに格納されているコード、またはマイクロコードが制御ストアにロードされるストレージデバイスのみです。これにより、マイクロコードシステムの問題修正がはるかに容易になります。また、命令の複雑さに実質的な制限はなく、使用できるメモリ量によってのみ制限されることを意味します。

コンピュータのソフトウェアスタックの最下層は、従来はプロセッサ用の生の機械語命令でした。マイクロコードプロセッサでは、これらの命令のフェッチとデコード、および実行はマイクロコードによって行われる場合があります。混乱を避けるため、マイクロプログラムに関連する各要素は、マイクロ命令、マイクロアセンブラ、マイクロプログラマなど、マイクロ接頭辞によって区別されます。 ^{[ 6 ]}

複雑なデジタルプロセッサでは、本質的に非同期的に並列に実行する必要のあるサブタスクを委任するために、複数の（おそらくマイクロコードベースの）制御ユニットを使用することもあります。たとえば、 VAX 9000には、命令を取得してデコードするためのハードワイヤードの IBox ユニットがあり、それをマイクロコード化された EBox ユニットに渡して実行させます^{[ 7 ]} 。また、 VAX 8800には、マイクロコード化された IBox とマイクロコード化された EBox の両方があります^{[ 8 ] 。}

高水準プログラマー、あるいはアセンブリ言語プログラマーでさえ、通常はマイクロコードを見たり変更したりすることはありません。マシンコードは、同一ファミリー内の異なるプロセッサ間である程度の互換性を維持することが多いのに対し、マイクロコードは、特定のプロセッサ設計自体に内在する要素であるため、設計された電子回路上でのみ動作します。

エンジニアは通常、プロセッサの設計段階でマイクロコードを記述し、それを読み出し専用メモリ(ROM) またはプログラマブルロジックアレイ(PLA) ^{[ 9 ]}構造、あるいはその両方の組み合わせに格納します。^{[ 10 ]}しかし、マイクロコードの一部または全部がスタティックランダムアクセスメモリ(SRAM) またはフラッシュメモリに格納されているマシンも存在します。これは、コンピュータの文脈では従来、書き込み可能な制御ストアと呼ばれ、読み出し専用メモリまたは読み書き可能なメモリのいずれかになります。後者の場合、CPU の初期化プロセスは、別の記憶媒体からマイクロコードを制御ストアにロードし、命令セットのバグを修正したり、新しいマシン命令を実装したりするためにマイクロコードを変更する可能性があります。

マイクロプログラムは、ハードウェア回路の非常に基本的なレベルでCPUを制御する一連のマイクロ命令で構成されています。例えば、典型的な水平方向のマイクロ命令1つは、次のような操作を同時に指定することができます。

• レジスタ1をALUのA側に接続する
• レジスタ7をALUのB側に接続する
• ALUを2の補数加算を実行するように設定する
• ALUのキャリー入力をゼロに設定する
• ALUの出力をレジスタ8に接続します。
• ALUステータスフラグ（負、ゼロ、オーバーフロー、キャリー）から条件コードを更新します。
• 次のマイクロ命令のために、指定されたμPCアドレスへマイクロジャンプする。

プロセッサのすべての機能を1サイクルで同時に制御するために、マイクロ命令は50ビットよりも広いサイズになることがよくあります。例えば、エミュレータ機能を備えた360/85では128ビットです。マイクロプログラムは、可能な限り高速に実行できるように慎重に設計および最適化されています。マイクロプログラムの実行速度が遅いと、マシン命令の実行速度が遅くなり、そのような命令を使用する関連アプリケーションプログラムのパフォーマンスが低下するためです。

プロセッサのマイクロプログラムは、通常のプログラマーが見るアセンブリ命令よりも、より原始的で、全く異なる、ハードウェア指向のアーキテクチャ上で動作します。マイクロコードはハードウェアと連携して、プログラマーが見るアーキテクチャを実装します。基盤となるハードウェアは、見えるアーキテクチャと固定的な関係を持つ必要はありません。これにより、特定の命令セットアーキテクチャを、多様な基盤となるハードウェアマイクロアーキテクチャ上で容易に実装できます。

IBM System/360 は 16 個の汎用レジスタを備えた 32 ビット アーキテクチャを採用していますが、System/360 の実装のほとんどは、より単純な基盤となるマイクロ アーキテクチャを実装するハードウェアを使用しています。たとえば、System/360 モデル 30 は、算術論理演算ユニット (ALU) とメイン メモリへの 8 ビット データ パスを持ち、汎用レジスタは高速コア メモリの専用ユニットに実装されています。System /360 モデル 40 は、ALU への 8 ビット データ パスとメイン メモリへの 16 ビット データ パスを持ち、汎用レジスタは高速コア メモリの専用ユニットに実装されています。モデル50 は完全な 32 ビット データ パスを持ち、汎用レジスタは高速コア メモリの専用ユニットに実装されています。^{[ 12 ]}モデル 65 からモデル 195 までは、より大きなデータ パスを持ち、汎用レジスタはより高速なトランジスタ回路に実装されています。このように、マイクロプログラミングによってIBMは、ハードウェア構成が大きく異なり、コストと性能の幅も広いSystem/360モデルを多数設計することが可能になり、しかもそれらすべてにアーキテクチャ上の互換性を持たせることができました。これにより、各モデルごとに作成する必要のある固有のシステムソフトウェアプログラムの数を劇的に削減することができました。

デジタル・イクイップメント・コーポレーションのPDP-11は、8つの汎用レジスタを備えた16ビットアーキテクチャです。1970年に発表され、基本アーキテクチャは1990年代まで変更されませんでした。シリーズの最初のマシンだけがマイクロコード化されていませんでした。1972年から1976年にかけて、PDP-11の基盤となるマイクロプログラムの幅は22ビットから64ビットまで変化しました。マイクロプログラムの長さは256ワードから1,024ワードまで変化し、マイクロプログラムの長さが長いほど、一般的に幅は狭くなりました。^{[ 13 ]}マイクロプログラムの幅が多様であることから、わずか4年間で少なくとも7つの異なるPDP-11の実装があったことがわかります。

デジタル・イクイップメント・コーポレーション（DEC）も、VAXシリーズのコンピュータで同様のアプローチを採用した。その結果、VAXプロセッサはそれぞれ異なるマイクロアーキテクチャを使用しているにもかかわらず、プログラマから見えるアーキテクチャは変わらない。

マイクロプログラミングは、プロセッサの欠陥（バグ）を修正するための現場変更コストも削減します。バグは、ハードウェアのロジックや配線を変更するのではなく、マイクロプログラムの一部を置き換えるだけで修正できる場合が多いからです。

1946年にアラン・チューリングによって設計されたACEコンピュータはマイクロプログラミングを使用していた。^{[ 14 ]}

1947年、 MIT Whirlwindの設計では、コンピュータ設計を簡素化し、アドホックな方法から脱却する方法として、制御ストアの概念が導入されました。制御ストアはダイオードマトリックスです。これは2次元格子で、一方の次元はCPUの内部クロックからの「制御時間パルス」を受け取り、もう一方の次元はゲートやその他の回路の制御信号に接続されます。「パルス分配器」は、CPUクロックによって生成されたパルスを受け取り、それを8つの個別の時間パルスに分割します。それぞれのパルスは格子の異なる行をアクティブにします。行がアクティブになると、それに接続されている制御信号がアクティブになります。^{[ 15 ]}

1951年、モーリス・ウィルクス^{[ 16 ]}は、コンピュータソフトウェアの条件分岐に似た条件付き実行の概念を追加することで、この概念を拡張しました。彼の最初の実装は、一対のマトリックスで構成されていました。最初のマトリックスは、Whirlwind制御ストアの方式で信号を生成し、2番目のマトリックスは、次のサイクルでどの信号行（いわばマイクロプログラムの命令語）を呼び出すかを選択しました。条件分岐は、制御ストアの単一の行が2番目のマトリックスの選択肢から選択できるようにすることで実装されました。これにより、制御信号は検出された内部信号に条件付きになりました。ウィルクスは、この機能を説明し、単純な制御ストアと区別するために、マイクロプログラミングという用語を作り出しました。

マイクロコードは、コードを格納するために必要なROMのコストがカスタム制御ロジックのコストとそれほど変わらなかったため、コンピュータ設計では比較的まれなままでした。これは、1960年代初頭に大量生産されたコアメモリとコアロープの導入によって変化しました。これらは、ダイオードアレイや同様のソリューションに基づく専用ロジックよりもはるかに安価でした。これを実際に活用した最初の企業は、 1964年のSystem/360シリーズでIBMでした。これにより、マシンは非常に複雑な命令セットを持つことができ、バイナリ値を10進数文字列としてフォーマットするなど、高水準言語の構造に一致する操作や、このタスクに必要な複雑な一連の内部ステップを低コストのメモリにエンコードすることが可能になりました。^{[ 17 ]}

しかし、360シリーズの真の価値は、内部構造が全く異なる一連のマシンを構築しながら、同じISAを実行できる点にあった。ローエンドのマシンでは、32ビットの加算を1回完了するのに複数サイクルを要する8ビットALUを使用するかもしれないが、ハイエンドのマシンでは、同じ加算を1サイクルで実行できる完全な32ビットALUを搭載するかもしれない。これらの違いは制御ロジックで実現できるが、マシンごとに全く異なるデコーダを実装するコストは法外なものになるだろう。マイクロコードを使用すれば、変更するのはROM内のコードだけとなる。例えば、あるマシンには浮動小数点演算ユニットが搭載されているため、2つの数値を乗算するマイクロコードはわずか数行で済むかもしれないが、同じマシンでFPUを搭載していない場合は、同じ演算を複数回の加算で行うプログラムとなり、変更するのはROMだけとなる。^{[ 17 ]}

この設計の結果、顧客は低価格モデルを使ってソフトウェア開発を行うことができ、より高いパフォーマンスが必要になった場合は、より高速なバージョンに移行すれば、他の部分は何も変更する必要がないという安心感を得ることができた。これにより参入障壁が低くなり、360は爆発的な成功を収めた。1970年代末までには、マイクロコードの使用はメインフレーム業界全体で必須となった。

初期のミニコンピュータはマイクロコードを必要とするほど単純ではなく、命令セットやデコード方法の点では初期のメインフレームに似ていました。しかし、設計者がより複雑なISAを可能にするより強力な集積回路を使用し始めるまで、そう時間はかかりませんでした。1970年代半ばまでに、ほとんどの新しいミニコンピュータとスーパーミニコンピュータもマイクロコードを使用するようになり、PDP-11のほとんどのモデルや、特にVAXのほとんどのモデルには、360に見られるものとよく似た高レベル命令が含まれていました。^{[ 18 ]}

マイクロプロセッサでも同様の基本的な進化が起こりました。初期の設計は非常にシンプルで、1970年代半ばのZilog Z80のようなより強力な8ビット設計でさえ、専用ロジックで実装できるほど単純な命令セットを持っていました。この頃には、制御ロジックをCPUと同じダイにパターン化できるようになり、ROMとロジックのコストの差はそれほど問題ではなくなりました。しかし、これらの企業は、より高性能な設計を導入しつつ、後方互換性も維持したいという問題にもすぐに直面しました。マイクロプロセッサ内のマイクロコードの初期の例としては、Intel 8086がありました。^{[ 5 ]}

マイクロプロセッサにおけるマイクロコードの究極の実装例の一つが、Motorola 68000です。これは、高度に直交した命令セットと、マイクロコードで実装されたさまざまなアドレッシングモードを提供しました。初期の記事によると、これにはコストがかかり、チップの表面積（つまりコスト）の約 20% がマイクロコード システムでした^{[ 19 ]} 。後の推定では、プロセッサの 68,000 個のトランジスタのうち約 23,000 個がマイクロコード システムの一部だったとされています。

企業が命令セットの複雑さで競争を続け、マイクロコードを使用してそれらを実装することに疑問が呈されなかった一方で、1970年代半ば、IBMの社内プロジェクトで、この概念全体に深刻な疑問が投げかけられました。高性能な全デジタル電話交換機を開発するプロジェクトの一環として、ジョン・コック率いるチームは、顧客の360（およびSystem/370）プログラムから膨大な量のパフォーマンスデータを調べ始めました。その結果、奇妙なパターンに気づきました。ISAが命令の複数のバージョンを提示する場合、コンパイラはコードを最も直接的に表す命令ではなく、ほぼ常に最も単純な命令を使用していたのです。その理由は、これらの命令は常にハードウェアで実装されており、したがって最も高速に実行されるためだと分かりました。他の命令を使用すると、一部のマシンではより高いパフォーマンスが得られる可能性がありますが、どのマシンで実行されているかを知る方法はありませんでした。これは、そもそもマイクロコードを使用する目的、つまりこれらの違いを隠すという目的を損なうものでした。^{[ 20 ]}

チームは「コンピュータとユーザーの間にマイクロコードを押し付けると、最も頻繁に実行される命令を実行する際にコストのかかるオーバーヘッドが発生する」という根本的な結論に達した。^{[ 20 ]}

The result of this discovery was what is today known as the RISC concept. The complex microcode engine and its associated ROM is reduced or eliminated completely, and those circuits instead dedicated to things like additional registers or a wider ALU, which increases the performance of every program. When complex sequences of instructions are needed, this is left to the compiler, which is the entire purpose of using a compiler in the first place. The basic concept was soon picked up by university researchers in California, where simulations suggested such designs would trivially outperform even the fastest conventional designs. It was one such project, at the University of California, Berkeley, that introduced the term RISC.

The industry responded to the concept of RISC with both confusion and hostility, including a famous dismissive article by the VAX team at Digital.^[21] A major point of contention was that implementing the instructions outside of the processor meant it would spend much more time reading those instructions from memory, thereby slowing overall performance no matter how fast the CPU itself ran.^[21] Proponents pointed out that simulations clearly showed the number of instructions was not much greater, especially when considering compiled code.^[20]

The debate raged until the first commercial RISC designs emerged in the second half of the 1980s, which easily outperformed the most complex designs from other companies. By the late 1980s it was over; even DEC was abandoning microcode for their DEC Alpha designs, and CISC processors switched to using hardwired circuitry, rather than microcode, to perform many functions. For example, the Intel 80486 uses hardwired circuitry to fetch and decode instructions, using microcode only to execute instructions; register-register move and arithmetic instructions required only one microinstruction, allowing them to be completed in one clock cycle.^[22] The Pentium Pro's fetch and decode hardware fetches instructions and decodes them into series of micro-operations that are passed on to the execution unit, which schedules and executes the micro-operations, possibly doing so out-of-order. Complex instructions are implemented by microcode that consists of predefined sequences of micro-operations.^[23]

一部のプロセッサ設計では、特別なモードで実行されるマシン コードを使用し、そのモードでのみ使用可能な、プロセッサ依存のハードウェアにアクセスできる特別な命令を使用して、命令セットのいくつかの低レベル機能を実装しています。純粋な RISC 設計である DEC Alpha は、PAL コードを使用して、変換ルックアサイド バッファ(TLB) ミス処理や割り込み処理などの機能を実装し、 ^{[ 24 ]}また、OpenVMSを実行する Alpha ベースのシステム向けに、 VAXアーキテクチャが提供する命令に似た、インターロック メモリ アクセスを必要とする命令を提供しました。^{[ 24 ]} CMOS IBM System/390 CPU (G4 プロセッサ以降) およびz/Architecture CPU は、ミリ コードを使用して一部の命令を実装しています。^{[ 25 ]}

「水平マイクロコードには、複数の個別のマイクロ操作が1つのマイクロ命令にまとめられ、同時に実行されます。」^{[ 1 ]}水平マイクロコードは通常、かなり広い制御ストアに格納されます。各ワードが108ビット以上であることも珍しくありません。シーケンサクロックの各ティックで、マイクロコードワードが読み取られ、デコードされ、CPUを構成する機能要素を制御するために使用されます。

一般的な実装では、水平方向のマイクロプログラムワードは、かなり厳密に定義されたビットのグループで構成されます。例えば、単純な構成としては次のようなものがあります。

このタイプのマイクロマシンがオペコードの次のアドレスを持つJUMP命令を実行するには、マイクロコードに2クロックティックが必要になる場合があります。設計者は、次のようなマイクロアセンブラのソースコードを作成します。

# 番号記号で始まる行はすべてコメントです。# これは単なるラベルで、アセンブラがメモリ アドレスをシンボルで表現する通常の方法です。 InstructionJUMP : # 次の命令に備えるため、命令デコード マイクロ コードはすでにプログラム カウンタをメモリ アドレス レジスタに移動しています。 この命令は、 #ジャンプ オペ コードの後のメモリ ワードから、メモリ データ レジスタからメモリ アドレス レジスタにコピーすることで、ジャンプ命令のターゲット アドレスをフェッチします。 # これにより、メモリ システムは、次の命令をメモリ データ レジスタにフェッチして、命令デコードで使用できるようになります。# シーケンサ命令「next」は、制御ワード アドレスに 1 を加えることを意味します。 MDR 、 NONE 、 MAR 、 COPY 、 NEXT 、 NONE # これは、次の命令のアドレスを PC に配置します。# これにより、メモリ システムは、前のマイクロ命令で開始したフェッチを完了するためにクロック ティックを受け取ります。# シーケンサ命令は、命令デコードの開始位置にジャンプします。 MAR 、1 、 PC 、 ADD 、 JMP 、 InstructionDecode # 命令デコードは通常、非常に複雑で、エミュレートされている特定のプロセッサに固有のものであるため、表示されません。この例でさえ簡略化されています。 # 多くのCPUは、オペコードの後のワードからアドレスをフェッチするだけでなく、アドレスを計算する複数の方法を持っています。 # そのため、これらのCPUは、1つのジャンプ命令ではなく、関連するジャンプ命令のファミリーを持っています。

各ティックにおいて、CPUの一部のみが使用され、マイクロ命令内の残りのビット群は何もしない（no-op）状態となるのが一般的です。ハードウェアとマイクロコードを慎重に設計することで、この特性を利用して、CPUの異なる領域を使用する演算を並列化できます。例えば、上記の例では、最初のティックではALUは必要ないため、それ以前の算術演算命令を完了するために使用できる可能性があります。

垂直マイクロコードでは、各マイクロ命令は大幅にエンコードされます。つまり、ビットフィールドは一般的に中間組み合わせ論理回路を通過し、それがCPU内部要素（ALU、レジスタなど）の制御信号とシーケンス信号を生成します。これは、ビットフィールドが制御信号とシーケンス信号を直接生成するか、最小限にエンコードされる水平マイクロコードとは対照的です。したがって、垂直マイクロコードは命令長が短く、記憶容量も少なくて済みますが、デコードに時間がかかるため、CPUクロックが遅くなります。^{[ 45 ]}

一部の垂直マイクロコードは、より複雑なコンピュータをエミュレートする単純な従来型コンピュータのアセンブリ言語にすぎません。DEC Alphaプロセッサや、後の IBM メインフレームSystem/390およびz/Architectureの CMOS マイクロプロセッサなどの一部のプロセッサは、通常のマシン コードでは利用できない特別な命令、特別なレジスタ、およびその他のハードウェア リソースにアクセスできる特別なモードで実行されるマシン コードを使用して、一部の命令やその他の機能を実装します^{[ 46 ] [ 47 ]}、Alpha プロセッサではページ テーブル ウォークなどです^{[ 48 ]} 。これは、Alpha プロセッサではPAL コード、IBM メインフレーム プロセッサではミリコードと 呼ばれます。

垂直マイクロコードの別の形式には、2つのフィールドがあります。

フィールド選択は、制御ストアのこのワードによってCPUのどの部分が制御されるかを選択します。フィールド値は、そのCPU部分を制御します。このタイプのマイクロコードでは、設計者は制御ストア内の未使用ビットを削減することでコストを削減するために、意図的にCPUの速度を遅くすることを選択します。ただし、複雑さが軽減されることでCPUのクロック周波数が上昇し、命令あたりのサイクル数の増加による影響が軽減される可能性があります。

トランジスタの価格が下がるにつれて、マイクロコードを用いたCPUの設計においては水平マイクロコードが主流となり、垂直マイクロコードの使用頻度は減少していった。

垂直マイクロコードと水平マイクロコードの両方が使用される場合、水平マイクロコードはナノコードまたはピココードと呼ばれることがある。^{[ 49 ]}

PDP -8は、 1965年にデジタル・イクイップメント・コーポレーション（DEC）が発売した12ビットミニコンピュータのファミリーです。OPR （OPeRate）命令は「マイクロコード化」されていると言われていました。これは今日でいう「マイクロコード化」とは異なり、命令語の各ビットが特定のアクションを指定し、プログラマは複数のビットを設定することで1回の命令サイクルで複数のアクションを実行できるという意味でした。これらのアクションの例としては、アキュムレータのクリア、アキュムレータの補数化、右回転、2回右回転、バイトスワップなどがあります。

IBMやLenovoなどの一部のハードウェアベンダーは、マイクロコードという用語を組み込みファームウェアと互換的に使用しています。この文脈では、デバイス内のすべてのコードがマイクロコードかマシンコードかを問わず、マイクロコードと呼ばれます。たとえば、ハードディスクドライブのマイクロコードの更新には、マイクロコードとファームウェアの両方の更新が含まれる場合があります。^{[ 67 ]}組み込みファームウェアは、ネットワークプロセッサ、デジタル信号プロセッサ、チャネルコントローラ、ディスクコントローラ、ネットワークインターフェイスコントローラ、フラッシュメモリコントローラ、グラフィックス処理ユニットなどのアプリケーション固有のプロセッサやその他のハードウェアで普及しています。