実装面での分断化はお互い様
命令セットの分断化はむしろArmのほうがひどい
(3)もかなり言いがかりであって、ベンダーが異なっていてもRISC-V ISAをきちんとサポートしている限りは、命令セット面からの分断化(Fragmentation)は「原理的に」起きないし、実装面での分断化はどちらでも起き得る。
Armも例外ではない。2011年のことだが、Linus Torvalds氏が増え続けるARMのサポートに苦言を呈した(というかブチ切れた)。
当時はすでにCortex-A8やA9がリリースされていたが、ターゲットとなったのはその前のARM11ベースのSoCである。これらのLinuxサポートが2011年頃に大挙して行なわれたのだが、当時のARM11ベースのSoCはメーカーごと、下手をすると同一メーカーでも製品ごとに実装がまちまちで、初期化ロジックや周辺回路のアクセス方法、メモリーマッピングなどが全部異なっており、しかもそれを画一的に扱う方法がなかった。
結果、その製品専用のデバイスドライバーをカーネルに組み込む形になり、これをLinuxカーネルのコードに取り混ぜたため、x86向けのコードが5000ほど組み込まれる間にARM用のコードが7万あまり(しかもほとんどがその特定製品向けのデバイスドライバーの追加)という事態になったことが理由である。これも立派な分断化である。
Armの側に立った言い方をすれば、そういう苦い経験があったからこそCortex-M向けにはCMSIS(Cortex Microcontroller Software Interface Standard)が用意され、Cortex-A向けにもCMSIS-Coreなどが提供されるようになり、現在はHAL(Hardware Abstraction Layer)が提供されてこのあたりの問題は解決している。
一方2018年の段階ではRISC-Vにはこうした仕組みが提供されていなかったの、言いたくなる気持ちもわからなくはない。ただ命令セットそのものの分断化はArmの方がひどい。
ARMv7はお世辞にもキレイな命令セットではないし、ARMv8は32bitと64bitでまったく異なる。Cortex-M系はThumb2のみの実行が可能なので、Arm v7までの32bit ARM命令も実行できない。また拡張命令もVFP/DSP/NEON/SVEとまったくバラバラである。
ついでに言えば、現在ではRISC-VもRISC-V Processor ProfileやRVM-CSI(RISV-V Common Software Interface)など、ハードウェアの違いを吸収してくれる互換レイヤーの構築が進んでおり、ARM11の時代の混乱をそのまま再現することなく普及が進みそうなので、この点ではArmの言うことはあまり当てはまらない。
この手の話の場合、先行者の苦労を後発者は見ながら発展していくので、とても苦労した先行者の立場にあるArmが、そうしたノウハウをちゃっかり手に入れている後発者のRISC-Vに一言いいたくなる気持ちはわかる。
セキュリティはRISC-Vもしっかりしている
(4)はさすがにイチャモンである。もちろんArmは以前からTrust Zoneに代表されるセキュア向けソリューション(あまり目立たないが、クレジットカードなどに代表されるスマートカード向けにSC000というプロセッサーなど)を提供しているし、最近ではSecure Enclaveの提供も始まっている。またArmv8.3-AではPAC(Pointer Authentication Core:ポインター認証)の機能も追加されるなど、いろいろ対策が進んでいる。
RISC-Vにはそうした対応がないわけではないし、またスマートカード向けはともかくセキュア・エレメント向けにすでに採用事例が複数存在する。さすがに最近のセキュリティ動向はRISC-Vベンダーもきちんと把握しており、今さらセキュリティの対策のないコアを大量に発売したりはしない。そもそもRISC-V ISAの中にセキュリティの要素も含まれているので、これを無視した実装にでもしない限り、Armの言うようなことは発生し得ない。
週刊アスキーの最新情報を購読しよう
