マイクロプログラミングレベルと機械語レベルの間で少し混乱しています。例えば:
- 実行中、両方のタイプのプログラムはどこにありますか?
- アセンブリ言語のtrue-op命令への1:1マッピングはありますか?
- どちらの形式もプロセッサアーキテクチャによって定義されていますか?
マイクロプログラミングレベルと機械語レベルの間で少し混乱しています。例えば:
回答:
マイクロコードは、マシンコードを超える別のレベルの抽象化です。実際のCPUはマイクロコードを実行しており、変換エンジンはマシンコードをオンザフライでマイクロコードに変換します。これは、高速で小型のプロセッサ、デバッグの少ない複雑なプロセッサの作成が容易、下位互換性など、さまざまな理由で行われます。たとえば、x86命令セットには、ほとんど使用されない文字列処理命令が含まれています。ただし、下位互換性を維持するには、最新のx86プロセッサーで引き続き使用できる必要があります。これらの命令の実行パスをハードワイヤするのではなく、それらはマイクロコードに変換されて実行されます。これにより、下位互換性を維持しながらシリコンを節約できます。
実行中、両方のタイプのプログラムはどこにありますか?
マシンコードはキャッシュに常駐します(RAMからプルされた後)。マイクロコードは、特定のマシンアーキテクチャに応じて、マイクロコードキャッシュに常駐します。キャッシュは、可能な限り最大のマシンコード命令からの変換済みマイクロコードを保持するのに十分なマイクロコードを保持するのに十分な大きさであるか、またはすべてを再変換する必要がないように多くのマシンコードの変換結果を格納するより大きなキャッシュである可能性があります小さなループの各反復のマシンコード。
一部のアーキテクチャでは、変換されたマイクロコードはどこにも保存されません。フェッチ/変換ユニットは、現在実行中のマシンコードに基づいて一連のマイクロコード命令を単に出力します。この場合、マイクロコードは何らかのROMから実行されており、マシンコードは本質的にROMへのインデックスです-マシンコード命令を完全に実行するために実行する必要がある一連のマイクロコード命令を指します。
アセンブリ言語のtrue-op命令への1:1マッピングはありますか?
マシンコードとアセンブリコードは、通常、1:1でアセンブリ命令にマッピングされます。アセンブラーに依存します。高レベルのアセンブラには、1行のアセンブリコードを記述できるマクロの大きなセットがあり、アセンブラは複数のマシンコードを生成します。
しかし、一般に、「純粋な」アセンブリ言語は、プロセッサのマニュアルの命令セットテーブルを使用して直接マシンコードに変換できます。
「true-op命令」の意味がわかりません。おそらくあなたはリファレンスを説明することができます。
どちらの形式もプロセッサアーキテクチャによって定義されていますか?
マシンコードとマイクロコードの両方のフォーマットは、プロセッサアーキテクチャによって定義されます。
基本的に、マイクロコードは、限られたCPU命令セットを拡張して、ハードウェアに実装するのは面倒ですが、既存の命令を使用して比較的簡単に構築できるより高いレベルの命令を含みます。マイクロコードを使用すると、命令セットが小さいプロセッサを、命令セットが大きいプロセッサと同様に機能させることができます。
MARIE命令セットを使用していて、x、y関数を追加したいとしますが、アーキテクチャーはxの追加のみを許可するので、マイクロコード命令を追加します。
LOAD x //Load x into the register
ADD y //Add y to the value in the register
今あなたの機械語コードが言うとき:
ADD x,y
ROM(マイクロコード)に追加したADD関数を検索して実行します。これは命令セットを増やし、より読みやすいマシンコードを可能にし、マイクロコードがROMに格納されているため、RAMからLOADおよびADDを呼び出すよりも少し高速であるため、これは素晴らしいことです。
古いシステムで非常に高速にカスタム測定を実行するために実際にマイクロコードを作成した会社で働いていました。ただし、FPGAの進歩に伴い、FPGAはより高速なものに切り替わりました(実際には「カスタム命令」をROMではなくハードウェアに実装しているため)。
多くのプロセッサは、遷移シーケンスが実行される命令の影響を受けるステートマシンによって駆動されます。マイクロコードの「命令」は、多くの場合、プログラマーには見えない方法で、さまざまなレジスターおよびバス間の相互作用を指定します。
たとえば、状態#1の8ビットCPUのマイクロコード命令は、プログラムカウンターの両方の半分の出力イネーブルをアクティブにする必要があることを指定する場合があります(プログラムカウンターが上位および下位の内部アドレスバスに出力されるようにする)。プログラムカウンターのインクリメント信号がアクティブになり、外部アドレスラッチ信号がアクティブになり(外部アドレスバスが内部アドレスを追跡するため)、RAM読み取り信号がアクティブになり、コントローラーが状態#2に切り替わります。
状態#2では、外部データバスが内部プライマリデータバスに供給され、そのバスから読み取る命令レジスタが読み込まれます。プログラムカウンターは、以前と同様に、アドレスバスの両方の半分に出力され、別のRAM読み取りが発行されます。命令レジスタのビット5〜7は、状態コントローラのビット0〜2にロードし、状態レジスタのビット3は、命令レジスタのビット1〜7がすべて設定されている場合を除き、設定する必要があります。明確である必要があり、最終的な結果は次の状態が#7〜#15になるということです。
マイクロコードは実際には命令の観点から定義されているのではなく、制御信号の組み合わせの観点から定義されていることに注意してください。ハードウェアは、マイクロコードの汎用命令を許可するようにセットアップされませんが、さまざまなレジスタをそれらが置かれているバスとの間でロードまたは出力したり、異なるバスを相互に接続したり、さまざまなビットまたはその組み合わせを使用して異なる状態を選択します。設計の多くの側面がハードワイヤードされます(たとえば、オペコードFEおよびFFは、マイクロコードではなくハードウェアで特殊なケースになる場合があります)。マイクロコードのアイデアは、プログラムを実行することではなく、ロジックを置き換えることです。