こうした動向を受けてかRedmond氏の基調講演では、2025年までに累積で800億個のRISC-Vコアが市場に投入される、という強気な数字が語られている（図1）。もっともArmは昨年のArm DevSummitの基調講演の中で、既に2000億個のArmコアが市場出荷されているという数字が出ているから、これに比べればまだ少ないという見方もできなくはないが、Armは30年掛けて2000億個であり、一方RISC-Vは6年で800億個の予定なのだから、この勢いは無視できないものである。

図1　あくまでもこの数字は推定なので、本当にここまで伸びるか？はまだ分からないのだが

　もっとも、何もしなくてもここまで伸びるか？ というとそれは疑問である。以前から筆者は「今のRISC-Vは、2003年ごろのARM（まだ当時はArmではなくARM）に近い」と何度か言及しており、この考えは現在も変わらない。何が問題か？ というと、古いARM（～ARM11コア）ベースのSoCを触ったことがある方ならご存じなのだが、デバイス初期化とか割り込み周りやDMAの設定、周辺回路のアクセスなどがメーカー別どころか下手をすると同一メーカーでも製品別に全然違っており、ミドルウェアの構築とかOS/RTOSのサポートなどが極端に大変（製品別のサポートが必要）という問題があった。

　実はこの問題、結構尾を引いている。2011年にLinus Torvalds氏がブチ切れた（*1）のは、余りにARMベースのSoCの構成に統一性が無さすぎ、なので機種別の初期化コードを全部Linux Kernelにブチ込んだ結果、Linux kernel v2.6.38とv2.6.39のarch/ディレクトリの差分を取ったら6割がARM向けだった、というのがその発端である。これは最終的にARM11ベースのSoCがCortex-Aに置き換えられていく中で解決していったのだが、MCU向けも問題は同じであった。

（*1）Linus Torvalds氏がブチ切れるのはまぁ良くあることだったから、それほど大きな問題ではない、という見方も当然ある。

　Armはこの問題を、Cortex-Mの投入に合わせて導入したCMSIS（Common Microcontroller Software Interface Standard）で解決した。Common “Microcontroller”と書いてはあるが、実際にはCortex-MのみならずCortex-A5/A7/A9もCMSISのサポート対象になっている。なので半導体ベンダーはCortex-AなりCortex-Mを利用してSoCを構築する際にCMSISに準拠するようなAPIを提供し、一方OSあるいはミドルウェアはCMSISに準拠する形で初期化ルーチンや機種依存部を記述する事で、大幅に互換性が向上することになった。

　一方でCortex-Aを利用する（つまりCortex-A9以降に登場した）SoCの場合、Appleを除くと基本Androidが動作する事が必要と考えられ、そのAndroidのHALがCMSISの代わり（いやむしろCMSISがAndroidのHALの代替というべきなのか？）を果たすことで互換性が保たれることになった。こうした標準が存在しなかったのがサーバ向けのSoCであるが、これについてもまず2014年にSBSA（Server Base System Architecture）が公開されて、Armベースサーバを構築するための最低限のインフラが整えられた。これに続き2018年にはServerReadyと呼ばれる、SBSAの上にファームウェアや認証まで含めてパッケージ化されたインフラが提供開始される。2020年にはこれをもう広い範囲に含めたSystemReadyが提供開始されている。

　RISC-Vに欠けているのは、まさしくこうしたインフラである。単に命令セットが共通、というだけでは異なるSoC間の互換性を取るには十分ではなく、互換性がないとミドルウェアやOSなどのインフラの普及が遅れることになる。

　問題はこうした互換性を取るための仕組みのイニシアティブを誰が取るか？ という話である。Armエコシステムの場合は話が簡単で、Arm以外にこれを取れる組織は存在せず、そしてArmがイニシアティブを取って（もちろんその際にArm単独という訳ではなく、関係する企業を巻き込みながら）仕様を策定した訳だが、RISC-VではArmの様な独占的にIPを提供する企業は存在しない。仮に例えばSiFiveがそうした仕様を定めたとして、他のメーカーがこれに協賛して利用するか？と言えば非常に怪しい。こうした事が可能なのはRISC-V Internationalしかないわけだが、昨年まではそうした動きが（水面下はともかく）表面には出てこなかった。