◆Load/Store
さて、見かけ上一番大きく変わったのは、Load/Storeユニット(Photo16)かもしれない。AGUが2→3となり、またAVX2命令をサポートした結果として、256bit Load×2と256bit Store×1を1cycleで実施できるようにする必要が出てきた(これが実現できないとAVX2命令の処理のボトルネックがLoad/Storeユニットになってしまう)。
-
Photo16: AGU1からLoad Queueに至る矢印を入れ忘れている様に思われる。
さて、Load/Storeユニットに関して、Coffee LakeというかIntelのCoreアーキテクチャは、AGUがLoad用とStore用で別々に用意されるという非対称構成になっていたが、AMDは(それこそK7の頃からの伝統であるが)AGUはLoad用/Store用で区別がなかった。実際Zenの構成(Photo17)の場合、
-
Photo17: AGU0からDAT0、あるいはAGU1からDAT1への直接アクセスの矢印が抜けているのはこっちもミスと思われる。
AGU0：基本はLoad用で、TLB 0/Data 0に直接アクセス可能。ただStore Queueにリクエストを出すこともできる。
AGU1：基本はLoadで、TLB1/Data 1に直接アクセス可能。ただStore Queueにリクエストを出すこともできる。
という構成になっていた。Loadに関しては、Load Queueを介さずに直接TLB/Dataにアクセスできるが、StoreのみStore Queueを介する形だ。あるいはAGU0からTLB1/DAT1をアクセスも不可能ではないが、その場合はLoad Queue経由となる。
これがZen 2ではAGU2が新たに追加され、
AGU2：基本はStoreで、Store Pipeに直接アクセス可能。ただLoad Queueにリクエストを出すことで、間接的にTLB/DATAにアクセスすることもできる。
と変更になった。
一番効率が良いのはAGU 0/1がLoad、AGU 2がStoreをハンドリングすることで、恐らくこの調整を行うためにAGUのスケジューラが一体化されたのだと思うが、仮にうまくスケジュールできない場合、この原則を崩しても問題ない(ただLoad Queue/Store Queue経由になる分、若干Latencyが増えると思われる)ということで、Coffee Lakeなどに比べると柔軟性が高い構成になっている。
