Avis de l’éditeur : D’une manière générale, nous sommes de grands fans de RISC V. Il fait très bien certaines choses, gère assez bien beaucoup d’autres et a des signes clairs d’adoption et d’attrait. Il répond à un réel besoin du marché de manière innovante, exactement ce que nous aimons voir de notre technologie. Nous disons donc cela d’un point de vue amoureux – RISC V va avoir un gros problème logiciel. La bonne nouvelle est que cela n’a peut-être pas d’importance.
Tout d’abord, un peu de contexte. RISC V est une architecture de jeu d’instructions open source (ISA), une alternative “libre” à Arm. Les ISA fournissent un ensemble de “plans” communs, importants mais peu prestigieux pour les processeurs. Chaque processeur a besoin de ce qu’un ISA fournit pour faire des calculs de base. Leur conception et leur maintenance nécessitent beaucoup de travail, mais n’offrent pas beaucoup de différenciation du produit final, ce qui signifie que les sociétés de puces qui les utilisent voient un grand avantage à sous-traiter ce travail à un tiers comme Arm.
L’intérêt des processeurs est d’exécuter une forme de logiciel. Et même si l’ISA et le développeur de logiciels sont séparés de plusieurs couches, les ISA sont si fondamentaux pour les puces que les modifications apportées à un ISA créent de véritables problèmes logiciels.
Essayez de télécharger un langage de programmation populaire sur un nouveau MacBook alimenté par Apple M1 et vous constaterez probablement que le logiciel ne fonctionne pas sur le M1 ou nécessite une version bêta alternative. Ceci est en fait assez important car cela signifie que toute personne exécutant du code hérité doit subir des frictions importantes pour passer à un nouvel ISA.
Les ISA sont incroyablement collants, changer pour un nouveau est quelque chose que la plupart des sociétés de puces détestent faire. Par exemple, Qualcomm construit des puces basées sur Arm depuis des décennies, et même si Arm les poursuit, il est peu probable que Qualcomm déplace un jour ses produits de base vers RISC V, car cela rendrait tous les logiciels écrits pour les puces basées sur Qualcomm peu maniables. , sinon irréalisable. Nous ne voulons pas exagérer cela, changer n’est pas impossible, c’est juste difficile. Comme nous l’avons dit plus haut, c’est beaucoup de friction.
Source: Cadence
Cela aurait pu être un gros problème pour que RISC V soit adopté. Cependant, il est entré sur le marché à un moment presque parfait. Juste au moment où Arm est entré en hibernation dans les bras de Softbank et a perdu sa motivation pour attirer de nouveaux clients, les semi-démarrages ont recommencé à germer pour la première fois en une décennie. Cela inclut la croissance naissante des semi-démarrages américains et leur explosion absolue en Chine. Aucune de ces entreprises n’avait des décennies de dépendances héritées d’Arm et était heureuse d’opter pour la solution qui ne coûtait rien.
Mais il y a un problème avec tout cela. RISC V est open source, ce qui signifie que quiconque souhaite concevoir une puce RISC V a largement la possibilité d’apporter toutes sortes de modifications à son implémentation spécifique de l’ISA. Cela signifie que le RISC V de chacun est un peu différent. L’organisation RISC V a prévu ce problème et a défini un ensemble d’exigences de compatibilité, et bien que tout le monde veuille s’y conformer, il n’y a pas de véritable mécanisme d’application pour l’empêcher de se produire.
Cela signifie que la mise en œuvre des principaux concepteurs de puces RISC V autonomes tels que SiFive, Andes et CodaSIP peut être légèrement différente. Tout le monde se conforme complètement à toutes les règles, mais certaines personnes s’y conforment plus complètement. Et parmi les nombreuses grandes sociétés de puces avec des conceptions RISC V, qui sait ce qui se passe.
Cela signifie probablement qu’un logiciel écrit pour une puce RISC V ne fonctionnera pas sur une autre puce RISC V, ou du moins ne fonctionnera pas bien.
Il était une fois qui aurait été un bouchon de spectacle. Les années 1980 ont vu toute une guerre de systèmes d’exploitation dont l’issue dépendait très fortement des puces et des ISA sous-jacents. Ce type de problème logiciel aurait gravement entravé l’attrait de RISC V, en particulier pour certains des projets les plus ambitieux, tels que les processeurs pour serveurs. Mais cette fois ce sera différent. Il y a vraiment deux raisons pour lesquelles cette fragmentation logicielle RISC V peut ne pas avoir autant d’importance.
Premièrement, la façon dont nous utilisons les logiciels a changé. Les systèmes d’exploitation importent moins qu’avant à cause d’Internet et du cloud computing (ils importent toujours, mais pas de la même manière). Tant que ce processeur sous-jacent peut gérer le trafic Web de base, il y aura un moyen d’y exécuter des logiciels. Il y aura probablement des problèmes lors du portage de nombreuses applications logicielles courantes vers RISC V, et comme nous l’avons souvent noté, c’est le facteur qui a gardé Arm hors du centre de données, mais ce n’est qu’une petite partie du marché.
La deuxième raison pour laquelle cela n’a pas beaucoup d’importance est qu’une grande partie de ce pour quoi RISC V est utilisé ne repose pas sur un logiciel commun – il existe des centaines de puces RISC V conçues pour l’IoT, les applications industrielles et autres applications embarquées. Nous pensons RISC V viendra dominer ce marché. À moins que quelqu’un ne propose un système d’exploitation pour l’Internet des objets (IoT), il n’y a vraiment pas besoin d’une architecture de puce commune pour ces appareils. Et nous croyons fermement que il n’y aura jamais un système d’exploitation pour l’IoT.
Il est également tout à fait possible qu’un jour l’environnement logiciel de RISC V converge vers des solutions plus compatibles. Cela prendra des années et sera plein de sortes de problèmes – quelqu’un se souvient-il de l’incompatibilité du pilote de l’imprimante et du GPU ? – mais c’est encore probable.
À ce stade, RISC V semble imparable. C’est une bonne chose. Mais ce n’est pas une solution unique, et elle rencontrera sa part de difficultés de croissance, et nombre d’entre elles se produiront dans et autour de la compatibilité logicielle. Cela ne présente pas la même barrière qu’autrefois.
