用語として、 "マイクロコード"とは何ですか。また、更新できる場合、ファームウェアとはどう違うのですか。
この質問は この質問の複製ではありません (私が言うことができる限り)マイクロコードの変更についても私が尋ねたところです。ここで私は厳密にこれらの用語を正しく使う方法を知りたいのです。
回答が選択されていますが、特に満足しているわけではありません。私はたくさんの答えをしてきましたが、それらの答えの多くは同様に満足のいくものではありません。私の2つのフレームをあなたに提示しましょう。
Wordの由来ファームウェアは、ハードウェアとソフトウェアの間の中間点 - ハードウェアに組み込まれたソフトウェアです。ハードウェアデバイス上の不揮発性メモリに格納されているソフトウェアを指します。ハードウェアデバイスに組み込まれているEEPROMやフラッシュメモリは、デバイス自体によって実行されるコードを格納するために使用されます。
一部の種類のハードウェアでは、「ファームウェア」をドライバソフトウェアに格納し、起動時または初期化時にデバイスにロードするのではなく、デバイス上に永続的に置くのが一般的になっています。たとえば、ホストOSにロードされたソフトウェアドライバに数百KBのファームウェアコードを格納し、ドライバによって初期化されたときにそれをデバイスに送信することは、今日では大した問題ではありません。
あなたが受け入れるファームウェアの定義にもよりますが、これは「ファームウェア」と呼ばれることが多いですが、ハードウェアに常駐していないので技術的にはファームウェアと見なさないかもしれません。そのバージョンの「ファームウェア」は保持されません。
マイクロコードは、この後者のタイプの「ファームウェア」のサブセットです。マイクロコードは、起動時にデバイスにロードされるすべての「ファームウェア」の総称ではありません。代わりに、マイクロコードが基本的に上位レベルの標準CPU命令とそのCPUに固有の下位レベルの操作との間の変換層を形成する、CPUに固有のものです。これは起動時にBIOSによってCPUにロードされますが、起動段階で後でOSによって置き換えることもできます。
マイクロコードを更新することで、CPUのハードウェアを交換する必要なしに、まだ発見されていないバグを回避するために、CPUの低レベルの動作を修正することができます。マイクロコードは通常、最高の速度とエネルギー効率のために可能な限り高レベルの命令から低レベルの命令への最も効率的なマッピングを含んでいます。
Meltdown(Intelチップのみに影響を与える脆弱性)は、マイクロコードの更新だけでは修正できず、コアOSの機能を変更する必要があるため、パフォーマンスがさらに低下する可能性があります。 Spectre(Intel、AMD、ARMチップに影響を与える脆弱性)は、マイクロコードの更新だけで回避できる可能性があります。
編集後の特定の質問に答えるには
はい、マイクロコードは基本的にプロセッサ上で動作するファームウェアです。特別な用語「マイクロコード」は、標準的な機械語から低レベルのプロセッサ命令に翻訳するための青写真を含むプロセッサ上のファームウェアを具体的に指す。だからそれはファームウェアよりもより具体的な用語です。
上で説明したように、オフの間はCPUに保存されませんが、起動するたびにロードされるので、ある意味では従来のファームウェアのようには機能しません。ただし、現在多くのハードウェアでこれが行われており、まだ「ファームウェア」と呼ばれているため、ファームウェアと呼ぶことで問題ありません。
私はあなたが間違っているとは思わない。ファームウェアは特定の機械語で書かれる必要はなく、その実行は特定の方法で起動される必要もありません。ある低レベルでは、すべてのマシンコードは「データ」、つまりプロセッサによって「読み取られ」、特定の方法で解釈されます。
「マイクロコード」という用語は通常、メインCPUにのみ使用され、グラフィックカードや他のハードウェアには使用されません。ただし、他のデバイスにも同じ方法でコードがロードされている場合があります。
https://wiki.debian.org/マイクロコード
CPUマイクロコード
プロセッサマイクロコードは、プロセッサファームウェアに似ています。カーネルは、BIOSアップデートでアップデートする必要なしに、プロセッサのファームウェアをアップデートすることができます。マイクロコードの更新は揮発性メモリに保存されるため、BIOS/UEFIまたはカーネルは起動ごとにマイクロコードを更新します。
IntelとAMDのプロセッサでは、正常に動作するためにマイクロコードのアップデートが必要になる場合があります。これらのアップデートは、不正な処理からコードやデータの破損、そしてシステムのロックアップまでのあらゆる原因となり得るバグ/エラッタを修正します。
BIOS(またはUEFI)は起動中にCPUマイクロコードを更新しますが、ほとんどの場合、マザーボードベンダーは頻繁なBIOS/UEFI更新を発行しないか、ユーザーがそのような更新をインストールしません。これらの理由から、システムプロセッサは膨大な数のシステムで古いマイクロコードで動作している可能性があります。
例:
https://www.win-raid.com/t3355f47-Intel-AMD-amp-VIA-CPU-Microcode-Repositories.html
まあ、Intelの "マイクロコードの更新"は、実際には "ファームウェア"の更新であり、プロセッサのマイクロコード変換ユニットだけでなく、はるかに多くのものを更新します。
インテルの「マイクロコードアップデート」と呼ばれるこれらの統合プロセッサパッケージアップデートは、他のオンダイマイクロコントローラ(PMUや電源管理コアなど)や、さまざまなオンダイプロセッササブシステム用のいくつかのパラメータテーブルもアップデートします。それらはかなり複雑です。
この情報は、マイクロコードおよびマイクロコードの更新に関するIntelの特許のいくつかで入手できます。
「マイクロコード」という用語は主にそのコードが行うことを意味し(それはさらに低レベルの命令を使用して低レベルの命令を実行する)、「ファームウェア」という用語は主にそれがどのように保存および管理されるかを指すハードウェアよりも簡単にアップデートできます。その意味では、「アプリケーション」と「JARファイル」の区別に似ています - 同じプログラムが両方である可能性がありますが、2つの異なる観点から見ています。
ちなみに、マイクロプロセッサの概念は、コンピュータプロセッサがシリコンに埋め込まれる数十年前の1951年にモーリスウィルクスに遡ります。
「マイクロコード」は元の用語であり、プロセッサの「パブリック」命令セット用のインタプリタを実装するために使用された命令を指していました。
しかし、時間が経つにつれて、実装方式にはさまざまなバリエーションがあるため、そのような違いはより曖昧になりました。最初に水平対垂直マイクロコードがあり、次に「メイン」プロセッサ命令セットに(例えば、入出力命令を実行するために)「マイクロコード」を書くための様々な方式があった。それから、通常のプログラム「実行」操作によって容易にロードされたコードとROMまたは他の保護された比較的不変の記憶装置に保存されたコード(例えばBIOS用)とを区別する必要がありました。したがって、「ファームウェア」という用語は、ストレージ内でより永続的に(そしてユーザーが変更するためにアクセスしにくく)したこれらの命令を指すために考案されました。
しかし、これらの最初の区別がなされて以来、物事は何度も変わっていてねじれていて、もうその用語は与えられたプロセッサとOS環境の中でどんな精度でも定義できるだけです。
[注:この答えは特に最近の編集に対処することを意図したものであり、そうでなければすでに投稿されているいくつかの正しい答えに追加するものではない。
繰り返しになりますが、マイクロコード(少なくとも最初の概算まで)特定の種類のファームウェアです
「マイクロコード」はこの文脈では単に「プロセッサファームウェア」を売りにしています。
まあ、それはマーケティングではありません。マーケティングはそれをXBoost Pro(TM)か何かと呼んでいたでしょう。むしろ、それは工学用語です。あなたがCPUを設計するなら、マイクロコードとCPUの他のファームウェア(そして他のデバイスに典型的な種類のファームウェア)の間の区別はあなたにとって重要です。そうでなければ、おそらくそうではありません。
あなたがマザーボードを設計するか、またはオペレーティングシステムを書くなら、あなたはおそらくより扱いにくくてあまり馴染みのない「CPUファームウェアアップデート」の省略形として「マイクロコードアップデート」を使用します。ほとんどのCPUファームウェアアップデートは主にマイクロコードに影響を与えるので、それは同じことに十分に近いです。あなたはおそらくその違いを知っていますが、それについて気にする必要はありません。
エンドユーザーは違いを知ったり気にする必要はありません。理想的な世界ではWordの「マイクロコード」はまったく聞こえません
最近の投機的実行の脆弱性についての報道で注目を集めたと思いますが、気にする必要がないことがより明白になったという文脈でそれを以前に聞いたこともあるかもしれません。これらの脆弱性は予定より早くリリースされていたため、報道された報道内容がそれ以外の場合よりもキュレーションされていなかった可能性があります。エンドユーザーの観点からは、BIOSアップデート、オペレーティングシステムアップデート、場合によってはアプリケーションアップデートをインストールする必要があります。これらのいずれかに新しいマイクロコードが含まれている場合、どれを知る必要も、気にする必要もありません。
それで、あなたがおそらく知る必要も気にする必要もないことを認識していても、あなたはまだ純粋な好奇心から興味を持っているかもしれません:どのように他のファームウェアからマイクロコードを区別しようか?
まず最初に認識すべきことは、必ずしも1つの厳格で高速な定義があるわけではないということです。それは Bleggs and Rubesの状況 の方が多いということです。それでも、マイクロコードについて言えることがいくつかあります。
マイクロコードは通常、CPU上ではなくCPU内で実行されます。それが高水準の見方です。
マイクロコードのアーキテクチャは通常、通常のファームウェアを含む通常のコードのアーキテクチャとはかなり異なって見えます。並列性が高く、ハードウェアにより近いところで実装される可能性があります。既存の回答のいくつか(あなた自身の回答を含む)でこれについて説明していますが、詳細はCPUの設計によって異なる場合があることに注意してください。
ハードウェアは製造元から提供されたファームウェアのみを実行するように設計されていることが多いですが、サードパーティ製のファームウェアを使用する場合は 特に珍しくはありません です。サードパーティ製のマイクロコードははるかにまれですが、昔は(CPUのサイズがブレッドボックスのサイズになったときについて話しています)エンドユーザーの中には、自分のCPUのマイクロコードを変更する人もいると思います。私の知る限りでは、これはPCで使用されている種類のCPUでは不可能です。
マイクロコードは一般に、パブリック命令セットアーキテクチャを翻訳するかまたはそれを実行するのを助ける、すなわち、それはオペレーティングシステム設計者およびアプリケーションプログラマが使用する機械コードを実行する。次のセクションで詳しく説明します。
「実行対データ」多くの答えがこのパラダイムを使う
混乱を招くように異なる方法で、私は恐れます、しかし私は私自身のコメントに対処します。このセクションは、上の最後の箇条書きの点を拡張するのにも役立ちます。ここでの目標は、CPUが実行している作業(ハードウェアとマイクロコードの組み合わせによって達成される)と、一般的なデバイスが実行している作業(ハードウェアとファームウェアの組み合わせによって達成される)を区別することです。私はSATAハードディスクドライブを選ぶつもりです。
SATAドライブは、「セクタ5,123からデータを読み取る」および「セクタ1,321にこのデータを書き込む」という行に沿っているコンピュータからの命令に従う。ドライブのファームウェアはハードウェアにこれを実現させる責任があります、そしてそれは典型的にはある種の組み込みCPU上で走るかなり普通のコードです。ドライブの指示は順番に到着しますが、到着した順序で処理されない場合があります。これらの命令はプログラムではなく、メインCPU上で実行されているプログラムによって送信されます。特に、制御の流れ、すなわちSATAドライブにどの命令を次に実行するかを指示する命令はない。
CPUはコンピュータを担当します。初期化が完了すると、マザーボード(BIOS、別の種類のファームウェア)が提供する命令( "マシンコード")を実行し、オペレーティングシステムが提供するマシンコードを実行するよう指示します。アプリケーションベンダーによる。 CPU自体がEEPROM(BIOSの場合)またはRAM(オペレーティングシステムおよびアプリケーションの場合)からマシンコードを取得します。特に、マシンコードには制御の流れがあります。マシンコードは、次に実行するマシンコードをCPUに指示します。同じマシンコードを繰り返しループすることができます。コードが機能しているデータに応じて異なるコードを実行することができます。SATAコードのようなデバイスインタフェース言語の命令では、限られた一連の簡単な作業しかできません。何でもする。 ( チューリングの完成度 もご覧ください。)
マイクロコードは通常Turing Complete言語を実装しています。通常のファームウェアは通常そうではありません。
「ハードウェア命令は解釈される」とマイクロコードで言うことは何を意味しますか。
確かに混乱します。重要な点は、制御の流れがありTuring Completeであるマシンコードと、そうでないかどうかにかかわらず、SATAなどのデバイスインタフェースによって定義される命令との違いです。
「マイクロコード」はサウンドカードで動作するコードに適用されますか
いいえ、サウンドカードはSATAドライブのようにコードではなく命令を受け取ります。その指示は、「シャープな演奏」や「このデータを波形として解釈して演奏する」のようなものです。それでもとてもシンプルです。
とビデオカード(GPU)?
昔ながらのビデオカード(GPUなしのもの)はSATAドライブと同じです。指示は、「このピクセルをこの色に設定する」または「Aをこの位置に書き込む」のようなものです。
... GPUは複雑で、私が上で説明した2つの世界の間のどこかに座っています。メインコンピュータの中にある専用のコンピュータ、つまり独自のCPUを持つコンピュータと考えるのがおそらく最も簡単です。 SATAドライブのようなデバイスにも組み込みCPUがあるのは事実ですが、違いは、SATAドライブの組み込みCPUはドライブの製造元から提供されたコードのみを実行し、GPUもオペレーティングシステムやアプリケーションベンダーから提供されるコードを実行するということです。本当にこれは全く別の質問です。
TL; DR:マイクロコードは特定の種類のファームウェアであり、ハードウェアがチューリング完了命令セットを実装するのに役立ちます。
ファームウェアは通常、CPU自体ではなくCPUを含むデバイスのコードを指します。 Android携帯用のファームウェア。
マイクロコードは、複雑な命令セット(例えば486、686、AMD − 64等)とチップ製造者がシリコンを設計するための低レベル命令との間の変換層である。そのため、CPU命令セット内の多数の命令はシリコンでは実装されていませんが、マイクロコードを介してシリコンで実装されている複数の命令に変換されます。
マイクロコード("control store")は、揮発性または不揮発性のメモリにあるデータです。一般に、データ出力信号はcontrol signalパラレルハードウェア機能ユニット、ランダム制御ロジックなどの入力。マイクロコードメモリのアドレス入力は、メモリワード(「マイクロプログラム」命令」)、一度に、1つまたは複数のハードウェアブロックの制御信号を効果的にシーケンスするこれにより、ハードウェアが時分割多重化され、非常に少ないランダムロジックで複雑な操作を実装できます。
現代のマイクロプロセッサでは、共通の「マシンコード」インターフェースを備えたより一般的なアーキテクチャファミリに物理シリコンマイクロアーキテクチャを抽象化するために必要なマイクロコード/シーケンスユニットの階層が存在する場合があります。例えば、命令デコーダーと浮動小数点ユニットを実装するために、マイクロコード/シーケンスのいくつかの層があるかもしれません。
従来の意味でのファームウェアは、不揮発性メモリに常駐するソフトウェア/データであり、まれにしか変更されないか、まったく変更されないことが予想されます。絶えず変化しています。 マイクロコードは、ハードウェアのシーケンス制御を行うマイクロプログラムを表すデータを特に指します。
マイクロコードはファームウェアに実装される場合があります/ファームウェアはマイクロコードを含む場合がありますが、同じではありません。
私は基本的にISAデザインのコースを受講しました。主にMIPSの概念をモデルにしたRISCプロセッサの研究とデザインです。これが私が覚えていることです
私の理解するように、レジスタ、ALU、マルチプレクサ、メモリモジュールなどのプロセッサの基本ブロックは、それらが機能するために特定の信号を必要とします。これらのシグナルを「アサーション」シグナルと呼ぶのは、これらのシグナルをこれらのブロックの操作に必要なシグナルだからです。 CPUは本質的に、ALU、メモリモジュール、レジスタ、その他のハードウェアのスパゲッティブロックです。つまり、各CPUは自分の仕事をするために特定のシーケンスの制御信号をアサートしなければなりません(ANDI、ORI、JMP、BNE、BEQなどの基本命令を意味します)。当時のカリキュラムのペースは私には何も教えていなかったので、命令セットのテストやデバッグ中に自分自身でシグナルをアサートしなければならなかったとき(文字通りすべてのMIPS命令を通り抜ける)、私はそれについて複雑な感情を抱いていました。
一方、アセンブラ言語は命令Wordのオペコードとそのオペランド(基本的にはデータバスの幅)にまとめられています。 MIPSに関しては、命令Wordの最初の6ビットがオペコードです。 単なる数学的検査だけでは、ALU、レジスタ、メモリ、マルチプレクサなど、基本的に残りのハードウェアを6ビットだけで「アサート」することはできません。
あなたが持っていない限りではありません...命令デコーダ。命令デコーダは基本的にあなたのオペコードを受け取り、あなたのハードウェアを操作するのに必要なすべてのあなたの「アサーション」信号を生成します。しかし、命令デコーダはアーキテクチャ間で実装が異なり、場合によってはプログラム可能です。マイクロコードは命令デコーダのプログラム可能部分に影響を与えます。
私はファームウェアがハードウェアに埋め込まれた情報の総称であると信じるようになりました。場合によっては、そのビットストリームをエンコードしてEEPROMやフラッシュメモリなどのハードウェアに格納できるため、マイクロコードとも呼ばれます。しかし、ほとんどの場合、それはコンパイルされたコード、asm、あるいはFPGAで使用されるVHDL/Verilogビットストリームです。私にとってのマイクロコードは、選択したプロセッサで「アサーションシグナル」を指定するために使用されるセマンティクスのように思えます。
ファームウェアは、ROMまたはその他の不揮発性メモリに格納されている実行可能コードです。
ファームウェアの本来の主な目的は、CPUが起動したときにそこにあることです。そのため、CPUが属するシステムであれば起動または起動するために実行するコードがあります。 PCの場合、ファームウェアは実行中のオペレーティングシステムにサービスを提供するためにも使用され、ファン、電源、その他のものを制御する組み込みコントローラ用のコード、およびバックグラウンドで実行されるME/PSP用のコードも保持します。 。
ハードドライブ、USBデバイスなどのファームウェアを使用する周辺機器には、組み込みCPUがあります。
マイクロコードは実行可能コードではなく、デバイスの内部機能で使用されるコードです。
それはWRMSR命令でIntelまたはAMD CPUにロードされます。ファームウェアをデバイスにロードするには、ROMまたはフラッシュメディアをプログラムするか、ファームウェアを受け入れるためにデバイスに存在する小さいローダープログラムに依存します。
ファームウェアとマイクロコードのアップデートも同様のカテゴリにあります。ハードウェアを動作させるために必要なことと、時々アップデートする必要があることです。
多くのCPUの複雑な命令はハードウェアに直接配線されているのではなく、メインCPU内の小さなCPUのような機能によって「実行」されます。マイクロコードはこれらの操作を制御します。これは、少なくとも "MicroROM"を含むマイクロコードを持っていたMotorola 68000にまでさかのぼります。
詳細を明らかにしていないため、IntelまたはAMDのプロセッサ以外は誰もマイクロコードが実際に制御していることを知っています。それをハックする試みがあります。 参照 。
実際には、マイクロコードの更新は本質的に、既知のモデル/ CPUのステッピングで問題を引き起こす命令を無効にするために使用されます。Intelの最新のCPUは、信頼できる機能の前に少なくとも1つのマイクロコードの更新を必要とします。
あなたが 6502 PLAデコードROM について読むならば、CPUマイクロコードが実際に何をすることができるか/実際に何ができるかについてのある見方が得られるかもしれません。ビットCPUとその命令は、内部PLAによって順序付け/制御されていました。 PLAは基本的に、チップのどの部分が各命令の各ステップに含まれていたかを示します(6502命令は2から7サイクルの範囲です)。これは、キャッシング、スーパースカラアーキテクチャ、分岐予測などのはるか前の話です。最近のCPUのマイクロコードがそのPLAのようなものを制御するかどうかはよくわかりません。
この this pdf でuse-contextのみを使用してこれに答えます。
ファームウェア-マイクロコード is は、CPUのファームウェアによって提供されるパスを介して更新されます。
「通常、マイクロコードパッチはマザーボードファームウェアによってCPUにアップロードされる(例:BIOSまたはUEFI)または初期ブートプロセス中のオペレーティングシステムです。」
Microcode-それ自体が「Instruction Decode Unit(IDU)」で使用されるデータです。 IDUは、 hardwired または microcoded のいずれかです。このコンテキストでマイクロコード化されているとは、単にプログラムされていることを意味します。 または、 "複数のマイクロコード。" IDUを意味します。
IDUは制御ユニット内で中心的な役割を果たし、命令レジスタの内容に基づいて制御信号を生成します。
マクロ命令 IDUに送信されてデコードされる1つの命令は、任意の量のマイクロ命令を返す場合があります。
マイクロ命令 1つの事前計算された「制御ワード」、1クロックサイクルで実行するすべての状態と命令。 制御信号を生成するためにCPUに送信されます。
したがって、このコンテキストでは、ファームウェアでマイクロコードを更新します。マクロ命令をマイクロコード化されたIDUに送信して、CPUで実行するためのマクロ命令を「マイクロ命令」に解決し、制御信号に変換します。
マイクロコードは data ですが、マイクロコードの更新は through firmwareで行われます。紛らわしいことに、本質的に内部ルックアップテーブルに相当するものについて話しているので、それは確かに firmware でもあり、本質的にチップに保存され、チップの実行フローで使用されます。一般的なMIDI、ハードウェアPostScript、ダム端末用の制御信号もハードウェアで同じ意味で解釈され、 something が命令を取得し、最終的には何らかの解釈プロセスで "制御信号" を生成します。
CPU内のこれらのプロセスとコンポーネントには特別な名前が付いているようです。CPUの「IDU」、およびIDUが使用するすべての「マイクロ命令」を保持する特定の入力テーブルの名前:「マイクロコード」。そのプロセスに関する情報は独自のものであり、閉鎖されています。モデム(ヘイズモデムのATDTなど)からMIDIカードまでの他の技術に似ていると思いますが、特定のルックアップテーブルに「マイクロコード」という名前を付けず、代わりにフラッシュプロセスとチップ全体に保存されたペイロード全体を指す「ファームウェア」の総称。