LMUL>1の対応考え直し)ベクトル命令における、LMUL>1の対応というのは結構難易度の高い問題だ。今回はその解決方法として、LMULの値がVSETVL命令で変更されると、例外を出して物理レジスタの構成を整列し直す方式を考えたい。この方式を実際にVerilogで記述して動作をテストしようと思ったのだが、問題にぶつかった。以下の例外対応コードを使って物理レジスタをLMULの大きさに整列しようとしていた。以下のコードがやっていることは:まずはすべての現在のアクティブな物理レジスタの内容をメモリにストアする。なるようにする(つまりLMULの倍数しか物理レジスタIDを使えないようにする)。物理レジスタにデータを書き戻す。mretこうすることにより、レジスタの内容をキープしながら、物理レジスタIDを整列する。して扱うことができるようになる(LMUL=8なのでv8の物理レジスタIDから連続した8個の物理レジスタはマイクロアーキテクチャ的に自動的に確保されたものとする)。その代わりにフリーリストのサイズはLMUL分の1となり、取れる値はLMULの倍数のみとなる。することでLMULへの簡単な対応を実現しようとしたのだが、問題にぶつかった。vsetvl命令実行後にフリーリストの大きさが変わり、LMULの倍数しか物理レジスタが取れなくなるのだが、その後にvl1r.vを実行すると、これらの命令はLMULを無視して1レジスタ単位でデータを扱うので、取得できる物理レジスタIDと合わずに矛盾が生じる。v7が実行されると、新しい物理レジスタID=32が取得されると同時に、もともとの物理レジスタID=7が解放され、フリーリストにLMULの倍数ではない7というIDが入ってしまい矛盾が生じる。この時、v7はすでにv0レジスタグループに入っているのだから、物理レジスタID=7を解放せずに、v0の持つID=0を解放すればいいのかもしれない。するとv0の物理レジスタIDが0から32に自動的に切り替わってしまい、データの移動が発生しておらずやはり矛盾が生じる。LMULの粒度と異なるベクトル操作命令を何も考えずにぶち込むのは非常に問題となる。ベクトル・ロードストアはこのようにvsetvl命令と関係なくEMULを変えてくるので結構面倒くさい。Stride命令でデータの書き戻しを行えばいいんじゃないか。v24によるデータ復帰マイクロコードをこのように変更して再実験を行う。LMUL>1の対応考え直し)前回の続き。マイクロコードを変更して再実験を行う。vl/vtypeのリネームに関する検討)自作CPUにベクトル実行エンジンを追加する試行をしている。3はてなブログをはじめよう!msyksphinzさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。