パイプラインプロセッサでの割り込み

確かに、割り込みとは何かを知っています。 おそらく、彼らはプロセッサデバイスにさえ興味がありました。 ほぼ確実に、プロセッサが割り込みをどのように検出し、プロセッサに行き、そして最も重要なこととして、そこから正確に戻るべきかについてのわかりやすい話を見たことはありません。



この記事を1年間書いた。 当初は、ハードウォーダー向けに設計されていました。 私はそれを決して終わらせないという理解、そして名声への欲求と10人以上の人がそれを読むことへの欲求により、私はそれを比較的広い聴衆に適応させ、図、Verilog上のコードの断片、およびキロメートルの時間図を放り出しました。



データシートで「プロセッサが正確なアボートをサポートする」という言葉の意味について考えたことがある場合は、catを使用してください。

ちょっとした用語：プロセッサ、プロセス、割り込み

広大さを把握しようとしないために、私は考慮しません：

• 市場シェアが非常に小さく、例として一般的なアーキテクチャを使用する方が論理的であるため、エキゾチックなアーキテクチャ（スタック、ストリーム、非同期など）を備えたプロセッサ。 宗教上の理由だけでRISCを選んだ
• マルチコアプロセッサ。各プロセッサコアが他のコアとは独立して割り込みを処理するため
• スーパースカラー、マルチスレッド、およびVLIWプロセッサ。割り込みを整理するという観点から見ると、スカラープロセッサに似ているためです（もちろん、はるかに複雑です）。

したがって、プロセッサとは、シングルコアシングルスレッドスカラーRISCプロセッサのみを意味します。 読者は少なくとも自分のデバイスに精通していると思います。



そのため、 プロセッサは一連のコマンド（プログラム）を実行して特定の問題を解決するデバイスです。 各コマンドに対して、プロセッサは、命令サイクルと呼ばれる一連の操作を実行する必要があり、次の手順で構成されます。

1. メモリからコマンドを取得する
2. コマンドデコード
3. チームの実行
4. レジスタやメモリへの結果の書き込み

コマンドのシーケンシャル実行を備えたプロセッサは、前のサイクルが完了した後でのみコマンドの次のサイクルの実行を開始します。つまり、常に1つのコマンドのみが実行されます。



命令の並列実行を備えたプロセッサは、複数の命令を同時に実行できます。 たとえば、4ステージの命令パイプラインを備えたプロセッサは、最初の命令の結果を記録し、2番目を実行し、3番目をデコードし、メモリから4番目を選択できます。



プロセスは実行中のプログラムです。 プロセスは、命令のシーケンシャルまたはパラレル実行でプロセッサで実行されるかどうかに関係なく、同じ結果をもたらすはずです。 プロセスの状態は、内容によって決定されます。

• プロセッサコマンドカウンター（プログラムカウンター、別名命令ポインター）
• プロセッサレジスタ（汎用、ステータス、フラグなど）
• RAMメモリ

リアルタイムシステムでは、キャッシュメモリ、変換ルックアサイドバッファ（TLB）、および動的遷移予測テーブルの影響も考慮する必要があります。



実行された各コマンドは、何らかの形でプロセスの状態を更新します。

• 算術および論理命令は、レジスタおよび命令カウンタの内容を更新します
• 分岐命令は、命令カウンタと動的分岐予測テーブルの内容を更新します
• ロードコマンドは、レジスタ、コマンドカウンター、キャッシュメモリの内容を更新します（キャッシュがミスした場合、キャッシュラインの交換が必要な場合はRAMもあります）
• 保存コマンドは、RAM（またはキャッシュ）および命令カウンターの内容を更新します

割り込みは、発生時にプロセッサが現在のプロセスの実行を中断し、その状態を保存し、割り込みハンドラと呼ばれる別のプロセスの実行を開始する必要があるイベントです。 割り込みハンドラーの完了後、割り込みを受けたプロセスの状態を復元する必要があり、致命的な割り込み（ハードウェア障害など）が発生した場合、プロセッサを再起動または停止する必要があります。



割り込みのソースに応じて、次のようになります。

1. 内部、プロセッサでのコマンドの実行が原因の場合：
   
   
   • ソフトウェア（ソフトウェア割り込み）、特別なコマンドによって呼び出された場合
   • コマンド実行時のエラーが原因である場合、例外（例外、フォールト、アボート-それだけ）
   
   
   
2. プロセッサ外部のイベントが原因の場合は外部

上記の割り込みのいずれかが現れたときに実行されたコマンドは、簡潔にするために、中断されたコマンドを呼び出します。



プロセスの状態の保存と復元は、ハードウェア、ソフトウェア、またはソフトウェアとハ​​ードウェアで実装できます。 将来的には、最も単純なハードウェアおよびソフトウェアオプションを検討します。

• プロセッサは、命令カウンタを特別なリターンアドレスレジスタ（RAV）に保存し、割り込みベクトルを命令カウンタに書き込んで、割り込みハンドラを開始します。
• 他のすべてのプロセス状態要素は、必要に応じて割り込みハンドラーによって保存されます（たとえば、レジ​​スターを使用する前に、その内容をスタックに保存する必要があります）
• 割り込みハンドラを完了する前に、変更したすべてのプロセス状態要素を復元する必要があります（たとえば、スタックに格納されているレジスタの内容を復元する）
• 割り込みハンドラは、RABの内容を命令カウンタに書き戻す割り込みコマンドからの戻りで終了します。つまり、制御を割り込みプロセスに戻します。

中断されたプロセスに制御を戻した後、彼は中断されていないかのように作業を続行できるはずです。 この要件はささいなものですが、最新のプロセッサのほとんどでは、これを満たすことは非常に困難です。 とても難しいので、時々彼らはそれを拒否します。 この要件が満たされていることを確認する割り込みはpreciseと呼ばれ、その他は不正確と呼ばれます。

正確および不正確な割り込み

正式には、次のすべての条件が満たされている場合、割り込みは正確と呼ばれます。

1. 中断される前のすべてのコマンドが完全に実行され、プロセスの状態が正しく保存された
2. 中断された後のすべてのコマンドは実行されず、プロセスの状態を一切変更しませんでした
3. 割り込みの種類に応じて、割り込み可能なコマンドが完全に実行されたか、まったく実行されなかった

精度の最初の2つの条件にはコメントは不要です。 3番目の条件は、次のことが原因です。

• 外部割り込みが到着したときに実行されたコマンドは、保存される前にプロセスの状態を更新する必要があります。 ソフトウェア割り込みを引き起こしたコマンドについても同じことが言えます。 どちらの場合も、RAVは、中断がなければ次に実行されるべきコマンドを示します。 割り込みハンドラから戻った直後に実行されます
• 例外を引き起こしたチームは悪いチームです。 その結果はおそらく不正確であるため、プロセスの状態を更新すべきではありません。 代わりに、そのアドレスはRAVに保存され、その後、割り込みハンドラーが呼び出され、エラーを修正しようとします。 ハンドラから戻った後、このコマンドが再度実行されます。 同じ例外を再度スローすると、エラーは致命的であり、プロセッサは致命的な割り込みを生成します

明らかに、外部割り込みは常に正確でなければなりません。 タイマーからの割り込みを処理した後、プロセスを正しく復元できないプロセッサが必要なのは誰ですか？



ソフトウェアの割り込みと例外は、正確または不正確な場合があります。 場合によっては、たとえばプロセッサにMMUがある場合など、正確な例外なしでは実行できません（その後、TLBミスが発生すると、制御は対応する例外ハンドラーに転送されます。 ）



マイクロコントローラでは、例外が不正確になる場合があります。 たとえば、メモリエラーが原因でsaveコマンドが例外を引き起こした場合、何らかの方法でエラーを修正してこのコマンドを再実行しようとする代わりに、マイクロコントローラーを再起動してプログラムを再起動するだけです（つまり、ウォッチドッグと同じことを行います）プログラムがフリーズするときのタイマー）。



ほとんどのコンピューターアーキテクチャの教科書（ Patterson＆HennessyやHennessy＆Pattersonなどの古典を含む）は、割り込みをバイパスします。 さらに、不正確な割り込みは重要ではありません。 私の意見では、これらは正確な中断に関する話を続ける優れた理由です。

シーケンシャルプロセッサでの正確な割り込み

命令をシーケンシャルに実行するプロセッサの場合、正確な割り込みの実装は非常に簡単であるため、それから始めるのが論理的に思えます。 各時点で実行されるコマンドは1つのみであるため、割り込みを検出した時点で、割り込みの前のコマンドはすべて実行されており、後続のコマンドも開始されていません。



したがって、このようなプロセッサに正確な割り込みを実装するには、割り込みが発生したコマンドが例外を引き起こしたかどうかが明らかになるまで、プロセスの状態を更新しないようにするだけで十分です。



チームがプロセスの状態を更新できるかどうかをプロセッサが決定する必要がある場所は、 コミットポイントと呼ばれます。 プロセッサがコマンドの結果を保存する場合、つまり、コマンドが例外を発生させなかった場合、彼らはこのコマンドが修正されたと言います（スラングではコミットされます）。



注視点の位置を理解するには、コマンドループの手順を思い出してください。

1. メモリからコマンドを取得する
2. コマンドのデコード
3. チームの実行
4. レジスタやメモリへの結果の書き込み

定義では、結果が記録される前でなければなりませんが、この時点で、コマンドが例外を引き起こしたかどうかはすでにわかっているはずです。 例外は、次の4つの段階のいずれかで発生する可能性があります。

1. コマンド取得中のメモリエラー
2. 不明なデコードオペコード
3. 実行時のゼロ除算
4. 結果の書き込み中のメモリエラー

明らかに、メモリへの結果の書き込みの問題が解決されるまで、正確な割り込みの実装は不可能です。

• コマンドをコミットして、そのコマンドが例外を発生させていないことが明らかになるまで、結果をメモリに書き込むことはできません。
• 結果をメモリに書き込まずに例外が発生していないことはわかりません（このためには、記録が成功したことをメモリコントローラから確認する必要があります）

ご想像のとおり、この問題を解決するのはかなり難しいので、簡単にするために、「ほぼ正確な」割り込みを簡単にするために実装します。つまり、結果を書き込む際のメモリエラーに起因する例外を除き、すべての割り込みを正確にします。 この場合、結果を修正するポイントは、チームサイクルの3番目と4番目の段階の間にあります。

重要！ 結果を修正した時点で、コマンドカウンターも厳密に更新する必要があることに注意してください。 同時に、コマンドが固定されているかどうかに関係なく変化します。次のコマンドのアドレス、割り込みベクトル、またはRAVが書き込まれます。

命令の並列実行によるプロセッサでの正確な割り込み

現在まで、コマンドのシーケンシャル実行を備えたプロセッサーはほとんどありません（Intelの8051の類似品しか思い出せません）。これらは、コマンドの並列実行を備えたプロセッサーに置き換えられました。 命令の並列実行を備えた最も単純なプロセッサは、命令パイプラインを備えたプロセッサです。

その多くの利点にもかかわらず、コマンドパイプラインは正確な割り込みの実装を大幅に複雑化し、開発者を何十年も悲しませてきました。



命令を順次実行するプロセッサでは、命令サイクルのステップは互いに依存します。 最も単純な例は、コマンドカウンターです。 最初に、サンプリング段階で（コマンドを読み取るメモリのアドレスとして）、次に実行段階で（その次の値を計算するために）使用されます。次に、コマンドが修正された場合、結果を記録する段階で更新されます。 これは、前のコマンドが最後のステージを完了してコマンドのカウンターを更新するまで、次のコマンドを選択できないという事実につながります。 プロセッサ内の他のすべての信号にも同じことが当てはまります。



命令パイプラインを備えたプロセッサは、命令サイクルの各ステージが前後のステージから独立している場合、命令を順次実行するプロセッサから取得できます。



このため、最後のステージを除く各ステージの結果は、ステージ間にある補助メモリ要素（レジスタ）に保存されます。

1. 選択の結果-エンコードされたコマンド-は、選択とデコードの段階の間にあるレジスタに保存されます
2. デコード結果-操作の種類、オペランドの値、結果のアドレス-は、デコード段階と実行段階の間にレジスタに保存されます
3. 実行結果-条件付き遷移の命令カウンターの新しい値、ALUで計算された算術演算の結果など-は、実行段階と結果の記録段階の間のレジスタに保存されます。
4. 最終段階では、結果はすでにレジスターやメモリーに書き込まれているため、補助レジスターは不要です。

これが、結果のパイプラインの仕組みです。

タクトSCサンプリングデコード実行Record_result
 1 0x00チーム1---
 2 0x04チーム2チーム1--
 3 0x08チーム3チーム2チーム1-
 4 0x0Cチーム4チーム3チーム2チーム1            
 5 0x10チーム5チーム4チーム3チーム2            

SK列（「コマンドカウンター」）に注意してください。 その値はサイクルごとに変化し、コマンドが選択されるメモリ内のアドレスを決定します。

注意深い読者はすでに小さな問題に気付いています。割り込みの精度を確保するために、最初のコマンドには4番目の測定の前にコマンドカウンターを変更する権利がありません。 これを修正するには、結果を修正するポイントを超えてコマンドカウンターを転送する必要があります（3番目と4番目のステージの間にあると仮定します）。

ビートサンプリングデコード実行Record_result SK
 1チーム1---0x00
 2-チーム1--0x00
 3--チーム1-0x00
 4 Team2--Team1 0x04
 5-チーム2--0x04

CPUのパフォーマンスが少し低下しましたね。 実際、解決策は表面にあります-2つの命令カウンターが必要です！ 1つはパイプラインの先頭にあり、コマンドを読み取る場所を示す必要があります。2つ目は最後にあり、次に修正する必要があるコマンドを指します。

1つ目は「投機的」、2つ目は「建築的」と呼ばれます。 ほとんどの場合、投機的コマンドカウンターはそれ自体ではなく、分岐予測に組み込まれています。 次のようになります。

 SSCタクトサンプリングデコード実行Record_of ACK
 1 0x00チーム1---0x00
 2 0x04 Team2 Team1--0x00
 3 0x08チーム3チーム2チーム1-0x00
 4 0x0Cチーム4チーム3チーム2チーム1 0x04
 5 0x10チーム5チーム4チーム3チーム2 0x08

これが次に起こることです。 ステージ間を移動するチームは、選択元のアドレス（つまり、CCK）をドラッグします。 結果の固定点の前に、プロセッサは外部割り込みが到着したかどうか、コマンドが例外を引き起こしたかどうかを確認し、そのアドレスをACKと比較します。

• 外部割り込みが到着すると、コマンドはコミットされますが、次のコマンドのアドレスはACKではなくRAVに記録されます。 割り込みベクターのアドレスはASKに書き込まれます。
• 例外が発生すると、コマンドはコミットされず、代わりに、対応する例外のベクトルのアドレスがACKに書き込まれ、コマンドアドレスがRAVに書き込まれます。
• チームのアドレスがASKと等しくない場合、それもコミットされません（これについては後で説明します）。 アドレスがACKで例外が発生していない場合、プロセッサはコマンドをコミットしてACKを更新します（分岐コマンドの場合は遷移アドレスを記録し、別のコマンドの場合は単純にインクリメントします）

チームの住所がASKと等しくないのはなぜですか？ 私のお気に入りの例を考えてみましょう：プロセッサの電源を入れたばかりで、割り込みテーブルから最初のコマンドを選択します。これは、遠距離（0x1234）に移動するコマンドにすぎません。

 SSCタクトサンプリングデコード実行Record_of ACK
 1 0x00ジャンプ0x1234---0x00
 2 0x04コマンド2ジャンプ0x1234--0x00
 3 0x08チーム3チーム2ジャンプ0x1234-0x00
 4 0x0Cチーム4チーム3チーム2ジャンプ0x1234 0x1234
 *** 4番目のメジャーのTeam2では、遷移が誤って予測されたため、そのアドレス（0x04）はASKと等しくありません***
 5 0x1234 Team666---0x1234
 6 0x1238 Team667 Team666--0x1234
 7 0x1240 Team668 Team667 Team666-0x1234
 8 0x1244 Team669 Team668 Team667 Team666 0x1238

以上です。 もちろん、示されている4段コンベヤーは単純から不可能です。 実際、一部のコマンドは複数のクロックサイクルで実行できます。また、単純なマイクロコントローラーでさえ、割り込みの精度を確保しながら、コマンドを間違った順序で実行することができます。 ただし、割り込みを編成する一般的な原則は、あえて保証しますが、同じままです。



脳の爆発を悪化させたい人のために、パイプラインプロセッサでの正確な割り込みの実装に慣れることをお勧めします。 はい、最新のIntel Cor Ai Sevenは、25年前にこの記事で説明したとおりに機能します。 80年代へようこそ！