La révolution RISC-V (1/4) : l'Agence tous RISC

RISC-V. Vous avez probablement déjà vu cet acronyme dans certains de nos articles sans savoir précisément de quoi il s'agit. Et pourtant, RISC-V (prononcez « risque cinq ») est une technologie qui va prendre de l'importance et peut-être même remplacer certains noms connus, quitte à amener une quatrième transition dans les appareils Apple. Pour comprendre cette révolution en germe, nous avons décidé d'explorer de fond en comble le sujet à travers quatre articles. Cette première partie va être assez théorique, alors accrochez-vous.

La révolution RISC-V

1. L'Agence tous RISC : les origines et les avantages
2. Les Rangers du RISC : des puces largement employées
3. Qui veut jouer à RISC ? : test d'une carte de développement

Mais c'est quoi, RISC-V ?

RISC-V est un jeu d'instructions moderne, dont la conception a débuté en 2010. Commençons donc par expliquer ce qu'est un jeu d'instructions (ou ISA, pour Instruction Set Architecture). De façon assez simplifiée, il s'agit du langage du processeur, de l'ensemble des instructions qui peuvent être exécutées. Il en existe énormément mais les plus connus sont le x86 (conçu par Intel), l'ARM (imaginé par la société Arm), le PowerPC (IBM, Motorola et Apple) et le 68K (Motorola)¹. Il y en a bien d'autres, certains plus ou moins abandonnés — il y a peu de nouveautés du côté des 68K —, d'autres en constante évolution.

Un processeur standard ne comprend généralement qu'un seul jeu d'instructions, le sien. Un Apple M2 est compatible avec celui d'ARM et ne peut pas exécuter nativement celui d'Intel, le x86. De même, il va englober uniquement « sa » version, avec parfois quelques limites : les fonctions du M2 ne sont pas nécessairement les mêmes que celles du M1, par exemple.

AMX : l'arme secrète d'Apple pour accélérer les intelligences artificielles

Un des points qu'il faut bien comprendre, c'est qu'une ISA est rarement figée : avec le temps, de nouvelles instructions sont ajoutées pour prendre en compte des innovations, gérer des cas particuliers, etc. Le x86 original ne proposait que des instructions 16 bits, alors que la version actuelle est 64 bits, tout en gardant la compatibilité avec l'existant. Pratiquement chaque génération de processeurs x86 a greffé de nouvelles instructions, parfois éphémères… et parfois adoptées en masse, comme celles dédiées au 64 bits imaginées par AMD.

Un second point important vient du poids de l'existant et de la rétrocompatibilité. Dans beaucoup de cas, ceux qui développent un jeu d'instructions tentent de conserver une certaine rétrocompatibilité. Ce n'est pas systématique, mais une bonne partie des ISA actuelles repose sur des bases assez anciennes. Le x86 date de 1978 ; du code écrit pour le processeur Intel 8086 de l'époque fonctionne encore directement sur un Core de 13e génération, par exemple. De même, l'ARM a été imaginé en 1985 et il y a une rétrocompatibilité partielle sur le code existant. Elle n'est pas nécessairement présente, cela dit : les puces ARM d'Apple ne gèrent pas la partie 32 bits du jeu d'instructions.

Le problème de cette évolution, c'est que certains choix peuvent être datés et amener des contraintes ou des limites pratiques, pour des raisons de compatibilité. Le RISC-V, nous y arrivons, a l'avantage d'être assez moderne, de ne pas dépendre d'une ancienne architecture et de partir sur des bases saines. Il a aussi le mérite d'être open source.

Le RISC-V a commencé vers 2010 comme un projet porté par un enseignant visant à créer un jeu d'instructions avec des élèves à l'université de Californie, à Berkeley. Après l'arrivée de David Patterson, qui avait participé au début des années 1980 aux premiers travaux sur le RISC, le projet prend de l'ampleur. Comme il s'agit de la cinquième génération de projets liés aux architectures RISC, le projet gagne le nom de RISC-V.

Dès 2011, le jeu d'instructions est placé sous une licence open source et une fondation à but non lucratif est créée en 2015 pour gérer son évolution. Elle déménage des États-Unis vers la Suisse en 2019 et devient l'association RISC-V International. Ce changement de pays est lié aux différentes lois sécuritaires aux États-Unis et la nouvelle localisation a été choisie pour permettre d'éviter d'éventuelles restrictions sur les puces qui emploient l'ISA. Les membres de l'association gardent un peu de contrôle sur le jeu d'instructions et les marques, avec notamment la possibilité de participer aux évolutions et de voter pour l'inclusion de ces dernières, mais l'ensemble reste open source, avec une licence Creative Common.

RISC contre CISC, un combat d'arrière-garde

Parler de RISC (Reduced Instruction Set Computer) et de CISC (un rétronyme qui signifie Complex Instruction Set Computer) suscite toujours des débats, surtout sur un site dédié à Apple. Pour autant, quand on évoque RISC-V, c'est important. Dans l'imaginaire collectif, un processeur RISC est plus efficace et dispose de moins d'instructions, alors que les CISC, comme les x86, sont compliqués, lents, moins « beaux » d'un point de vue architectural.

Dans les faits, c'est nettement plus compliqué. Premièrement, le Reduced peut faire penser qu'il y a peu d'instructions, mais ce n'est pas réellement le cas. Les PowerPC, par exemple, ont parfois eu plus d'instructions que les x86. Deuxièmement, la majorité des CPU modernes fonctionne en « RISC » en interne, comme les processeurs x86 depuis une trentaine d'années. Même si le jeu d'instructions est CISC, l'exécution est en RISC : certaines instructions sont décodées en plusieurs micro-instructions pour optimiser l'efficacité.

En réalité, le Reduced est lié à la complexité des instructions. Dans les fondations du RISC, une instruction doit effectuer une tâche simple qui peut s'exécuter rapidement, alors que certaines instructions CISC peuvent prendre beaucoup de cycles. L'autre point majeur, c'est que les instructions RISC ont souvent une taille fixe de 32 bits². Cela peut paraître mineur, mais ça ne l'est pas : cela permet une bien meilleure optimisation des unités, et c'est d'ailleurs une des particularités qui permettent à Apple de proposer des CPU efficaces avec ses puces Mx ou Ax, qui sont compatibles ARM et donc RISC. Eh oui, le R de ARM signifie RISC.

En x86, la taille des instructions varie, ce qui complexifie énormément certaines unités dans le CPU et rend l'exécution en parallèle en interne plus compliquée. Ce choix n'est pas une erreur d'Intel : le x86 date de 1978, une époque où le moindre octet en mémoire avait de l'importance. Proposer des instructions plus courtes permettait de gagner de la place dans une mémoire restreinte. Le problème du CISC n'est pas réellement la philosophie choisie au départ, mais son héritage. Il reste que dans les faits, le décodage des instructions est complexe même si l'exécution elle-même se base sur du RISC en interne.

Prenons l'exemple des puces ARM et x86. Chez Apple, avec le M1 ou l'A14, qui sont fonctionnellement proches, la partie qui s'occupe de décoder les instructions (le décodeur) peut en gérer huit en parallèle, notamment parce que les instructions ARM ont une taille fixe. Chez Intel, c'est plus compliqué à cause de la longueur variable. Jusqu'à la 11e génération de Core, par exemple, le décodeur pouvait traiter quatre instructions en parallèle, mais avec trois unités pour les instructions « simples » (les plus utilisées) et une pour les complexes. Ce point pouvait limiter les performances : il s'agissait d'un compromis entre la fréquence des instructions complexes, rares, et les plus courantes. La donne a un peu changé avec les 12e et 13e générations³, mais le souci demeure le même : certaines instructions sont décodées moins rapidement, ce qui peut causer un goulet d'étranglement.

RISC-V est de façon évidente un jeu d'instructions RISC, avec des bases très « propres », c'est-à-dire sans contraintes de rétrocompatibilité. Il a été pensé pour un usage académique dans l'université qui avait défini les bases du RISC dans les années 1980, celles de Berkeley. Par rapport aux autres jeux d'instructions, il a l'avantage d'être simple (au moins pour la partie dédiée aux entiers), moderne et open source — on y reviendra.

Un choix philosophique et parfois pragmatique

Il est possible d'expliquer la philosophie sous-jacente de façon plus pragmatique avec une simple question : « quels sont les avantages des instructions que je pourrais ajouter ? » Si l'idée que vous voulez implémenter peut être réalisée avec des instructions plus simples, qu'elle implique des contraintes pour d'autres tâches ou que les gains réels sont trop faibles, il s'agit probablement d'une mauvaise idée. Il est par exemple plus intéressant d'utiliser les transistors nécessaires pour améliorer le CPU — ajouter de la mémoire cache, des décodeurs, des unités standards — que d'ajouter des instructions trop spécialisées ou trop complexes.

Bien évidemment, rien n'est gravé dans le marbre : dans certains cas, les avantages liés à l'ajout d'instructions sont suffisamment nombreux pour envisager de « complexifier » le CPU, ce qui nous amène aux extensions du jeu d'instructions RISC-V.

Un aspect intéressant de RISC-V vient des extensions. Dans une puce x86, les instructions sont nombreuses et il est parfois difficile de savoir ce que gère exactement un CPU, entre le SSE, l'AVX, les différentes implémentations d'AMD et Intel, etc. Dans le monde ARM, c'est similaire : il existe de nombreuses versions du jeu d'instructions et la présence de certaines instructions n'est pas obligatoire. De façon un peu caricaturale, la manière dont les puces ARM et x86 évoluent est incrémentale, c'est-à-dire que chaque nouveauté ajoute des instructions.

En RISC-V, l'ensemble est nettement plus rigide et propre : le jeu d'instructions est divisé en plusieurs extensions et le processeur renvoie ce qu'il prend en charge. Le SiFive U74 est par exemple noté RV64GC. Le RV64 indique qu'il s'agit d'un CPU 64 bits, le G qu'il est General Purpose et prend en compte le nécessaire pour un usage standard (ce qui inclut l'unité de calcul en virgule flottante, par exemple) et le C qu'il intègre la partie 16 bits destinée au monde de l'embarqué.

Le XuanTie C906, un autre CPU RISC-V courant, est un RV64GCV : il supporte les extensions vectorielles… en théorie. C'est un des problèmes liés à la jeunesse de RISC-V : ce CPU implémente le brouillon de la norme (0.7.1), mais pas directement la version finale. Il est donc possible de profiter des instructions, mais pas avec du code totalement standard. Les combinaisons sont nombreuses, comme le montre la page Wikipedia qui en liste une partie.

Actuellement, et en supposant que les concepteurs jouent le jeu, la méthode RISC-V est plus simple pour les développeurs, qui ne doivent pas se poser de questions comme « ce processeur prend en charge l'AVX-512… mais quelles instructions ? » Il devient aussi possible de proposer des puces très spécialisées comme celles de Micro Magic : si vous êtes certains que votre cible n'a besoin que des instructions 32 bits liées aux entiers, vous pouvez développer un CPU très adapté à vos besoins ou ceux de vos clients.

Pas de SIMD mais du vectoriel

Dans les puces x86 et ARM, des instructions ont pris beaucoup d'importance au fil du temps : celles liées au SIMD, pour Single Instruction Multiple Data. Les instructions de ce type permettent, en schématisant, de traiter plusieurs données avec une seule instruction. Si vous devez travailler sur une image avec des couleurs codées sur 16 bits, il est possible d'effectuer le même traitement sur quatre pixels avec une seule instruction, dans un registre 64 bits. Chez Intel, les premiers essais datent de la fin des années 1990 avec le MMX, et de nouvelles instructions ont été ajoutées régulièrement.

En RISC-V, ce type d'instructions n'existe pas : les créateurs ont préféré une extension vectorielle. C'est un choix moderne radical finalement assez logique. Dans les faits, l'AVX (Advanced Vector Extensions) existe chez Intel depuis quelques années maintenant (dès les Core de 2e génération) et est assez utilisé, même s'il nécessite une détection préalable de sa présence.

De loin, les instructions vectorielles peuvent sembler assez proches des instructions SIMD : elles permettent d'effectuer un traitement sur plusieurs données à la fois, placées dans un vecteur. Dans ce cas de figure, il faut le voir comme une zone de mémoire qui contient des données placées séquentiellement : un vecteur de 128 bits peut par exemple comporter huit valeurs codées sur 16 bits ou deux codées sur 64 bits, etc. Le but est bien évidemment d'effectuer les opérations sur tous les éléments du vecteur en une instruction… de la même manière qu'en SIMD. Mais il y a une différence importante, bien expliquée dans cette analyse de l'organisation ACM SIGARCH : dans le cas d'un CPU avec du SIMD, l'exécution elle-même peut être rapide, mais une partie du code pratique va consister à placer les données correctement dans les registres (une petite mémoire tampon, accessible directement par le CPU), ce qui peut être lent.

L'exemple a été probablement choisi pour montrer les limites du SIMD, néanmoins un jeu d'instructions vectoriel moderne et bien implémenté — pour rappel, beaucoup de puces RISC-V ne prennent pas en charge les extensions en question — permet d'obtenir des gains intéressants en simplifiant le code sans devoir augmenter de façon régulière la taille des registres. C'est en effet un des soucis d'Intel : la première version d'AVX (2008) est en 128 bits, la version 2 (2013) en 256 bits et la dernière, AVX-512, en 512 bits. Cette augmentation de la largeur, en plus de complexifier les puces, les ralentit : l'exécution de code AVX-512 tend à réduire les performances globales des CPU, notamment sur la fréquence, pour éviter les surchauffes.

Avec l'extension vectorielle, le résultat va dépendre de la longueur des registres vectoriels du CPU (256 ou 512 bits par exemple), avec la possibilité d'en grouper une partie pour certaines instructions. Dans un cas extrême, il devient possible de travailler sur un vecteur de 4 096 bits (8 registres de 512 bits) en une seule instruction. Ce choix, pour peu qu'il soit implémenté correctement, a donc des avantages pratiques évidents et est rendu en partie envisageable par l'absence de rétrocompatibilité.

Des bases modernes dans tous les cas

Un autre point important vient de l'absence d'instructions conditionnelles. Kézako ? Essayons de faire simple. Dans du code, certaines instructions vont dépendre du résultat d'autres instructions, par exemple dans une boucle. Imaginons un cas basique : une boucle avec un compteur qui part de zéro et s'incrémente à chaque exécution, avec la possibilité de sortir de la boucle quand la valeur 10 est atteinte. Dans du code x86 ou ARM classique, il existe des instructions qui permettent de gérer cette sortie quand la condition est atteinte.

Les instructions en question portent le nom d'instructions conditionnelles et leur existence est liée aux anciennes architectures de processeurs, qui ne possédaient pas de prédiction de branchement mais un pipeline. Attention, ça se complique : l'idée du pipeline est de précharger les instructions, en supposant qu'elles sont séquentielles. Si cette supposition est bonne, tout va bien : votre préchargement fonctionne et vous avez gagné en performances. Si elles ne le sont pas — par exemple une sortie d'une boucle pour sauter à une autre position dans le code —, le pipeline est vidé et repart de zéro, avec une forte pénalité sur les performances.

La prédiction de branchement, apparue dans les années 1990 dans les puces grand public, consiste à tenter de deviner (généralement avec succès) si une instruction va poser un souci, et à prédire la bonne branche à choisir entre deux cas. Avec RISC-V, les concepteurs partent du principe que le CPU contient une prédiction de branchement, ce qui rend caduques les instructions dédiées. Ce choix facilite l'exécution en parallèle tout en réduisant en partie la complexité de la puce. Plus largement, une bonne partie du code est prédictible et les instructions conditionnelles ralentissent l'exécution dans certains cas. Elles peuvent toutefois parfois aider si le code n'est pas du tout prédictible, mais ça demeure assez rare dans l'absolu.

Pour ceux que le code assembleur intéresse, un spécialiste montre quelques exemples de code ARM, x86 et RISC-V. Mais dans les faits, le constat est assez simple : en partant du principe que le CPU a une prédiction de branchement efficace, le compromis qui consiste à ne pas proposer d'instructions conditionnelles reste intéressant et a des avantages pratiques évidents pour améliorer l'exécution en parallèle. Ce choix n'est pas spécifique à RISC-V : l'ARMv8 (la variante 64 bits d'ARM) ne possède pas non plus d'instructions de ce type, contrairement aux itérations précédentes.

La gestion de la consommation

Dans un sens, le jeu d'instructions RISC-V est pensé pour une consommation faible, alors que dans le cas des puces ARM, il s'agit en partie d'une conséquence. Dans les faits, le premier ARM a été pensé pour un ordinateur de bureau⁴ et la consommation faible était un avantage intéressant mais pas nécessairement voulu. Avec le temps, cet avantage a permis l'émergence des puces ARM dans les appareils mobiles et le côté « basse consommation » a donc toujours été mis en avant dans les différentes architectures.

Avec RISC-V, certains choix dans les instructions font que l'ensemble a été pensé avec cette idée en tête. Une extension permet l'utilisation d'instructions compressées, prévues pour les appareils avec peu de mémoire et une puissance de calcul faible, tout en gardant la compatibilité avec le code classique. Et la structure des instructions fait que les puces sont plus simples sur certaines parties, ce qui autorise in fine la production de puces qui consomment très peu assez facilement, même si ce n'est pas nécessairement le but de toutes les architectures compatibles RISC-V. Si nous prenons le cas des puces ARM, les instructions dédiées au monde de l'embarqué (nommées Thumb) sont différentes de celles du jeu d'instructions classique et ne sont pas supportées sur toutes les variantes, alors que la prise en charge de l'extension en question en RISC-V est quasi systématique.

D'une façon plus générale, la philosophie du jeu d'instructions et les choix des concepteurs font qu'il est plus simple de créer un CPU qui consomme très peu d'énergie. Attention, il faut bien prendre cette caractéristique pour ce qui est, sans extrapoler : une consommation faible n'implique pas nécessairement un excellent rapport performances/consommation ni de bonnes performances. C'est ce que nous vous expliquerons notamment dans l'article suivant.