Découvrez comment la pensée RISC de David Patterson et la co-conception matériel–logiciel ont amélioré la performance par watt, façonné les CPU et influencé RISC-V aujourd’hui.
David Patterson est souvent présenté comme « un pionnier du RISC », mais son influence durable dépasse celle d’un seul design de CPU. Il a aidé à populariser une manière pragmatique de penser l’informatique : considérer la performance comme quelque chose que l’on peut mesurer, simplifier et améliorer de bout en bout — des instructions qu’une puce comprend jusqu’aux outils logiciels qui génèrent ces instructions.
RISC (Reduced Instruction Set Computing) est l’idée qu’un processeur peut fonctionner plus vite et de façon plus prévisible s’il se concentre sur un ensemble réduit d’instructions simples. Plutôt que d’implémenter en hardware un grand catalogue d’opérations compliquées, on rend les opérations courantes rapides, régulières et faciles à pipeline. Le gain n’est pas une « moindre capacité » : des blocs simples, exécutés efficacement, l’emportent souvent sur les charges de travail réelles.
Patterson a aussi défendu la co-conception matériel–logiciel : une boucle de rétroaction où architectes de puces, auteurs de compilateurs et concepteurs systèmes itèrent ensemble.
Si un processeur est conçu pour exécuter efficacement des motifs simples, les compilateurs peuvent produire ces motifs de manière fiable. Si les compilateurs montrent que les programmes réels passent du temps sur certaines opérations (comme l’accès mémoire), le matériel peut être ajusté pour mieux traiter ces cas. C’est pourquoi les discussions sur une architecture d’instructions (ISA) se relient naturellement aux optimisations du compilateur, au cache et au pipelining.
Vous comprendrez pourquoi les idées RISC se connectent à la performance par watt (pas seulement à la vitesse brute), comment la « prévisibilité » rend les CPU modernes et les puces mobiles plus efficaces, et comment ces principes apparaissent dans les appareils d’aujourd’hui — des ordinateurs portables aux serveurs cloud.
Si vous voulez une carte des concepts clés avant d’aller plus loin, passez à /blog/key-takeaways-and-next-steps.
Les premiers microprocesseurs étaient conçus sous fortes contraintes : les puces avaient peu d’espace pour les circuits, la mémoire était coûteuse et le stockage lent. Les concepteurs essayaient de livrer des ordinateurs abordables et « suffisamment rapides », souvent avec de petits caches (ou aucun), des fréquences modestes et une mémoire principale très limitée par rapport aux besoins des logiciels.
Une idée populaire à l’époque était que si le CPU proposait des instructions plus puissantes et de haut niveau — capables d’effectuer plusieurs étapes en une seule fois — les programmes s’exécuteraient plus rapidement et seraient plus faciles à écrire. Si une instruction pouvait « faire le travail de plusieurs », on pensait qu’il faudrait moins d’instructions au total, économisant temps et mémoire.
C’est l’intuition derrière de nombreux designs CISC (Complex Instruction Set Computing) : donner aux programmeurs et aux compilateurs une grande boîte à outils d’opérations sophistiquées.
Le problème était que les programmes réels (et les compilateurs qui les traduisent) n’exploitaient pas systématiquement cette complexité. Beaucoup des instructions les plus élaborées étaient rarement utilisées, tandis qu’un petit ensemble d’opérations simples — charger, stocker, additionner, comparer, brancher — revenait sans cesse.
Parallèlement, supporter un vaste menu d’instructions complexes rendait les CPU plus difficiles à construire et plus lents à optimiser. La complexité consommait de la surface de puce et des efforts de conception qui auraient pu être consacrés à rendre les opérations courantes prévisibles et rapides.
Le RISC a répondu à ce fossé : concentrer le CPU sur ce que le logiciel fait réellement le plus souvent, rendre ces chemins rapides — puis laisser les compilateurs faire davantage le travail d’« orchestration » de manière systématique.
Une façon simple de voir CISC vs RISC est de comparer des boîtes à outils.
CISC (Complex Instruction Set Computing) ressemble à un atelier rempli d’outils spécialisés et sophistiqués — chacun peut faire beaucoup en un seul geste. Une seule « instruction » peut charger des données, effectuer un calcul et stocker le résultat, le tout regroupé.
RISC (Reduced Instruction Set Computing) ressemble à une trousse plus réduite d’outils fiables que l’on utilise constamment — marteau, tournevis, mètre — et à construire tout à partir d’étapes répétables. Chaque instruction fait en général une petite tâche claire.
Quand les instructions sont plus simples et plus uniformes, le CPU peut les exécuter avec une chaîne de montage plus propre (un pipeline). Cette chaîne est plus facile à concevoir, à faire tourner à des fréquences plus élevées et à maintenir occupée.
Avec des instructions de style CISC « qui font beaucoup », le CPU doit souvent décoder et décomposer l’instruction complexe en étapes internes plus petites. Cela peut ajouter de la complexité et rendre plus difficile le maintien d’un pipeline fluide.
Le RISC vise une durée d’instruction prévisible — de nombreuses instructions prennent à peu près le même temps. La prévisibilité aide le CPU à planifier le travail efficacement et aide les compilateurs à générer du code qui nourrit le pipeline au lieu de le bloquer.
Le RISC nécessite généralement plus d’instructions pour accomplir la même tâche. Cela peut signifier :
Mais cela peut rester intéressant si chaque instruction est rapide, si le pipeline reste fluide et si la conception globale est plus simple.
En pratique, des compilateurs bien optimisés et une gestion efficace du cache peuvent compenser l’inconvénient des « instructions en plus » — et le CPU passera plus de temps à faire du travail utile et moins à démêler des instructions compliquées.
Berkeley RISC n’était pas seulement un nouvel ensemble d’instructions. C’était une attitude de recherche : ne partez pas de ce qui paraît élégant sur le papier — partez de ce que font réellement les programmes, puis façonnez le CPU autour de cette réalité.
Conceptuellement, l’équipe de Berkeley visait un cœur CPU assez simple pour tourner très vite et de façon prévisible. Plutôt que d’encombrer le hardware de nombreuses « astuces » d’instruction compliquées, ils s’appuyaient sur le compilateur pour faire plus de travail : choisir des instructions simples, bien les ordonnancer et garder les données dans les registres autant que possible.
Cette répartition des responsabilités comptait. Un cœur plus petit et plus propre est plus facile à pipeline efficacement, plus simple à raisonner et souvent plus performant par transistor. Le compilateur, qui voit l’ensemble du programme, peut planifier en avance d’une manière que le matériel ne peut pas faire facilement en temps réel.
David Patterson insistait sur la mesure parce que la conception d’ordinateurs est pleine de mythes tentants — des fonctionnalités qui semblent utiles mais apparaissent rarement dans le code réel. Berkeley RISC a poussé à utiliser des benchmarks et des traces de charges de travail pour trouver les chemins chauds : boucles, appels de fonction et accès mémoire qui dominent le temps d’exécution.
Cela renvoie directement au principe « rendre le cas fréquent rapide ». Si la plupart des instructions sont des opérations simples et des loads/stores, optimiser ces cas fréquents rapporte plus que d’accélérer des instructions complexes rares.
L’enseignement durable est que RISC a été à la fois une architecture et un état d’esprit : simplifier ce qui est fréquent, valider par les données et considérer le matériel et le logiciel comme un seul système que l’on peut accorder ensemble.
La co-conception matériel–logiciel signifie que vous ne concevez pas un CPU isolément. Vous concevez la puce et le compilateur (et parfois le système d’exploitation) en tenant compte l’un de l’autre, afin que les programmes réels tournent vite et efficacement — pas seulement des séquences d’instructions synthétiques « meilleures ».
La co-conception fonctionne comme une boucle d’ingénierie :
Choix d’ISA : l’architecture d’instructions (ISA) décide ce que le CPU peut exprimer facilement (par exemple, accès mémoire « load/store », beaucoup de registres, modes d’adressage simples).
Stratégies du compilateur : le compilateur s’adapte — garde les variables chaudes en registres, réordonne les instructions pour éviter les stalls, choisit des conventions d’appel qui réduisent les frais.
Résultats des charges de travail : vous mesurez des programmes réels (compilateurs, bases de données, graphiques, code OS) et voyez où le temps et l’énergie sont dépensés.
Conception suivante : vous ajustez l’ISA et la microarchitecture (profondeur du pipeline, nombre de registres, tailles de cache) en fonction de ces mesures.
Voici une petite boucle (C) qui illustre la relation :
for (int i = 0; i < n; i++)
sum += a[i];
Sur une ISA de style RISC, le compilateur garde typiquement sum et i dans les registres, utilise de simples instructions de load pour a[i], et effectue de la planification d’instructions pour que le CPU reste occupé pendant qu’un accès mémoire est en cours.
Si une puce ajoute des instructions complexes ou du matériel spécial que les compilateurs utilisent rarement, cette surface consomme quand même de l’énergie et demande des efforts de conception. Pendant ce temps, les choses « ennuyeuses » sur lesquelles les compilateurs comptent — suffisamment de registres, des pipelines prévisibles, des conventions d’appel efficaces — peuvent être sous-dimensionnées.
La pensée RISC de Patterson insistait pour dépenser le silicium là où le logiciel réel peut en tirer bénéfice.
Une idée clé du RISC était de rendre la « chaîne de montage » du CPU plus facile à maintenir occupée. Cette chaîne est le pipeline : au lieu de finir une instruction complètement avant de commencer la suivante, le processeur décompose le travail en étapes (fetch, decode, execute, write-back) et les chevauche. Quand tout s’enchaîne, on complète près d’une instruction par cycle — comme des voitures traversant une usine à plusieurs stations.
Les pipelines fonctionnent mieux quand chaque élément est similaire. Les instructions RISC ont été conçues pour être relativement uniformes et prévisibles (souvent de longueur fixe, avec un adressage simple). Cela réduit les « cas particuliers » où une instruction demande plus de temps ou des ressources inhabituelles.
Les programmes réels ne sont pas parfaitement lisses. Parfois une instruction dépend du résultat d’une précédente (on ne peut pas utiliser une valeur avant qu’elle soit calculée). Parfois le CPU attend des données depuis la mémoire, ou il ne connaît pas encore quel chemin une branche va prendre.
Ces situations provoquent des stalls — de courtes pauses où une partie du pipeline reste inerte. L’intuition est simple : les stalls arrivent quand l’étage suivant ne peut pas faire de travail utile parce que quelque chose dont il a besoin n’est pas arrivé.
C’est là que la co-conception matériel–logiciel se manifeste clairement. Si le matériel est prévisible, le compilateur peut aider en réarrangeant l’ordre des instructions (sans changer le sens du programme) pour combler les « trous ». Par exemple, en attendant la production d’une valeur, le compilateur peut placer une instruction indépendante qui n’en dépend pas.
Le gain est une responsabilité partagée : le CPU reste plus simple et rapide pour le cas courant, tandis que le compilateur fait davantage de planification. Ensemble, ils réduisent les stalls et augmentent le débit — souvent en améliorant les performances réelles sans nécessiter un jeu d’instructions plus complexe.
Un CPU peut exécuter des opérations simples en quelques cycles, mais récupérer des données depuis la mémoire principale (DRAM) peut prendre des centaines de cycles. Cet écart existe parce que la DRAM est physiquement plus éloignée, optimisée pour la capacité et le coût, et limitée par la latence (le temps d’une requête) et la bande passante (le nombre d’octets par seconde que l’on peut déplacer).
À mesure que les CPU s’accéléraient, la mémoire n’a pas suivi au même rythme — cet écart croissant s’appelle souvent le mur de la mémoire.
Les caches sont de petites mémoires rapides placées près du CPU pour éviter de payer la pénalité DRAM à chaque accès. Elles fonctionnent parce que les programmes réels ont de la localité :
Les puces modernes empilent les caches (L1, L2, L3), essayant de garder l’« ensemble de travail » du code et des données proche du cœur.
C’est ici que la co-conception matériel–logiciel montre tout son intérêt. L’ISA et le compilateur façonnent ensemble la pression sur le cache d’un programme.
En termes quotidiens, le mur de la mémoire explique pourquoi un CPU à haute fréquence peut quand même sembler lent : ouvrir une grosse application, exécuter une requête de base de données, faire défiler un fil ou traiter un gros jeu de données est souvent limité par les misses de cache et la bande passante mémoire — pas par la vitesse arithmétique brute.
Pendant longtemps, on parlait des CPU comme d’une course : la puce qui termine une tâche le plus vite « gagne ». Mais les ordinateurs réels vivent dans des limites physiques — capacité de batterie, chaleur, bruit des ventilateurs et factures d’électricité.
C’est pourquoi la performance par watt est devenue une métrique centrale : combien de travail utile obtient-on pour l’énergie dépensée.
Pensez-y comme à l’efficacité, pas à la force maximale. Deux processeurs peuvent sembler similaires dans l’usage quotidien, mais l’un peut le faire en consommant moins d’énergie, restant plus frais et tournant plus longtemps sur la même batterie.
Sur les portables et téléphones, cela affecte directement l’autonomie et le confort. Dans les centres de données, cela impacte le coût d’alimentation et de refroidissement de milliers de machines, plus la densité d’intégration possible sans surchauffe.
La pensée RISC a poussé la conception CPU à faire moins de choses en hardware, de manière plus prévisible. Un cœur plus simple peut réduire la consommation d’énergie de plusieurs façons liées :
L’idée n’est pas que « simple = toujours mieux ». C’est que la complexité a un coût énergétique, et qu’un ISA et une microarchitecture bien choisis peuvent échanger un peu d’astuce pour beaucoup d’efficacité.
Les téléphones tiennent à la batterie et à la chaleur ; les serveurs tiennent à l’alimentation et au refroidissement. Différents environnements, même leçon : la puce la plus rapide n’est pas toujours le meilleur ordinateur. Les gagnants sont souvent les architectures qui fournissent un débit stable tout en maîtrisant la consommation d’énergie.
RISC se résume souvent à « les instructions plus simples gagnent », mais la leçon durable est plus subtile : l’ISA compte, mais beaucoup de gains réels venaient de la façon dont les puces étaient implémentées, pas seulement de l’apparence de l’ISA sur le papier.
Les premiers arguments RISC laissaient entendre qu’un ISA plus propre et plus réduit rendrait automatiquement les ordinateurs plus rapides. En pratique, les plus grands gains venaient souvent de choix d’implémentation facilités par le RISC : décodage simplifié, pipelining plus profond, fréquences plus élevées et compilateurs capables d’ordonner mieux le travail.
C’est pourquoi deux CPU avec des ISA différentes peuvent finir surprenamment proches en performances si leur microarchitecture, tailles de caches, prédiction de branchement et procédé de fabrication diffèrent. L’ISA fixe les règles ; la microarchitecture joue le jeu.
Un changement clé de l’époque Patterson fut de concevoir à partir des données, pas des suppositions. Plutôt que d’ajouter des instructions parce qu’elles semblent utiles, les équipes mesuraient ce que faisaient les programmes et optimisaient le cas fréquent.
Cet état d’esprit surpassait souvent la conception « axée fonctionnalités », où la complexité croit plus vite que les bénéfices. Il rend aussi les compromis plus clairs : une instruction qui sauve quelques lignes de code peut coûter des cycles, de l’énergie ou de la surface de puce — et ces coûts apparaissent partout.
La pensée RISC n’a pas seulement façonné les « puces RISC ». Avec le temps, beaucoup de CPU CISC ont adopté des techniques internes de type RISC (par exemple, décomposer des instructions complexes en opérations internes plus simples) tout en conservant leur ISA.
Donc l’issue n’a pas été « RISC a battu CISC ». Ce fut une évolution vers des designs qui valorisent la mesure, la prévisibilité et une coordination étroite matériel–logiciel — indépendamment du logo de l’ISA.
RISC n’est pas resté au laboratoire. L’un des fils les plus clairs de la recherche à la pratique moderne va de MIPS à RISC-V — deux ISA qui ont fait de la simplicité et de la clarté une caractéristique, et non une contrainte.
MIPS est souvent retenu comme une ISA pédagogique, et pour de bonnes raisons : les règles sont faciles à expliquer, les formats d’instruction sont cohérents et le modèle load/store facilite le travail du compilateur.
Cette propreté n’était pas que théorique. Des processeurs MIPS ont été commercialisés pendant des années (stations de travail, systèmes embarqués), en partie parce qu’une ISA simple facilite la construction de pipelines rapides, des compilateurs prévisibles et des chaînes d’outils efficaces. Quand le comportement matériel est régulier, le logiciel peut s’en accommoder.
RISC-V a ravivé l’intérêt pour la pensée RISC en faisant un pas clé que MIPS n’a pas fait : c’est une ISA ouverte. Cela change les incitations. Universités, startups et grandes entreprises peuvent expérimenter, fabriquer du silicium et partager des outils sans négocier l’accès à l’ISA.
Pour la co-conception, cette ouverture compte parce que le côté « logiciel » (compilateurs, OS, runtimes) peut évoluer publiquement avec le côté « matériel », avec moins de barrières artificielles.
Autre raison pour laquelle RISC-V colle bien à la co-conception : son approche modulaire. On commence par une petite ISA de base, puis on ajoute des extensions pour des besoins spécifiques — calcul vectoriel, contraintes embarquées, sécurité, etc.
Cela favorise un meilleur compromis : au lieu de fourrer toutes les fonctionnalités dans un design monolithique, les équipes peuvent aligner les fonctions matérielles sur les logiciels qu’elles exécutent réellement.
Si vous voulez une introduction plus approfondie, voyez /blog/what-is-risc-v.
La co-conception n’est pas un simple épisode historique de l’ère RISC — c’est la manière dont l’informatique moderne continue de gagner en vitesse et en efficacité. L’idée clé reste dans l’esprit de Patterson : on ne gagne pas avec le seul matériel ni le seul logiciel. On gagne quand les deux s’ajustent à leurs forces et contraintes respectives.
Les smartphones et beaucoup d’appareils embarqués s’appuient fortement sur des principes RISC (souvent basés sur ARM) : instructions simples, exécution prévisible et forte priorité à la consommation d’énergie.
Cette prévisibilité aide les compilateurs à produire du code efficace et permet aux concepteurs de construire des cœurs qui consomment peu en navigation, mais peuvent monter en puissance pour le pipeline de la caméra ou un jeu.
Les ordinateurs portables et les serveurs poursuivent de plus en plus les mêmes objectifs — surtout la performance par watt. Même quand l’ISA n’est pas traditionnellement « RISC », beaucoup de choix internes visent une efficacité de type RISC : pipelining profond, exécution large et gestion agressive de la puissance adaptée au comportement logiciel réel.
GPU, accélérateurs IA (TPU/ NPU) et moteurs médias sont une forme pratique de co-conception : plutôt que de faire passer tout le travail par un CPU généraliste, la plateforme fournit du matériel adapté aux motifs de calcul courants.
Ce qui fait que c’est de la co-conception (et pas juste « du hardware en plus »), c’est la pile logicielle qui l’entoure :
Si le logiciel ne cible pas l’accélérateur, la vitesse théorique reste théorique.
Deux plateformes aux spécifications similaires peuvent donner des sensations très différentes parce que le « produit réel » inclut compilateurs, bibliothèques et frameworks. Une bibliothèque mathématique bien optimisée (BLAS), un bon JIT ou un compilateur plus malin peuvent apporter de gros gains sans changer la puce.
C’est pourquoi la conception CPU moderne est souvent guidée par les benchmarks : les équipes matérielles regardent ce que font réellement les compilateurs et les charges de travail, puis ajustent des fonctionnalités (caches, prédiction de branchement, instructions vectorielles, préfetching) pour accélérer le cas fréquent.
Quand vous évaluez une plateforme (téléphone, portable, serveur ou carte embarquée), recherchez des signaux de co-conception :
Le progrès informatique moderne tient moins à un seul « CPU plus rapide » qu’à un système matériel-plus-logiciel complet qui a été façonné — mesuré, puis conçu — autour de charges de travail réelles.
La pensée RISC et le message plus large de Patterson se résument en quelques leçons durables : simplifier ce qui doit être rapide, mesurer ce qui se passe réellement et traiter matériel et logiciel comme un seul système — parce que l’utilisateur vit l’expérience globale, pas les composants isolés.
D’abord, la simplicité est une stratégie, pas une esthétique. Une ISA propre et une exécution prévisible facilitent la génération de bon code par les compilateurs et l’exécution efficace de ce code par les CPU.
Ensuite, la mesure bat l’intuition. Faites des benchmarks avec des charges représentatives, collectez des profils et laissez les goulets d’étranglement réels guider les décisions — que vous ajustiez des optimisations de compilateur, choisissiez un SKU CPU ou refondiez un chemin critique.
Enfin, la co-conception est où les gains s’additionnent. Du code pipeline-friendly, des structures de données conscientes du cache et des objectifs réalistes de performance-par-watt livrent souvent plus de vitesse pratique que la poursuite d’un rendement théorique maximal.
Si vous choisissez une plateforme (x86, ARM ou systèmes basés RISC-V), évaluez-la comme vos utilisateurs :
Si une partie de votre travail consiste à transformer ces mesures en logiciel livré, il peut être utile de raccourcir la boucle build–measure. Par exemple, des équipes utilisent Koder.ai pour prototyper et faire évoluer des applications réelles via un flux de travail piloté par chat (web, backend et mobile), puis relancer les mêmes benchmarks de bout en bout après chaque changement. Des fonctionnalités comme le mode planification, les snapshots et le rollback soutiennent la même discipline « mesurer, puis concevoir » que prônait Patterson — appliquée au développement produit moderne.
Pour une introduction plus approfondie sur l’efficacité, voir /blog/performance-per-watt-basics. Si vous comparez des environnements et avez besoin d’un moyen simple d’estimer les compromis coût/performance, /pricing peut aider.
La leçon durable : les idées — simplicité, mesure et co-conception — continuent de rapporter, même si les implémentations évoluent des pipelines de l’ère MIPS vers des cœurs hétérogènes modernes et de nouvelles ISA comme RISC-V.
RISC (Reduced Instruction Set Computing) met l’accent sur un ensemble réduit d’instructions simples et régulières, faciles à pipeline et à optimiser. L’objectif n’est pas « moins de capacités », mais une exécution plus prévisible et efficace des opérations que les programmes utilisent le plus (chargements/stocks, opérations arithmétiques, branches).
CISC offre de nombreuses instructions complexes et spécialisées, parfois enchaînant plusieurs étapes en une seule. RISC utilise des blocs de construction plus simples (souvent modèle load/store + opérations ALU) et s’appuie davantage sur les compilateurs pour combiner ces blocs efficacement. Sur les CPU modernes, la frontière est floue : beaucoup de processeurs CISC traduisent leurs instructions complexes en micro-opérations internes plus simples.
Des instructions plus simples et plus uniformes facilitent la construction d’un pipeline fluide (une « chaîne de montage » pour l’exécution). Cela peut améliorer le débit (proche d’une instruction par cycle) et réduire le temps passé à gérer des cas particuliers, ce qui aide à la fois les performances et la consommation d’énergie.
Un ISA et un modèle d’exécution prévisibles permettent aux compilateurs de :
load/store)Cela réduit les bulles dans le pipeline et le travail gaspillé, améliorant les performances réelles sans ajouter de fonctions matérielles compliquées que le logiciel n’utilisera pas.
La co-conception matériel–logiciel est une boucle itérative où les choix d’ISA, les stratégies du compilateur et les mesures des charges de travail s’informent mutuellement. Plutôt que de concevoir un CPU isolément, on ajuste matériel, chaîne d’outils et parfois OS/runtime ensemble pour que les programmes réels tournent plus vite et plus efficacement.
Les stalls surviennent lorsque le pipeline ne peut pas avancer parce qu’il attend :
load manque le cache et attend la DRAMLa prévisibilité de type RISC aide matériel et compilateurs à réduire la fréquence et le coût de ces pauses.
Le « mur de la mémoire » est l’écart croissant entre l’exécution rapide du CPU et l’accès lent à la mémoire principale (DRAM). Les caches (L1/L2/L3) atténuent ce problème en exploitant la localité :
Pourtant, les misses de cache peuvent encore dominer le temps d’exécution, rendant beaucoup de programmes limités par la mémoire plutôt que par la vitesse du cœur.
C’est une mesure d’efficacité : combien de travail utile on obtient par unité d’énergie. Concrètement, elle affecte la durée de batterie, la chaleur, le bruit de ventilation et le coût d’alimentation et de refroidissement des centres de données. Les conceptions influencées par la pensée RISC cherchent souvent une exécution prévisible et moins d’activités inutiles, ce qui améliore le rapport performance/watt.
Beaucoup de CPU CISC ont adopté des techniques internes de type RISC (pipelining, micro-ops simples, caches, prédiction) tout en conservant leur ISA historique. Le « gain » réel n’a pas été la victoire d’un ISA sur l’autre, mais l’adoption d’un état d’esprit : mesurer les charges réelles, optimiser le cas fréquent et aligner matériel et logiciel.
RISC-V est une ISA ouverte avec une base réduite et des extensions modulaires, ce qui facilite la co-conception : équipes universitaires, startups et grandes entreprises peuvent expérimenter et faire évoluer matériel et outils publiquement. C’est une continuation moderne de l’approche « cœur simple + outils puissants + mesures » décrite dans l’article. Pour en savoir plus, voir /blog/what-is-risc-v.