前回の続き：
3.1.1. mem-regsの改善
CVP-1 のトレースは、0 から 3 までの書き込みレジスタを持つ命令で構成される。 プリフェッチ・ロードとストアは、CVP-1トレースには書き込みレジスタがない（ベース・アップデートを行うストアや、Exclusiveなストアには書き込みレジスタがある） さらに、フラグレジスタを変更する多くの演算命令は、書き込みレジスタが全くない状態でCVP-1トレースに現れる。
複数の書き込みレジスタを持つ命令は、ベース・レジスタを更新するロード（例えば、前の例のLDR）、ロード・ペア（例えば、前の例のLDP）、またはベクタ・ロード（例えば、LD2、LD3、LD4）であり、複数のメモリ・アクセスを伴う可能性がある。
一方，オリジナルのcvp2champsimコンバータでは、分岐を除くすべての命令で行き先レジスタを1つに制限している。 書き込みレジスタを持たないプリフェッチロードとストアの場合、レジスタX0が追加される。 これにより、これらの命令と、レジスタ X0 から読み出す若い命令との間に、元の CVP-1 トレースには存在しない依存関係が生じる。 同様に、複数の書き込みレジスタを持つロードでは、最初のものだけが保存される。 その結果、これらのロード命令と、欠落している書き込みレジスタから読み出す若い命令との間の依存関係は、変換後のトレースからは欠落している。
これらの問題に対処するため、改良された cvp2champsim コンバータは、プリフェッチ・ロードと、書き込みレジスタを持たないストアに、書き込みレジスタを追加しない． また，CVP-1 のトレースで指定されたすべての書き込みレジスタを保持する 。
3.1.2. base-updateの改善：メモリ命令のデスティネーションレジスタのレイテンシが異なる依存関係の解決
前述の例で、書き込みレジスタの数を固定した後、我々のコンバータは、LDRとLDPの両方で、1つのソース（X0）と2つのデスティネーション・レジスタ（X1とX0）を持つロードを生成する。
つまり、どちらの場合も、レジスタX0とX1は、ロード完了後の従属命令でのみ使用可能となる。
トレースの観点からは、両レジスタは対応するメモリ・アクセスが完了した後にのみ利用可能になるはずなので、ロード・ペアではこれは正確である。
しかし、この場合、X0は、ベースレジスタX0を更新する算術演算のレイテンシの後に従属命令に対して利用可能であるべきであるため、これは、前後のインデックスインクリメントLDRに対しては正確ではない。
ベースレジスタを更新するメモリ演算に関して、変換されたトレースをより正確にするために、そのアドレッシングモードを推測し、特定の命令がベース更新を実行するかどうかを判断することを試みる。 この目的のため、トレースメンテナ[36]によって提案された発見的手法を活用し、若干の改良を加えている。 この発見的手法は、ソースレジスタと書き込みレジスタ、CVP-1トレースに存在する書き込みレジスタの出力値、トレースリーダ内のデータ構造に保持され、トレース命令によって書き込みレジスタに書き込まれた値で更新されたレジスタの現在値に基づいて、アドレッシングモードを推論する。 要するに、この推論は、ソース・レジスタと書き込みレジスタの本数をチェックすることによって行われる。 しかし、ChampSimはデフォルトで4本しか許可していない。 このような命令の使用頻度は非常に低く、ChampSimへの変更を制限することを目的としているため、このコンバータは、このような場合、最初の4つのソース・レジスタのみをChampSimトレースに伝える。
ソース・レジスタがデスティネーションでもあり、ベース・レジスタ候補に書き込まれた値と比較した実効アドレスの差が即時オフセット内に収まるかどうか。 この推論は、常に正確な答えが得られるとは限らないため、最善の努力であることに注意されたい。
アドレッシング・モードが得られたら、さらに、ベース・レジスタを更新する算術演算がメモリ命令の前に来るべきか、後に来るべきかを判断するために、インデキシング・インクリメントの前と後を区別する。 このためには、メモリ命令の実効アドレスとベースレジスタに書き込まれた値を比較するだけでよい。 もし両者が一致すれば、ベースレジスタはメモリアクセスが行われる前に更新され、そうでなければ、ベースレジスタはメモリ命令が行われた後に更新される。 幸運なことに、CVP-1 のトレース命令には、書き込みレジスタに書き込まれた値が含まれているので、この比較は簡単である。
最後に、コンバータは 2 つの命令をトレースファイルに書き込む。 CVP-1トレース命令のPCを最初の命令（すなわち、プレインデックスインクリメントの場合はベースレジスタ更新ALU、ポストインデックスインクリメントの場合はメモリ命令）に割り当て、PC＋2を2番目の命令（すなわち、プレインデックスインクリメントの場合はメモリ命令、ポストインデックスインクリメントの場合はベースレジスタ更新ALU）に割り当てる。 この変換が引き起こす可能性のある唯一の不正確さは、シミュレータが命令を2つのMicroOpとして扱い、ROBとIQに2つのエントリを占有し、特定のマイクロアーキテクチャがその動作を1つのマイクロオ ップで実装できるにもかかわらず、パイプライン全体で2倍の帯域幅を必要とすることである。 これは、シミュレータ・ロジックがこれを識別し、2つのトレース命令を一緒にバンドルできるため、基本的な問題ではない。
この改良の重要性は、ALU演算のレイテンシ後にベースレジスタを依存命令で利用可能にすることにある。 この改善がなければ、ベース・アップデートを実行しメイン・メモリ・アクセスをもたらすロードの場合、ベース・レジスタが利用可能になるのはメモリ・アクセスが完了した後となり、ベース・レジスタに依存する若い命令の実行が遅れることになる。 プレインデックス・インクリメント・ロードとポストインデックス・インクリメント・ロードを正しく 識別することで、アプリケーションのデータ・メモリ・フットプリントをより良く伝えること もできる。
3.1.3. mem-footprint の改善： メモリ・フットプリントの改善
最後に、メモリ命令のアクセスサイズに注目する。 CVP-1 と ChampSim のトレースフォーマットには本質的な制約があるため、元のアプリ ケーションのメモリフットプリントを ChampSim に正しく伝えることが難しい。 まず，CVP-1トレース・フォーマットは、ロード命令の書き込みレジスタ内で、メモリからポピュレーションされたレジスタと、メモリ・アクセスの前後に更新されたアドレス・レジスタをマージする。
さらに、Aarch64 ISA、したがってCVP-1トレースには、64Bキャッシュラインアクセスが2回発生する可能性のあるロードペアとベクタロードが含まれる。 その結果、CVP-1トレースに含まれる転送サイズに出力レジスタ数を乗じたものを、命令の総アクセスサイズとして計算すると、総メモリアクセスサイズを過大評価することになる。
さらに悪いことに、ChampSim はメモリ操作のアクセスサイズをモデル化していないため、ChampSim のトレースにはその情報が完全に含まれていない。
これを改善し、元のアプリケーションのデータ・メモリ・フットプリントをChampSimによりよく伝えるための我々の解決策は、コンバーターに命令のメモリ転送サイズと、この転送サイズが単一または複数の64Bキャッシュラインのどちらを含むかを判断させることである。 この目的のために、まず、メモリアドレスメントモードを特定し、命令がベースレジスタを更新するかどうかを判断する。 これにより、命令の転送サイズを正しく計算することができる。その後、メモリ操作が2つのキャッシュラインにまたがる場合、ロードかストアかに応じて、変換後の命令に2つ目のキャッシュラインのアドレスを2つ目のメモリソースまたは書き込み先として追加する。 それに加えて、我々のコンバータは、64BストアをDC ZVA命令として識別する。 これは、64バイトの自然に整列されたブロックをゼロにするものである。 CVP-1 の公開トレースではこのようなケースは見つからなかったが、この命令はアーキテクチャ上、アラインメントされていないアドレスを持つことが許されている。
従って、DC ZVA 命令は、定義上、1 つのキャッシュラインに触れるので、我々のコンバータは、常に、その有効アドレスをキャッシュライン境界にアライメントする。
