Arm TechCon 2019 - ArmがCustom Instructionの提供を決定した背景

Arm Custom Instructionの実装

10月8日から10月10日まで、サンノゼコンベンションセンター(SJCC)において「Arm TechCon 2019」が開催された。

先行してお届けした基調講演のレポートの冒頭でお伝えした「Arm Custom Instruction」であるが、取材を通して細かい話がいろいろと判ってきたので、どのようなものであるのかをご紹介したい。

そもそもCustom InstructionのメリットとしてArmが挙げているのは、Cortex-Mベンダー内で差別化を図るのに、Custom Instructionを利用できるという話であった。

会期3日目のPeter Greenhalgh氏(VP of Technology and Fellow, Arm)の基調講演の中で、その実例を示している。例えばモーターのベクトル制御をやるという場合に、細かくCPUからパラメータを与えるよりも、いっそベクトル制御をまとめて行うような専用回路を設けて、これに初期パラメータを一発与えて処理を行う、なんて形の使い方を想定しているという話である(Photo01)。

Photo01:実はArmのCTOを長らく務めてきたMike Muller氏が2019年9月末で引退、後任のCTO職はおかないそうで、Greenhalgh氏を含む複数のFellowがその役割を果たす形になっているそうだ

さてこのCustom命令であるが、いろいろ制約がある。具体的には、

拡張命令は最大16個。オペランドは、これまでThumb-2で予約されていたものが割り当てられる。
オペランドは3つまで。要するに、Op R1 R2、ないし、Op R1 R2 R3、のフォーマットのみが許される。

ここでオペランドには、レジスタ(および恐らく即値)の指定が可能であるが、アドレス指定などは不可。Op R1 R2フォーマットだとR1とR2のパラメータをもとに処理を行い、結果をR1に返す。Op R1 R2 R3ならR2とR3のパラメータをもとに処理を行い、結果をR1に返す。

拡張命令は、既存の実行ユニットとはIsolateされた形でインプリメントされる。そのため、例えば通常のCortex-Mのパイプラインに細工を施すような命令を実装することはできない。
命令のThroughput/Latencyには制約がない。そのため、例えば実行に100cycleを要するような命令も実装は可能。ただし当然これは全体のパフォーマンスに大きな影響を与える(例えば100cycleの命令の処理実行中にInterruptが入っても、命令を途中で中断する事はできない^(注1)ので、当然ISRへのDispatchがその分遅れることになる)。

要するに、命令Fetch→DispatchまでとWritebackに関しては既存の命令パイプラインをそのまま利用し、実行部だけ顧客(つまりCustom Instruction拡張機能付きのCortex-M33のIPを入手したMCUベンダー)が勝手に実装できる、という形に縛りを入れている訳だ。

ところで冒頭に「顧客の差別化のため」と説明したこのCustom Instructionであるが、本音はやっぱり「速やかにできるようにしないとRISC-Vにやられてしまう」(Senior Director, IoT/Embedded BusinessのThomas Ensergueix氏)という話であった。実情としてもそんなところだろう。

ちなみにこのCustom Instructionは現在はCortex-M33のみだが、2020年前半中にはCortex-M23でも対応する予定との事。ただし旧来のCortex-M0/M0+/3/4/7では対応予定は無いという話であった。またCortex-A/Rに関して言えば、Custom Instructionを提供する可能性はあるが、具体的に説明できるような話は無い、という含みを持たせたものだった。

ちょっと気になるのは、「よくCustom InstructionのためにOpCodeを空けたな」という点だろう。通常アーキテクチャを自前で実装しているベンダーは、未使用のOpCodeをあまり開放することを好まない。というのは、その分自身で将来拡張できる余地が減るからだ。ましてやCortex-Mの場合はThumb-2での実装のため、OpCodeにそれほど大量の空きがあるわけではない。にも拘わらず開放したというのは、要するにThumb-2にこれ以上拡張を行う計画がないからではないか？というのが筆者の邪推である。

というのは、Arm v8.1-Mにて、かなり命令拡張が進んでおり、これ以上増やすとするとそろそろ次のフォーマット(Thumb-3？)が必要になりそうな感じだからだ。逆に言えば、Thumb-3が予定されているからこそ、Thumb-2の未公開OpCodeを公開する決断が出来た、というのは邪推にすぎるだろうか？