動的バイナリ変換における本研究の着眼点と新規性

本研究は，性能の評価や解析を目的としたシミュレータの高速化としてバイナリ変換ア クセラレータを研究したものである．本節では，まず本研究の着眼点を述べ，次に5.6で個々 に述べた関連研究との差異を新規性としてまとめる．

関連研究では，実現しているバイナリ変換で使用した性能を向上させる工夫について述 べられているが，それらの投資効果やトレードオフについて言及されていない．また，設 計品質を確保するときに設計の簡素化が重要となるが，そのトレードオフも示されていな い．本研究では，性能向上への投資効果を上げるため，バイナリ変換の対象とする命令種 の効率化，コード生成の最適化，対象とするレガシーISA やホストの種類に依存しない共 通化，マイクロプロセッサの進歩による価値観の変化に着目した見直し，マルチプロセッ サを対象としたとき固有の工夫，について順に着眼点を述べる．

まず，バイナリ変換の対象とする命令種の効率化について考える．命令の出現頻度は，

基本的な命令ほどまた機能が単純な命令ほど実行頻度が高いことが知られている．そこで 次のようにブレークダウンする．

・ 実行頻度の低い命令のために，バイナリ変換の開発コストを掛けるのは効率が悪いた め，バイナリ変換の対象を基本的な命令に限定するのがよい．

・ PowerPCのbcX命令を例にとると，命令フィールドを組み合わせてより高機能な命

令を形成している．しかし，実際によく使われる命令の組合せは限定されている．そ のため，複雑な機能を持つ命令でもその一部の機能についてのみを，バイナリ変換の 対象を基本的な命令に限定するのがよい．

・ 基本的な命令や単純な命令をバイナリ変換の対象とし，それ以外はインタプリタ用の 関数を呼び出すようにすればバイナリ変換の開発コストを削減できる．これは，イン タプリタを第3章で提案した function 方式で実装すれば新たな開発コストの増加要 因にはならない．

・ バイナリ変換の対象であるレガシーISA を使用しているシミュレーションのユーザが

増えるかまたは処理速度向上への要求が増えたら，その時点で変換対象とする命令種

を追加すればよい．

次に，バイナリコード生成の最適化について考える．バイナリ変換はインタプリタに比 べて数倍から十倍ほどの性能向上が可能といわれている．その幅は広いため数倍と十倍の 途中に丁度よいトレードオフがあると予想でき，次のようなトレードオフを考える．

・ バイナリ変換を用いて高い性能を目指す場合は，レガシーISAのレジスタをホストの レジスタに割りつけるのが定石である．この方法を使用するとレガシーレジスタの読 出し操作が不要となり，ホスト命令のコード削減と処理実行の高速化が見込める．し かし，CISCからRISCへのアーキテクチャ転換時にレジスタ本数を増やして移植を 容易化したときのようにレジスタ数を増やせるわけではない．したがって本質的には レジスタ本数不足は解消しないため，性能向上に寄与するが十分な性能向上にはなら ないと考える．また，上記のインタプリタ用の関数を呼び出す手法との両立が困難と なる^†32．処理速度という点では，メモリ配列からレガシーレジスタの読出しを行わず に，ホストのレジスタ間のコピーを行えばほぼホストのレジスタへの割付けと同等の バイナリ変換の処理性能を実現できると考える．スーパスカラのホストを使用すると その可能性は更に高くなる．そこで，メモリ配列をレガシーレジスタの本籍として結 果の書込みはメモリ配列に行うが，読出しにはホストレジスタに残った値を再利用す れば，リードアフターライトと呼ばれるパイプライン干渉を回避できる．

・ 1.2.4で既に基本ブロックと拡張ブロックについて説明した．その基本ブロックを跨

ぐようなバイナリ変換は行わないようにする簡素化は，開発投資をミニマムにする方 法の１つである．しかし，開発経験から拡張ブロックレベルまでの範囲を対象とした バイナリ変換が必要と考える．一方，他の分岐ブロックまたはその分岐ブロック内へ 直接に分岐する“チェイニング”を行うと，バイナリ変換されたホストコードの流れ に合流が生じてしまい，変換処理が一層複雑化する．したがって，そのようなチェイ ニングはしない方がよい．

・ シミュレータを使用するプロジェクトのニーズに合わせて，バイナリ変換アクセラ レータの開発投資を増減するのは自然である．したがって，レガシーISAまたはホス トごとに変換の適用レベルを設定して，ニーズに合った変換レベルを実装すればよい．

次に，対象とするレガシーISA やホストの種類に依存しない共通化について考える．異 種マルチプロセッサの混載シミュレーションを実現するためには，シミュレータのコア部 がどのレガシーISA のプロセッサモデルにも依存しないようにインターフェイスを規定す る必要がある．また，シミュレータが複数のホストにも対応するためには，レガシーISA とホストの種類の組合せの影響を受けるべきではない．シミュレータに実装すべき処理の 種類が，レガシーISA とホストの種類の掛け算にまで増えるとシミュレータの拡張性と保 守性に問題を生じる．したがって，レガシーISA およびホストに対応した実装は，シミュ レータが標準機能としてサポートする処理に単純にマッピングできるようにして，レガ シーISA やホストに依存したカストマイズはできるだけ避けるべきである．そのような観

†32 原理的にはインタプリタ用の関数を呼び出すときに本籍となるメモリ配列に書き戻せばよいが，その制 御は複雑となりまた，呼び出しが多いと性能も劣化する．

点から，次の点に着目して3階層構造のトランスレータが有効と考えた．

・ レガシー命令と別のレガシー命令に渡る最適化を行わなければ，バイナリ変換のレガ シーISAへの依存部およびホストへの依存部の排除が容易となる．

・ レガシー命令を，オペランドの読出し，演算，結果の格納を単位としてその生成方法 を記述すれば，用意する機能も単純化できる．加えて，それらの記述がインタプリタ の記述と似ていると，テキストエディタを使ってコードの書き換えを省力化できる．

これが提案している3階層方式のトランスレータのlayer-1の記述となる．

・ 上記の機能をホストの1個ないし複数個の命令に単純にマッピングできれば，バイナ リ変換のロジックを簡単に実装できる．

・ バイナリ変換の実装にはホストの機械命令の知識が必要となる．5.1.9で紹介した WSS のように C コンパイラなどの力を借りてバイナリ生成する方法もあるが，デ バッグのためにホストの機械命令の知識は必須となる．そのため，デバッガと相性の よい変換処理を実装することが望ましく，表形式で変換ルールを記述する方法は効率 がよくないと考える．変換のロジックを記述したソースコードにブレークポイントが 設定でき，そのソースコードから生成されたバイナリコードをデバッグできる構造が よい．これが提案している3階層方式のトランスレータのlayer-2となる．

・ ホスト命令を1個生成する処理は，別のホスト命令を生成する処理と独立であれば，

ホスト命令同士の組合せ問題がなくなり開発が容易となる．ホスト命令生成に関する 簡素化の課題としては，定数を1命令で生成できるか，ゼロ値や符号拡張などのため に別の命令を使うように変形した方がよいかなどの選択肢である．このような最適化 は，生成する頻度が高い命令では最適化実装をすべきであり，そうでない命令では最 適化しない方が検証効率が上がる．したがって，ホスト命令種ごとに処理を別けると 効果的と考える．これは提案方式のlayer-3に相当する．

・ ホスト命令セットには複雑な仕様を持つ命令がある．そのような命令を生成するのは，

その仕様の理解も含めて効率が悪い．通常は同等の機能を単純な命令の組み合わせて 実現できることが多く，それを利用するのは合理的である．layer-2 レベルでその組 合せは記述できる．

次にマイクロプロセッサの進歩により，バイナリ変換の実装方法の得失も変わってきて いると考える．特に，パイプラインが深くなったため分岐予測ミスの影響が大きい．また，

2次キャッシュメモリの容量が大きくなりその効果を利用して，条件付分岐を減らす実装が よいと考える．なお，従来研究のShade やSimOS とは開発時期が異なり同じ評価ベンチ マークや同じホストを入手できないため直接に比較はできないが，現在のベンチマークや ホストを用いてこの着眼点の効果は確認できる．これは，次のようにブレークダウンする．

・ ホストの分岐予測ミスを減らすとともに分岐ペナルティサイクル数を減らすには，バ イナリ変換のランタイムの分岐を極力減らすことが効果的である．そのためには，

セットアソシアティブ形式の表よりむしろ一回の分岐で判定できるダイレクトマッ プ形式の表探索が効果的である．ダイレクトマップの欠点はハッシュエントリが競合 することであるが，空きエントリを考慮して大きめのエントリ数にし，その大きさを 2次キャシュメモリより溢れない程度にすればよい．

次に，マルチプロセッサを対象としたとき固有の工夫について考える．ユニプロセッサ