Oryonコアの「中身」

　さてそんなOryonコアのフロントエンドの構成が図3で、特徴は図4。この時の説明はOryonコアを利用したモバイル向け製品（Snapdragon X Eliteなど）に実装した際の構成であるが、モバイル向けとしては結構重厚な構成である。もちろん、モバイルといってもハイエンド向けではそれなりの性能が必要なのは当然だが、16命令Fetchとか8命令同時デコードというフロントエンドはかなりトップエンド向けを狙った構成だ。

図3：ROBが650エントリ以上（このスライドでは600+だが、後に650+という数字が出てくる）って、どれだけ命令をIn-Flight状態に置くつもりなのかというレベルである［クリックで拡大］ 出所：Qualcomm

図4：L1が6-way 192KBというのもちょっと面白い、あと命令TLBが結構重厚だし、分岐ミスのペナルティが13cycleはかなり優秀な方だと思う［クリックで拡大］ 出所：Qualcomm

　ではバックエンドは？ということで概略を図5に示す。通常のALU（IXU）が6-wide、VXU（Vector/FPU）が4-way、LSU（Load/Store Unit）も4-wayという、IntelやAMDの最新x86コアと比較しても遜色ない重厚さである。ただVXUに関して言えば、まだ2024年ということでかSVE/SVE2ではなくNEONベースになっているのがちょっと特徴的である。また、やはり2024年ということでFP4/FP8のサポートは無いが、INT8に加えてBF16のサポートがあるのは、さすがというべきか。

　ALUの構造が図6である。x86のようにBR/PCをALUと別に設けるという事をせず共用ポートにしているが、これを分離してもそこまでIPCは上がらないだろうし、エリアサイズに制限のあるMobile向けを考えれば妥当ではある（Register Fileの数を考えると焼け石に水という気もしなくはないが）。

図5：Integer/Vector共にRegisterが400以上というのはかなりすさまじい。ROBの数もそうだが、多数の命令をIn-Flightで保持する気満々である［クリックで拡大］ 出所：Qualcomm

図6：Reservation Stationがそれぞれ20 entryなのでこれだけで120命令を保持できる訳だ。Register Fileが400以上必要になるのも無理はない［クリックで拡大］ 出所：Qualcomm

　一方、VXUの構造が図7である。128bitというか、内部は64bit×2のエンジンが4つ並んでいる感じである。FPUの場合は片方だけが動き、NEONでは両方が動くという感じだろうか。サポートされる命令を見ると分かるように完全に同一構成ではないが、主要な命令は同時に4命令処理可能という感じになっている。

　先に書いたようにこれは2024年のMobile向けだから、SVE/SVE2には未対応だが、この構成なら小変更でSVE2への対応は可能になるだろう。もっとも、モバイル向けはともかくサーバ用途で512bit幅で足りるのか？という方が問題で、あるいは1024bit幅への拡張が行われているかもしれないが、その場合は次に説明するLSUの強化が当然必要な訳で、バランスを崩さずにこれが実現できるかはちょっと微妙なところだ。

図7：主要な命令は4つ全てのユニットで処理可能なので、NEONを利用したデータ処理はほぼ512bit/cycleで実行できると考えてよさそうだ［クリックで拡大］ 出所：Qualcomm