ロードマップでわかる！当世プロセッサー事情

第895回

IBM ZがArmを取り込む衝撃！ 次世代メインフレーム「z18（仮）」のネイティブDual-ISA戦略の狙い

Arm v9.3-Aのネイティブ実装とデコーダー・分岐予測の大規模改修

　さて肝心のArmアーキテクチャーの話だ。これはz18(仮)に限らず昨今のプロセッサーはみんな同じであるが、もう命令セットをそのまま解釈するのではなく、デコーダーで内部命令(MicroOp)に変換し、そのMicroOpを共通のバックエンドでぶん回すという構造になっているので、理屈上はデコーダーががんばれば複数の命令セットをサポートするのは難しくない。

　古いところで言えばAMDのAm29000とK5がそうだし、その後のZenとK12や、富士通のSPARC XIfxと富岳に採用されたA64FXもそうで、どれもデコード部(というか命令セット)は異なるが、バックエンドは共通である。ただ「同時に複数の命令をサポート」というのはわりと珍しい。

　まともに完成しなかったものまで含めれば、MCST(Moscow Center of SPARC Technologies)のElbrus 2000(VILWベースのアーキテクチャーで、独自ISAとx86の両対応だが、x86はDynamic Translationを採用していた)があるが、これは例外というかキワモノに属する。

　これに対してz18(仮)では、Armからアーキテクチャーライセンスを取得し、きちんとAArch64 v9.3(Arm v9.3-A)を実装したことが明らかにされた。

Endianの違いまで吸収してるのだから壮絶である。それにしてもArch64命令が2792個もあったとは！

　ここでも明らかになっているが、アーキテクチャーが"CISC Mainframe DNA"というのは、バックエンドは従来のzシリーズのプロセッサーそのもので、そこは大きな変更はない(小変更はいろいろありそうだが)ということになる。

　また"Arm SystemReady compliant"というのは、Armベースのサーバー向けのOSやミドルウェア、アプリケーションがそのまま動作するので、おそらくはArm v9.3-AのUser Mode InstructionだけでなくSystem Mode Instructionもすべて実装されているように思える。これに関しては質疑応答で多く確認の質問が出たが、IBMからの回答はなかった。

　気になるのはもともとzに搭載されていた信頼性関連の機能、例えばcheckpoint/recoveryの機能(システムの動作状況や制御情報をcheckpointの時点で記録しておき、その後なにか障害が発生した際にはcheckpointの機能からやり直しをできるというもの)がArm環境で動作するか？　というあたりで、これは製品発表にあわせて情報が公開されるであろう。

　そもそもどうz命令のプログラム環境とArm命令のプログラム環境が共存するかは、最後に説明がある。あるいはChekipointなどの信頼性関連はこの環境側でサポートするのかもしれない。

　下の画像がそのz18(仮)のコアの詳細である。理屈で言えばデコードだけ作り替えれば可能とは言っても、例えば分岐予測は当然命令セットにあわせて最適化する必要があるし、フェッチも当然命令境界が異なるため、それぞれにあわせて最適化する必要があるなど、決して簡単ではない。

　Branch Prediction/Fetch/Decodeに関しては、結構な大工事になったのではないかと思われる。特にデコードは2792もの新命令をサポートし、さらに239ものAArch64専用レジスターを解釈する必要があるので、相当に大変だったのではないかと思われる。

　ただDispatch以降に関して言えばMicroOpベースでの実装になるから、ここは大きな変更はないようで、実際Dispatch and Issueもほぼ再利用できる(GR16～31のRenamingのみ必要)だし、Arithmetic and Load-Storeも基本は再利用可能で、SVEでの制御、それとFP16/BF16のサポートが追加になった程度の変更で済んでいる。もっとも講演の中では、Translation Buffer向けに新しいTable Walkの実装が必要になったという話もあり、そう簡単ではなかったようだ。

　SVE/SVE2については、もともとzシリーズは128bit幅のSIMDエンジンをコア内に搭載しているので、SVE/SVE2も原則的にはこれをそのまま使う形になっているようだ(SVE/SVE2に対応する制御を追加する必要はあったようだが)。

　興味深いのは、Zのトランザクション命令の実装である。CryptoやGZIP、あるいはOn ChipのAIアクセラレーターなどは、Zの側では専用命令が用意されている。ところがArmの場合は(アーキテクチャーライセンスがあっても)勝手に専用命令を追加できない。

　そこでどうしたか？　というと、仮想的にCryptoデバイスやGZIPデバイスなどを作成し、Arm命令からはこうした仮想デバイスをアクセスすることで、同じ処理が可能なように配慮されたそうだ。

z ISAを使った場合も、Armからデバイスアクセスの形で実行した場合も同等レベル(Comparable)なレイテンシーで実行できるとしている

　ところで先程触れた両環境の共存が下の画像である。Logical Partitionを利用して3種類の環境が共存し、それを共通のプロセッサーで同時に処理する形になる。したがって、1つの環境からZとArmの両方の命令が発行されるという事態にはならない模様だ。

z命令のプログラム環境とArm命令のプログラム環境の共存。ただLinuxONEでもこのKVM環境が提供されるのかはまだ不明である。あるいはLinuxONEでは引き続きZ ISAだけの可能性もあるし、あるいはLinuxONE for ZとLinuxONE for Armの2種類が湧いてくる可能性もありそうだ