スコアボーディング

2025年10月23日

スコアボーディング

英語表記: Scoreboarding

概要

スコアボーディングは、初期の高性能スーパースカラプロセッサにおいて、命令レベルの並列性を最大限に引き出し、アウト・オブ・オーダー実行（OoO実行）を実現するために開発されたハードウェア制御機構です。これは、命令がパイプラインを流れる際に発生するデータ依存性（ハザード）を厳密に管理し、必要なオペランドが揃い、かつ実行ユニットが空いている場合にのみ、命令の実行を許可する「交通整理役」として機能します。この仕組みのおかげで、CPUは命令発行時のプログラム順序に縛られず、効率的に機能ユニットを稼働させることが可能になるのです。

詳細解説

OoO実行におけるスコアボーディングの役割

スコアボーディングは、私たちが現在学んでいる「CPUの仕組み（命令セット, パイプライン） → スーパースカラと OoO → OoO 実行」という文脈の中で、歴史的に非常に重要な位置を占めています。パイプライン処理において、命令Aの結果を命令Bが利用する場合、命令Bは命令Aが結果を書き込むまで待たなければなりません。この待ち時間（ストール）を減らすために、CPUは実行可能な他の命令を先に処理しようとします。これがOoO実行です。

スコアボーディングの主な目的は、この「順序を入れ替えても安全である」ことを保証することにあります。具体的には、命令の実行に必要なリソース（機能ユニット）とデータ（レジスタの値）の状況を集中管理する「スコアボード」と呼ばれるテーブルを保持し、命令が実行フェーズに進むたびに、以下の3種類のデータハザードが発生しないかを確認します。

RAW (Read After Write: 真の依存性): ある命令がレジスタに書き込む前に、次の命令がそのレジスタを読み込もうとするケースです。これは最も一般的な依存性で、スコアボーディングはこれを厳しくチェックします。
WAR (Write After Read: アンチ依存性): ある命令がレジスタを読み込む前に、次の命令がそのレジスタに書き込もうとするケースです。
WAW (Write After Write: 出力依存性): 複数の命令が同じレジスタに書き込もうとするケースです。

構成要素と動作プロセス

スコアボーディングは、主に以下の3つのステータステーブル（スコアボード）によって構成されています。これらが連携して、どの命令がどこまで進んでいるか、どのリソースが使用中かを監視しています。

1. 命令ステータス (Instruction Status)

現在処理中の各命令が、パイプラインのどの段階にあるか（発行、オペランド読み出し、実行、結果書き込み）を追跡します。

2. 機能ユニットステータス (Functional Unit Status)

加算器、乗算器、ロード/ストアユニットといった各機能ユニットが使用可能かどうか、どの命令が使用しているか、そしてその実行が完了したかどうかを記録します。

3. レジスタ結果ステータス (Register Result Status)

これがスコアボーディングの心臓部と言えます。各レジスタに対して、「次にどの機能ユニットがこのレジスタに結果を書き込む予定か」を記録します。これにより、命令がオペランドを読み出す際に、そのオペランドがまだ計算中の結果であるかどうか（RAWハザードの有無）を瞬時に判断できます。

動作の4つの段階とハザードチェック

命令は、以下の4つの段階を経て実行されますが、スコアボーディングは各段階の開始時に厳密なチェックを行います。

発行 (Issue):
- チェック1 (構造ハザード): 命令が必要とする機能ユニットが空いているか？
- チェック2 (WAWハザード): 既に他の実行中の命令が同じレジスタに結果を書き込む予定になっていないか？
- → ここでどちらか一つでも問題があれば、命令は発行を停止し、待機します。
オペランド読み出し (Read Operands):
- チェック (RAWハザード): 命令が必要とするソースオペランド（レジスタの値）が、まだ他の実行中の命令によって計算中ではないか？
- → ここで問題があれば、命令はストールします。
実行 (Execution):
- オペランドが揃っていれば、機能ユニットで計算を実行します。この段階では他の命令に干渉しないため、チェックは不要です。
結果書き込み (Write Result):
- チェック (WARハザード): この結果をレジスタに書き込むことで、まだそのレジスタの古い値を必要としている後続の命令がないか？
- → もし後続の命令が古い値を読み込むのを待っている場合、書き込みを一時的に停止します。

スコアボーディングは、これらの厳格なチェックを通じて、命令の並列実行を可能にしましたが、特にWAR/WAWハザードの処理が複雑で、しばしばパイプラインを不必要に停止させてしまうという欠点がありました。この欠点を克服するために、後にレジスタ・リネーミング（レジスタ名の付け替え）を活用したより高度な方式（トマシュロのアルゴリズムなど）が開発されることになります。

具体例・活用シーン

スコアボーディングの役割を理解するために、レストランの厨房を想像してみましょう。この厨房がCPUであり、複数の料理人（機能ユニット）が同時に料理（命令）を作っています。

厨房のスコアボード比喩

あなたは、この厨房を統括する料理長（スコアボーディング機構）だとします。あなたは大きなホワイトボード（スコアボード）を持ち、すべての料理の状況を管理しています。

1. 依存性の発生

例えば、料理A（命令A）が「鶏肉を茹でる」作業を担当し、料理B（命令B）が「その茹でた鶏肉を使ってサラダを盛り付ける」作業を担当しているとします。

RAWハザード（真の依存性）のチェック: 料理長は、料理Bが鶏肉を求めるとき、ホワイトボードを見て「待て、料理Aはまだ茹で終わっていない（結果を書き込んでいない）」と判断します。これがなければ、料理Bは生肉を使ってしまい、事故が起こります。スコアボーディングは、この最も重要な依存性を防ぎます。

2. リソース管理

同時に、料理長は「揚げ物担当のフライヤー（機能ユニット）は今空いているか？」もチェックします。料理Cがフライドポテトを注文したとき、フライヤーが空いていなければ、料理長は「順番待ちだ」と指示します（構造ハザードのチェック）。

3. WARハザードによるストール

スコアボーディングの古典的な問題は、WARハザードの処理です。

料理Dが「塩入れ」を完了し、塩入れレジスタに結果を書き込もうとしています。しかし、まだ料理Eが「塩を入れる前の状態のスープを味見する」という作業（読み出し）を終えていなかったとします。

料理長は「待て！料理Eがまだ味見を終えていないのに、Dが塩を加えてしまうと、Eは間違った味見をしてしまう！」と判断し、Dの塩入れ完了（結果書き込み）をストップさせます。

このように、スコアボーディングは中央集権的にすべてのリソースとデータの流れを監視することで、OoO実行という「非同期でカオスな並列処理」を安全に制御する司令塔の役割を果たしているのです。もしこの管理機構がなければ、CPU内部ではデータが衝突し、計算結果が保証されなくなってしまいます。

資格試験向けチェックポイント

スコアボーディングは、IT Passport試験では直接的な専門用語として出題されることは稀ですが、上位の基本情報技術者試験（FE）や応用情報技術者試験（AP）では、「パイプライン制御」や「スーパースカラ処理」の文脈で、トマシュロのアルゴリズムとの対比として重要になります。

スコアボーディングの目的: データハザード（RAW, WAR, WAW）を検出し、機能ユニットの利用効率を高めること。
動作上の弱点: WAWハザードやWARハザードの解決能力が低く、レジスタ・リネーミング機能がないため、不必要なストールを引き起こしやすい点。
対比: スコアボーディングは「集中型」の制御機構ですが、より高性能なトマシュロのアルゴリズムは「分散型」（リザベーション・ステーション）の制御機構を採用しているという違いを把握しておいてください。
チェックポイントとハザード: 命令発行時にWAWをチェックし、結果書き込み時にWARをチェックするという、各ステージでの依存性チェックのタイミングを覚えておくと得点源になります。