やはり目立つ「モバイル向け仕様」

　Load/Storeユニットの構成が図8である。この辺もMobile向けの感じが明確である。まずL1の容量からしてInstructionの方が大きい辺りで、大量のデータを処理するのではなく、プログラムを高速に処理する事を前提に構成されていると考えられる。それはそれとして、L1とL2は64Byte/cycle（512bit/cycle）で接続されており、NEONがフルに動いてもちゃんと格納できる帯域は用意されている事が分かる。ただLoad QueueがStore Queueの3.5倍、というあたりで書き出しより読み込みを重視しており、またL2からInterconnectへの帯域は半分の32Bytes/cycleに減ってるあたりは、連続して大量のデータ処理を行う事は想定していない事が分かる。これは細かい特徴（図9）を見ても言えることで、Prefetchingがかなり強化されているあたり、読み込み性能を重視した構成になっている事が分かる。

図8：L2が12MBと大容量な理由は後述［クリックで拡大］ 出所：Qualcomm

図9：dTLBが7-wayの224entryという構成はかなり珍しい。どうしてこういう構成になったのかが興味あるところだ［クリックで拡大］ 出所：Qualcomm

　ただ面白いのは、キャッシュ容量とかQueueの大きさはそんな訳でMobile向けに特化させた構造になっていながら、例えばTLBが1cycleでアクセスできるとか、複数のページサイズのサポート、仮想化環境のサポートなどはサーバ向けと同等の構成になっているし（図10）、セキュリティ周り（図11）のPointer AuthenticationやBranch Target IDなどの機能はArm v9.2-Aで採用されているものに近いように思われる。この辺はClient向けの枠を超えて、当初からServer向けの用途を考慮して作り込まれているように思える。

図10：最後のMultiple outstanding Table WalksはUnified L2-TLBに絡む話と思われる。これも後述［クリックで拡大］ 出所：Qualcomm

図11：ただArm v9.2-aそのもののSecurity機能（CCAとかMTEなど）と、どこまできちんと互換性があるのかは不明［クリックで拡大］ 出所：Qualcomm

　さてそんなOryonだが、2024年に発表されたものは第1世代でMobile向けに特化した構造である。このため、4つのコアで一つのClusterを構成し、おのおののCluster当たり12MBのL2を持つという構造になっている（図12）。先程L2が12MBと大容量だったのは4コア共有だからであり、コア当たりで言えば3MBとまぁ妥当な数字ではある。またTable Walkerの話が図10で出ていたが、恐らくL1だけでなくL2領域もコアごとにTable Walkerで独立してアクセスできる構造になっているのだろう。

図12：ちなみに製造プロセスは4nmと発表されている［クリックで拡大］ 出所：Qualcomm