/i/2004699844.png?fit=%2C&ssl=1)
RISC-V lui-même n’est pas une conception, mais une ISA (Instruction Set Architecture).
Par exemple, ARM fournit un ensemble assez complet de données pour construire un processeur. Par exemple, l’ISA sera corrigé pour une certaine génération de cœurs ARM, mais il existe également différentes conceptions de cœur qui peuvent être concédées sous licence et qui atteignent différents niveaux de performances. Les maisons de conception bien connues construisent des périphériques et des bus mémoire autour de lui, puis le SOC est prêt. Certains fabricants (Apple avec M1, mais aussi d’autres) ajustent encore plus les cœurs à leur propre discrétion.
Avec RISC-V, tout cela est beaucoup plus détendu. Le jeu d’instructions a plusieurs extensions distinctes et vous pouvez choisir ce dont vous avez besoin. Le minimum dont vous avez besoin est de pouvoir travailler avec des entiers 32 bits. Dans le jeu d’instructions, il reste même de la place dans les opcodes pour que vous puissiez ajouter vos propres instructions. La mise en œuvre du processeur tel que le pipeline, etc. n’est pas non plus établie et est également fournie par l’industrie/la communauté.
Cela présente certainement des avantages à certains égards. Si vous construisez votre propre conception ASIC ou FPGA, vous pouvez choisir de créer/d’octroyer une licence à une conception de cœur hautes performances qui inclut un superscalaire (traitement de plusieurs instructions à la fois), une exécution spéculative, plusieurs ALU, etc. Vous vous dirigez alors vers les performances des niveaux PC de bureau.
Mais vous pouvez également optimiser la taille. Cependant, dans la communauté open source, il existe également une implémentation dite “bit-serial” appelée SERV. Ce processeur est extrêmement petit en ce sens qu’il traite 1 bit d’une instruction 32 bits par cycle d’horloge. Une instruction d’addition de 2 nombres prend donc 32 cycles. Les processeurs réguliers le font en 1 cycle, et les processeurs avec plusieurs ALU peuvent atteindre un débit encore plus élevé.
Pourquoi voudrai-tu ceci? Parce que c’est possible. Le CPU est littéralement plusieurs centaines de bascules. Ainsi, 6000 cœurs SERV tiennent sur 1 grand FPGA. La performance est à pleurer, car 1 cœur de processeur a en fait besoin de 32 tics d’horloge par instruction.
Cependant, il y a toujours une utilisation légitime pour cela. Supposons que vous fassiez un ASIC qui a besoin d’un petit processeur pour mettre quelques bits au bon endroit au démarrage, et ne fait rien d’autre. Ensuite, vous pouvez le faire avec quelques centaines de bascules, et vous pouvez même ajuster le firmware plus tard.
Il y a quelques paragraphes, j’ai dit “dans un sens”, car je ne suis pas encore tout à fait convaincu que ce soit “l’approche” pour les développeurs de logiciels. Pour les développeurs de matériel, RISC-V est fantastique car il n’a pas encore été moulé. Cependant, plusieurs microcontrôleurs que j’ai vus sortir avec RISC-V jusqu’à présent ont souvent leurs propres versions de compilateur GCC (nécessaires) précisément parce qu’ils ajoutent leurs propres instructions au processeur. C’est une fonctionnalité classique de l’OpenSource où quelqu’un qui veut améliorer un logiciel mais qui n’aime pas la collaboration ou la direction du projet et crée son propre fork. Vous avez donc 2 logiciels qui font la même chose. Et est-ce souhaitable pour un compilateur qui devrait utiliser la même architecture ? Ou devons-nous vivre avec le fait que vous ne pouvez utiliser certaines extensions de jeu d’instructions «propriétaires» que si vous utilisez le fork de compilateur du fabricant (peut-être mal entretenu et très obsolète)?
Je n’aime pas non plus le fait qu’il n’est pas clair quel niveau de performance vous pouvez attendre de nombreuses puces. Un “noyau RISC-V” ne me dit pas à quelle vitesse il peut être, comme je viens de le décrire avec une implémentation superscalaire vs bit-série.
[Reactie gewijzigd door Hans1990 op 30 juli 2022 12:48]
