大規模データパス・アーキテクチャの提案
辻
坂 井

秀 典y
修 一y

安 島 雄 一 郎y
田 中 英 彦y

我々は新しいマイクロプロセッサ・アーキテクチャとして、大規模データパス・アーキテクチャを提案する。これは、将来利用できる大規模なハード ウェア資源を有効に活用し、積極的に細粒度並列性を抽出することで 、実効 IPC 8 の達成をめざすものである。本アーキテクチャでは、大規模な命令処理と複数パス実行を導入する。本論文では、その大規模な複数パス実行の実現について述べ、性能に関する初期的な検討を行う。

Very Large Data Path Architecture
Hidenori Tsuji,y Yuichiro Ajima,y Shuichi Sakaiyand Hidehiko Tanakay

We propose the Very Large Data Path (VLDP) architecture, a new microprocessor architecture which is expected to e ectively utilize the massive hardware resources available in the
future. VLDP performs the enormous instruction processing and multiple-path execution toachieve e ective IPC of 8 by exploiting ne-grain parallelism aggressively. This paper describes
the implementation for large scale multi-path execution mechanism and brie y evaluates its
performance.

1.

一スレッド における並列性の利用であるのに対し、それらのアーキテクチャは複数のスレッド からより多くの並列性を利用する。
今後も半導体技術の進歩が期待できるならば、ハード ウェア資源の投入とともに性能向上が望めるアーキ
テクチャが必要である。スーパースカラは、より多くのハード ウェア資源を投入したとしても、命令ウィン
ド ウの実装の複雑さなどの点で大規模化による性能向上は難しい。multithreading も、構造の複雑さという点では、スーパースカラを改善するものではないため同様である。その観点では、CMP は提供されるハード ウェア資源を有効に活用する手段である。しかしながら、さらに多くのハードウェア資源を活用するために、より多くのプロセッサを並列化した場合には、複数のプロセッサ間における制御依存とデータ依存の管理が複雑化し、単純にプロセッサ数を増やすことによる性能向上は難しい。
スーパースカラによる並列性利用が細粒度とすれば、単一スレッド に対する細粒度並列実行の要素プロセッ
サとそのプロセッサの並列化による中粒度から粗粒度の並列性利用を組合せる技術が CMP の技術である。
そのため、CMP は単純にスーパースカラを並列化する技術ではなく、利用可能なハード ウェア資源を考慮した、要素プロセッサの規模とそのプロセッサの並列化のバランスが重要である。つまり、細粒度並列利用と CMP による中粒度以上の並列性利用は直交する技

はじめに

マイクロプロセッサの性能向上は留まるところを知らない。その性能向上は、アーキテクチャと半導体プロセス技術に支えられている。常に進歩をとげる半導体プロセス技術によって、より高い集積度が実現され、より多くの利用可能なトランジスタ数が提供されてきた。それが、さまざまな新しい技術の実装を可能とするだけでなく、1GHz を越える高いクロック周波数を実現した。現在主流のスーパースカラで・アーキテク
チャでは、さまざまな技術により命令レベル並列性を利用した命令処理が行われている。
しかしながら、スーパースカラをベースとしたアー
キテクチャでは、分岐予測性能の限界と分岐予測ミス
ペナルティの増大、より多くの並列性利用を目的とした命令ウィンド ウの拡大の限界など、動的な並列性利用技術による性能向上の限界が指摘されている6) 7) 。
そこで、より多くの細粒度並列性を利用するさまざま
なアーキテクチャの研究が行われている。その研究の例としては、hydra3) 、multiscalar8) 、MUSCAT11) 、SKY12) などの CMP(Chip Multi-Processor) と、si-

multaneous multithreading (SMT)9) , M-Machine2)などの multithreading がある。スーパースカラが単
y 東京大学 大学院工学系研究科
GraduateschoolofEngineering,

The

University

of

Tokyo

1

2.2 IB の構成情報
IB は命令情報とデータ同期情報を持つ。命令情報
は 32 命令それぞれの命令コード と入力オペランド により構成され、ひとつのスロットに相当する情報を図2に示す。なお、出力オペランド は用意されず後述のOutput Register Map を用いる。
ここで注目すべきは、入力に関する情報である。従来の命令の入力は論理レジスタ番号もしくは即値であったが、IB ではこれに加え出力番号が追加される。
これは IB 内の 32 の命令に順に与えられた番号であり、IB 内の n 番目の命令の結果を意味する。これを利用すれば、IB ローカルな命令間でのデータの受け渡しには、論理レジスタを介する必要がなくなる。

術であると考えられ、スーパースカラを越える細粒度
並列性を利用するアーキテクチャの研究は必須であるといえる。
そこで我々は、5 年以上先に利用可能なハード ウェ
ア資源を背景に、単一スレッド から積極的に細粒度並列性を利用して実効 IPC 8 を達成する、大規模デー
タパス (VLDP: Very Large Data Path)・アーキテク
チャを提案する。このアーキテクチャは、スーパース
カラや VLIW よりもはるかに大きな幅で命令を並列処理するとともに、並列性抽出の鍵となる大幅な命令
ウィンド ウの拡大を実現する。また、分岐予測ミスペ
ナルティの増大を避けるため、複数パス実行を導入する。そして、VLDP アーキテクチャを実行機構を含む
複数パス実行を実現するアーキテクチャとして提案する。本論文では 、VLDP アーキテクチャにおける複数パス実行の実現と大きな幅の命令発行の実現を中心に、アーキテクチャの提案と初期評価を行う。
2.

Operation

Input 1

Input:

OperandSelectInput 2

Select=0x: Operand = Immediate
Select=10: Operand = Logical Register Number (0 ...63)
Select=11: Operand = Output Number (0 ...31)

命令ブロックの導入

VLDP が目標とする実効 ILP 8 を達成するためには、毎サイクルに 2 桁命令のフェッチスループットが必要となる。そこで、複数の命令を同時に処理するた
めに 、命令ブロック (IB: Instruction Block) を導入する。IB によって処理単位を大幅に拡張することで、高いスループットを確保するとともに、命令管理の単位が大きくなることで処理の複雑化も避けられる。さらに、整数演算系の命令列には分岐命令が 2 割以上存在することから、IB は複数の分岐命令を含む必要があり、複数パス実行における分岐命令の扱いも考慮する。本節ではそのような IB の構成について述べる。
2.1 IB の構成
IB は複数の命令によって構成され、フェッチポイン
トとなるひとつの PC を与えられる。命令幅は 32 命
令の固定長として、その中に存在できる分岐命令数は4 つとする。図 1に示すように 32 命令のスロットを持
ち 、これが 8 命令単位の 4 つの eld に区切られ、制御フロー順に命令が配置される。ただし、それぞれのeld の最後のスロットにだけ分岐命令が配置できるものとする。分岐の区切りにより命令が埋められない
スロットは、空きスロットとして NOP 命令を挿入する。なお、分岐命令が 8 命令以上の間隔で出現した場
合には、その基本ブロックを複数の eld に分割して配置する。
IB は先頭の命令から必ず処理されるが 、分岐の結果によって、実際に実行される制御フローは異なるため、IB 内の命令がすべて実行されるとは限らない。そのため、IB は eld 単位に実行を区切ることができる。

図2
Fig. 2

命令情報

Instruction Information

VLDP では、IB 内で参照するすべての論理レジス
タ、IB の実行の結果として更新するすべての論理レ
ジスタの情報をコード に付加する。この情報をデー
タ同期情報と呼び、これによってデコード 時の論理レ
ジスタと物理レジスタの対応づけの処理を軽減する。
これらは 、Input Register Mask 、Output Register
Mask 、Output Resgiter Map として表現され、次のような意味を持つ。
Input Register Mask (IRMask): IB 内の全命令が参照する論理レジスタの情報をあらわす。64 ビットで構成され 、それぞれの bit が 64 個の論理レジ
スタに対応し、参照される論理レジスタに対応するビットが 1 となる。
Output Register Mask (ORMask):
IB の実
行の結果 、更新する論理レジスタの情報をあらわす。構成は IRMask と同様であり、更新する論理レ
ジスタに対応するビットが 1 となる。
Output Register Map (IRMask):
IB 内の各命令の演算結果に対応する論理レジスタをあらわす。命令番号順に更新する論理レジスタの番号を記述する。これが各命令の出力オペランドに相当する。
IB 内には最大 4 つの分岐命令が存在するため、それぞれの分岐命令の確定によって、更新するレジスタの情報は異なる。そのため、ORMask と ORMap については、それぞれの分岐命令をチェックポイントとして図 3に示すように 4 つ用意する。

IB (Instruction Block)
op0

op7

op8

op15 op16

op23 op24

op31

IRMaskfield 0field 1

Instruction

Branch Instruction

図1
Fig. 1

field 2

ORMap: Output Register Map
ORMask: Output Register Mask

IRMask: Input Register Mask
BB

BB

BB

BB

field 3

Blank Slot

命令ブロックの構成

Instruction Block Structure

Fig. 3

2

ORMap0
ORMask0

ORMap1
ORMask1

ORMap2
ORMask2

図3

データ同期情報

ORMap3
ORMask3

Data Synchronus Information

2.3 IB の生成
IB 内には 3 つの分岐ポイントが存在するため、その組合せは最大 8 とおりとなる。しかし、同じ基本ブロックから始まる IB を 8 とおり用意すると、1. 命令列が冗長となる 2. 同じ PC からスタートする複数のIB を区別する機構が必要になるという問題が生じる
ため、ひとつの PC からスタートする IB はひとつに限定する。実行される命令列の制御フローには局所性があるため 、実際の IB の構成では 、なるべく IB 内の命令が多く実行されるように、実行される確率が高い組み合せで命令列を生成する。これによって、コード 量の増大とフェッチ機構の複雑化を避ける。

図4

次に、実際に IB の生成例を示す。サンプルプログ
ラムとして、簡単なループ演算の livermore loop 5 番を取り上げた。その C のソースプログラムを、図 4に示す。これを Alpha AXP アーキテクチャのコード に
gcc の -O2 オプションでコンパイルしたコードを基本
ブロックに分割して、その制御フローの関係を示したものが図 5である。図中の BBxx は基本ブロックの番号を示す。また、矢印の太さは分岐先の実行確率を示しており、ループする方向に確率が高いと仮定した。

3.

taken

BB04
BB05
BB06
untakenBB07
untakenBB08
図5

サンプルプログラムのコントロールフロー

Fig. 5BB04(15 instr.)

BB04

BB05

(22instr.)

IB03:

BB03

BB04

BB05

BB06

(22 instr.)

IB04:

BB04

BB05

BB06

BB05

(26 instr.)

IB05:

BB05

BB06

BB05

BB06

(28 instr.)

IB06:

BB06

BB05

BB06

BB05

(28 instr.)

IB07:

BB07

BB03

BB04

BB05

(20 instr.)

IB08:

BB08

null

null

null

( 1 instr.)

IB の生成例

Example of IB Creation

複数パス実行VLDP では毎サイクルに最大 4 つの分岐命令を処理するため、分岐予測ミスの影響は従来よりもはるかに大きい。そこで、分岐ペナルティを削減するアプロー
チとして複数パス実行を採用し、分岐先が確定していない分岐命令の複数の分岐候補を投機的に処理する。
従来より、複数パス実行に関する研究は多く行われている10)4)5) 。しかしながらこれらの研究では、複数パ
ス実行における命令フェッチの戦略について主に議論されているにとどまっている。複数パス実行を実現する場合には、パスのフェッチの戦略にとどまらず、制
御依存とデータ依存の管理が大きな課題となる。この節では、複数パス実行の実現のために解消しなければならない課題を列挙し 、VLDP がこれをどのように解決しているかについて述べる。
3.1 複数パス実行の課題
複数パス実行では、これによって生み出される複数の制御流に対する制御依存とデータ依存を管理しなけ
ればならない。具体的には次にあげる処理である。
( 1 ) 命令間の順序関係の管理( 2 ) 分岐の確定による不用な命令の削除( 3 ) 異なる制御流におけるデータ依存性の保証
複数パス実行では、すべての命令の親子関係を管理するとともに、複数の制御流間での依存関係を管理する必要がある。これが、(1) の命令の順序関係の管理である。また、パスが投機的に処理されているので、分岐の確定により実際には必要のないパスを削除する必要がある。これが、(2) の分岐の確定による不用な命令の削除である。(1) の情報と (2) の操作は 、プロセッサ内部の全ての処理に必要とされるため、これが

BB01
BB02
BB03

taken

BB03

BB03

ことは難しい。そこで、メモリデバイスのバースト転送能力に注目し、連続化した IB 列を転送することで要求されるフェッチ能力を達成する。VLDP ではコー
ド の連続化をストリーミングと呼び、コントロールフ
ローが連続する複数の IB をまとめ、IB よりもより大きな単位で命令列を転送する。さらに、IB 内の NOP
を圧縮しメモリの利用効率を上げる。ストリームコー
ド は、コンパイラによって生成され、メモリ上にその形で格納される。メモリ上における命令転送のスルー
プットを確保するために、オフチップのメモリ ( メイ
ンメモリや外部キャッシュ) 、オンチップのキャッシュ
上は、すべてストリームコード が転送される。

C Source Code of Sample Program

taken

BB02

BB02

Fig. 6

サンプルプログラムの C ソースコード

untaken

BB01

IB02:

図6

int loop, n;void livermore05(long *x, long *y, long *z){
int l, i;for (l=1; l<=loop; l++) {for (i=1; i<n; i++) {x[i] = z[i] * (y[i] - x[i-1]);}}}
Fig. 4

IB01:

Contorl Flow of Sample Program

これに基づき、より実行される確率の高い命令の組
合せで 、各基本ブロックから始まる IB を生成する。
図 6 における括弧内は、IB に含まれる命令の数を示している。
2.4 IB のスト リーミング
容量の大きなメモリはレイテンシが大きいために、
ランダムアクセスの高速化によりスループットを稼ぐ

3

処理のクリティカルパスとならない実装を提案する必要がある。
そして、(3) は特に大きな課題である。制御流の分岐
よってデータ流も分岐するため、複数の制御流間で独立したデータ依存性を保証しなければならない。単純にデータ依存性を保証するための手法として、制御流の分岐ポイントにおけるデータの複製があげられる。
しかしながら、プロセッサにおけるデータはレジスタとメモリ上に存在し、それを分岐のたびに複製することは実質的に不可能である。そのために、これを仮想的に実現する、レジスタアクセス機構とメモリアクセ
ス機構が必要である。また、これらについても処理のクリティカルパスとならないために、パス管理機構と新和性の高い手法をとる必要がある。
3.2 複数パス実行の実現
VLDP では大規模に複数パス実行を行う現実的な手法を提案する。それらは大きくパス管理、レジスタ
アクセス管理、メモリアクセス管理に分けられる。
3.2.1 パ ス 管 理
複数パス実行におけるパス管理を実現する場合 、フェッチしたパスに対してタグを与え、そのタグを表で管理することで命令の順序関係を管理する。VLDP
ではタグの与え方を工夫し、タグ同士の比較により順
序関係の判定が行えるようにする。このタグを BHTagと呼び、フェッチ時に IB 内の各 eld に与える。パス
管理はすべて BHTag を用いて行い、BHTag の比較だ
けでパスが親子関係にあたるのか、異なる制御流のものであるかを比較できるようにする。これによって、パス管理の表へのアクセスは、フェッチ時と完了時 、それに伴うパス無効化時だけとなる。
3.2.2 レジスタアクセス管理
VLDP では 、物理レジスタと論理レジスタの対応
を 、Register Map Set (RMS) という形で保存する。
フェッチ時にフェッチポ イントにおける RMS が与えられ、デコード時に実行に物理レジスタへのアクセス
情報を生成する。同時に、その IB を実行した後の状態の RMS を生成する。IB 内には最大 4 つの分岐命令が存在し、4 つの新たなフェッチポイントを持つため、4 つの RMS が生成される。RMS は分岐ポイント
におけるデータ流のチェックポイントであり、これによって複数パス実行におけるレジスタのデータ依存を保証する。VLDP では、IB 内のレジスタ同期情報を用いることにより、物理レジスタへのアクセス情報の生成と新たな RMS の生成の処理を簡単化している。
3.2.3 メモリアクセス管理
メモリアクセスにおける制御依存性とデータ依存性は、ロード ストアユニットによって保証される。ロー
ド ストアユニットは、実行ユニットからのメモリアクセスのリクエストを保持し、ストア命令に関しては、
そのストアがリタイアするまで保持して依存性を解消する。ロード に関しては、依存性をロードストアユ
ニットで解析し、保持されているストア命令からフォ
ワーディングできるものはフォワーディングする。複数パス実行により、リタイアしない命令からのメモリアクセスも処理されるが、これはすべてロード ストア
ユニットにおいて吸収する。VLDP では大規模なロード ストアユニットを構成することで、投機的メモリア
クセス、依存性の解消、ロード ストア間のデータフォ
ワーデ ィングを実現する。

基本構成

4.

VLDP の基本構成を図 7 に示す。その構成は大きく Contorl Section と、Exectuion Section 、Memory
Access Section に別れ、Control Section ではフェッチとパス管理、Execution Section ではデコード と実
行 、Memory Access Section では Load/Store 命令の処理を行う。
Control Section
BHTag
Management Unit

Path Management Unit
PC

Completion/Exception

StreamRMS

Execution Section

Stream Buffer

IB Buffer

RMS Buffer

BHTag

IB

Stream
EU Management
Unit

Decoder
RRM

EU

EU

BHTag

EU

IB

On-Chip
Cache

EU

Data Network

Data

Memory Access Section

Load/Store

Data

Data Buffer

Load Store Unit

図7
Fig. 7

4.1

VLDP の基本構成

Fundamental Structure Block Diagram

命令処理

VLDP における命令の処理は IB の単位で行われ、フェッチとデコードは直列、実行が並列に処理される。
ひとつの IB はひとつの EU(Eexecutin Unit) に割り当てられて実行され、EU が複数存在することで IBを並列に実行する。EU 間でのレジスタアクセスのために EU 間を接続する Data Network が存在する。
Path Management Unit (PMU) は IB のフェッチと完了を管理する機構であり、RMS Bu er と BHTag
Management Unit はフェッチした IB に RMS と BHTag を与える。Execution Section において、命令のデコード と物理レジスタへのアクセス情報が生成され、EU Management Unit(EUMU) によって指示された EU に IB を割り当てて実行する。また、EUMU
は EU における IB の実行完了と EU の解放の管理も行う。分岐の確定により不用となったパスの削除の管理は PMU で行われ、その指令を全機構に送ることで各機構が命令の削除を行う。EU 内にはメモリアクセ
ス機構は持たず、ロード ・ストア命令は Load Store
Unit に直接発行される。
4.2 レジスタアクセスの効率化
VLDP では、処理命令数の大幅な増大とともにレジスタアクセス数も多くなるため、集中化したレジスタ
ファイルでは大規模かつ複雑化する。そこで、レジス
タファイルを分散させ各 EU に配置する。

4

Bu er に対して、取得した指定することで、新たな IB
をフェッチする。このとき、フェッチする IB の親にあたる IB の BHTag と予測された IB のフェッチポイン
トを BHTag Management Unit と RMS Bu er に送り、フェッチポイントにおける RMS と新たな BHTagを取得する。
デコード 処理には 3 ステージを要し、IB を割り当
てる EUID の指定、IB のデコード、RRM の生成が行われる。EUMU は EU の実行状況を把握しており、新たな IB が割り当て可能な EU の EUID を指定する。また、指定された EU に従い RMS と IRMask より RRM を生成し、ORMask と ORMap を参照する
ことで RMS の更新を行う。

「短い距離で命令間の一時的なデータ転送に使われ1)というレジスタアクセスの性質に注ることが多い」目すると、IB 内で生成されたデータを IB 内で消費する IB 内レジスタアクセスを、IB 間レジスタアクセスと分離できる。特に IB 内レジスタアクセスのうち特に IB 内で生成され、IB 内で消費されてしまうレジス
タを"Ephemeral Value" と定義し 、論理レジスタを消費しないデータ転送を実現する。これは、IB に情報を付加することで行い、データの消費者が生成者のIB 内命令番号を指定することで実現する。(図 2 おける input eld の select = 11 がこれに相当) このよ
うに、局所的ななレジスタアクセスを最適化して高速化するとともに、大域的なレジスタアクセス数を減らすことで、平均的なレジスタアクセス時間をを低下させることなく、分散レジスタ構成により仮想的に大規模なレジスタファイルを実現する。
さらに、IB 間のレジスタアクセス性能を低下させないために、他の IB に対するレジスタアクセス要求
はデコード時に生成される。図 8に示すように、IB の割り当てと同時に他の EU に対して Register Request
Map (RRM) が発行される。RRM を受け取った EU
では、指定されたレジスタ値が準備でき次第値を転送する。

Instruction Fetch Instruction Decode Instruction Decode Instruction Decode(Stage 2)(Stage 1)(Stage 2)(Stage 3)

Get Fetch PC
Get Parent BHTag

Fetch IB
Get RMS
Create BHTag

Prediction PC

IB Buffer

CreateRegister Request Map
17

EU2:R18

EU2:R3

Logical

EU

Num.

1
2
3
2

17
13
8
25

BHTag: Branch History Tag
RMS: Register Map Set

図9Fig. 9Distributed
Register FileEU

Distributed
Register Fileinter-EU register accessDistributed
Register Fileinter-EU register access
Data Network

図8
Fig. 8

DecodeIB

IRMaskCreate RRM

RRM
BHTag

Update RMS

RMS
EUID

EU
Management Unit

フェッチとデコードの処理
Fetch and Decode Process

EUMU で指定された EU に対して、IB が割り当てられることで IB は実行される。IB の割り当てとともに、他の EU に対しては RRM が発行される。それぞれの EU は RRM に従って、値が準備できたものから
レジスタ値を返す。IB は EU 内の 32 命令幅の命令ウィ
ンド ウに格納され、実行可能な命令が out-of-order に発火され、命令レベル並列処理される。そのため、実行ステージのサイクル数は IB により異なる。
5.2 パイプラインイメージ
次に、2.3 で用いたサンプルプログラムを実行した
ときの、パイプラインフローを図 10に示した。EU における実行サイクルとは、データ依存グラフの段数をもとに設定し、メモリアクセスについては理想化した。
また、分岐命令が確定するサイクルも同様に設定している。
図 10 中の矢印は、分岐命令の確定とパスの削除の関係を示している。この例では、サンプルプログラムの内側のループを 4 まわす例にすぎないが、途中までの実行を見ると 、外側のループ 2 回に相当する 20 サ
イクル目までに実行した 、有効な総命令数は 147 命
令に相当し、単純計算で 147/20 = 7.35 という実行
IPC になる。

RRM
EU

ORMap
ORMask

RRM: Register Request Map

RRM

EU

IB

RMS Table

Physical

R1
R2
R3
R4

Decode IB
Create RRM
Update RMS

BHTag
BHTag
Path
Managment UnitManagement
Unit Parent BBID

EUID: Execution Unit ID numher

IB

Get EUID

RMS

Decode5.

Instruction Fetch(Stage 1)

EU 間レジスタアクセス
Inter-EU Register Access

命令実行の流れ

この節では、VLDP の命令実行の流れについて、サンプルプログラムのパイプラインフローの例をあげて説明する。
5.1 パイプライン構成
フェッチとデコード のパイプラインステージ構成を
図 9に示す。
フェッチ処理には 2 ステージを要し、IB のフェッチと RMS 、BHTag の取得を行う。PMU は、分岐命令の履歴とすでにフェッチしたパスの情報を管理し、その情報に基づいて次にフェッチする IB を予測する。予測の結果フェッチ候補となる PC は優先順位を付けてバッ
ファリングされており、このバッファから次にフェッ
チする IB の PC を取得する。IB が展開されている IB

6.

性能に関する考察

VLDP アーキテクチャは実効 ILP にして 8 という値を達成する。これについて、図 11 にスループット
ベースの性能について示した。VLDP は、フェッチ、
デコード 、EU に対する IB の割り当てのスループッ

5模な複数パス実行の実現について説明した上で、ターゲットとしている ILP 8 の実現について議論した。今後は、アーキテクチャの実装と、シミュレーションによる性能の裏付けを行っていく。また、専用コンパイ
ラの研究も行い一層の性能向上を目指す。
謝辞 本研究の一部は、文部省科学研究費補助金 (基盤研究 (B) 課題番号 11480066) および、(株) 半導体
理工学研究センターとの共同研究によるものである。

IB01(01) F1 F2 D1 D2 D3 E1 E2 E3 E4
F1 F2 D1 D2 D3 E1 E2 E3 E4
IB05(02)F1 F2 D1 D2 D3 E1 E2 E3 E4
IB05(03)F1 F2 D1 D2 D3 E1
IB07(04)
F1 F2 D1 D2 D3 E1 E2
IB05(05)
F1 F2 D1 D2 D3
IB07(06)
F1 F2 D1 D2 D3IB05(07)
F1 F2 D1
IB07(08)
F1 F2 D1
IB05(09)
F1 F2 D1 D2 D3 E1 E2 E3 E4
IB07(10)F1
IB05(11)F1 F2 D1 D2 D3 E1 E2 E3 E4 E5
IB06(12)
IB07(13) F1 F2 D1 D2 D3
F1 F2 D1 D2 D3 E1 E2 E3 E4 E5
IB06(14)F1 F2 D1 D2 D3
IB07(15)F1 F2 D1 D2 D3 E1 E2
IB06(16)F1 F2 D1 D2
IB07(17)F1 F2 D1 D2 D3
IB06(18)F1 F2 D1
IB07(19)F1 F2 D1
IB06(20)F1 F2 D1 D2 D3 E1 E2 E3 E4
IB07(21)F1
IB06(22)F1 F2 D1 D2 D3 E1 E2 E3 E4
IB07(23)F1 F2 D1 D2 D3
IB06(24)

図 10
Fig. 10参 考 文 献1) C., L. A. L. and Gao, G. R.: Exploiting
Short-Lived Variables in Superscalar Processors, Proc. of the 28th MICRO , pp. 292{302(1995).
2) Fillo, M. and Keckler, S. W.: The M-Machine
multicomputer, Proc. of the 28th MICRO , pp.
146{156 (1995).
3) Hammond, L., Hubbert, B., Siu, M., Prabhu,
M., Chen, M. and Olukotun, K.: The Stanford
Hydra CMP, IEEE MICRO Magazine MarchApril , pp. 250{259 (2000).
4) Heil, T. H. and Smith, J. E.: Selective Dual
Path Execution, Technical Report, Universityof Wisconsin-Madison (1996).
5) Klauser, A., Paithankar, A. and Grunwald,
D.: Selective Eager Execution on the PolyPath
Architecture, Proc. of the 25th ISCA, pp. 250{
259 (1998).
6) Lam, M. S. and robert P. Wilson: Limits ofControl Flow on Parallelism, Proc. of the 19th
ISCA, pp. 46{57 (1992).
7) Palacharla, S., Jouppi, N. P. and Smith, J. E.:
Complexity-E ective Superscalar Processors,
Proc. of the 24th ISCA, pp. 206{218 (1997).
8) Sohi, G. S., Breach, S. E. and Vijaykumar,
T. N.: Multiscalar Processor, Proc. of the 22th
ISCA, pp. 414{425 (1995).
9) Tullesen, D. M., Eggers, S. J. and Levy, H. M.:
Simultaneous Multithreading: Maximizing OnChip Parallelism, Proc. of the 22th ISCA, pp.
392{403 (1995).
10) Uht, A.K. and Sindagi, V.: Disjoint Eager Execution: An Optimal Form of Speculative Execution., Proc. of the 28th MICRO , pp. 313{325(1995).
11) 鳥居淳, 近藤真己, 木村真人, 西直樹, 小長谷明
彦: On Chip Multiprocessor 指向制御並列アー
キテクチャ MUSCAT の提案, 並列処理シンポジ
ウム JSPP'97, pp. 229{236 (1997).
12) 小林良太郎, 岩田充晃, 安藤秀樹, 島田俊夫: 非数

パイプラインフロー
Pipeline Flow Image

トは毎サイクル 1IB となる。IB の実行には複数サイ
クル要し、複数の IB が並列に処理される。IB は実行の結果、リタイアするものと破棄されるものが存在する。VLDP における複数パス実行では、リタイアする
パスと投機的処理の結果不用となるパスの割合を 1:1としており、フェッチスループットの 50%をリタイア
スループットとする。IB の平均命令長さは 16 命令以上であるため、リタイアスループットとして 8 命令以上を達成する。
1 IB/cycle
IB

Fetch

IB

Decodestart execution
under execution
retireinvalidate

1 IB/cycle
1 IB/cycle Issue to IBEU
IBEU

Ave. 0.5 IB/cycle

IB

IB

IB

IB

IB

IB

IB

ALU-NetInvalidate

Ave. 0.5 IB/cycle = IPC 8Retire

図 11Fig. 11

命令処理のスループット

Instruction Process Throughput

細粒度並列性を利用するマイクロプロセッサの ILP
は、基本的には依存性解析を行う命令ウィンド ウの大きさにより決定される。VLDP においては、IBEU における命令レベル並列処理は 32 命令のウィンド ウにより実現され、この EU の並列処理によりより大きな並列度を利用可能とする。仮想的には、32 × IBEU の数だけの命令ウィンド ウの拡大を行うことに相当し、EU の数を 16 としたとき命令ウィンド ウの数は 512
命令に相当する。
7.

結論

値計算プログラムのスレッド 間命令レベル並列を利用するプロセッサ・アーキテクチャSKY, 並列
処理シンポジウム JSPP'98, pp. 87{94 (1998).

本論文では、細粒度並列性利用の必要性を述べた上で、積極的に細粒度並列性を利用する VLDP アーキテ
クチャの提案を行った。そして、VLDP における大規6