Bof, tant qu'elles sont décrite ouvertement. à l'inverse dans le noyau Linux, l'extension RISC-V vectoriel 0.7 qui en était la première spécification, faite par tous les participants, n'a été produite que par T-Head, et c'était pendant 2 ou 3 ans le seul disponible de toute façon. Pour pas perdre cela ça a été passé comme extension T-Head, bien que ce soit les spécifications ouverte.
Voir toutes les extensions aujourd'hui gérée dans le noyau, la suite GNU, Qemu, l'émulateur RVVM (moins complet mais 3* plus performant que Qemu un tas d'implémentation pour FPGA, ou la variété disponiblle en ASIC, pour voir que ça n'est pas un si gros problème que ça. Pas plus que le nombre d'extension sur les autres architectures. GCC permet de passer des flags RV64GC (pour le général, utilisé dans Arch-RISC-V ou Debian RISC-V par ex. RV64GC est l'équivalent de RV64I(MAFD)C pour Integer, Mul/div entier, Flottant, Double et instruction Compressées sur 16bits), RV32I pour seulement les entiers en 32 bits etc, et compilera en fonction de l'architecture cible. Le standard n'étant pas encore mort, il va continuer à évoluer, avec, la nouvelle habitude de mettre l'année de la publication de la specification.
C'est ce qui s'est toujours passé dans toutes les architectures, et ça n'a jamais été un problème majeur. Le noyau se charge de détecter les extensions présentent et les utilise ou pas.
Par contre, le fait de pouvoir n'en sélectionner que quelques unes et un avantages pour réduire le nombre de portes et multiplier les cœurs à nombre de transistors équivalents.
[^] # Re: Unification de l'ISA mais fragmentation des microarchitectures
Posté par tao popus . En réponse à la dépêche Linus Torvalds: comment éviter que RISC-V ne reproduise les erreurs du passé?. Évalué à 1.
Bof, tant qu'elles sont décrite ouvertement. à l'inverse dans le noyau Linux, l'extension RISC-V vectoriel 0.7 qui en était la première spécification, faite par tous les participants, n'a été produite que par T-Head, et c'était pendant 2 ou 3 ans le seul disponible de toute façon. Pour pas perdre cela ça a été passé comme extension T-Head, bien que ce soit les spécifications ouverte.
Voir toutes les extensions aujourd'hui gérée dans le noyau, la suite GNU, Qemu, l'émulateur RVVM (moins complet mais 3* plus performant que Qemu un tas d'implémentation pour FPGA, ou la variété disponiblle en ASIC, pour voir que ça n'est pas un si gros problème que ça. Pas plus que le nombre d'extension sur les autres architectures. GCC permet de passer des flags RV64GC (pour le général, utilisé dans Arch-RISC-V ou Debian RISC-V par ex. RV64GC est l'équivalent de RV64I(MAFD)C pour Integer, Mul/div entier, Flottant, Double et instruction Compressées sur 16bits), RV32I pour seulement les entiers en 32 bits etc, et compilera en fonction de l'architecture cible. Le standard n'étant pas encore mort, il va continuer à évoluer, avec, la nouvelle habitude de mettre l'année de la publication de la specification.
C'est ce qui s'est toujours passé dans toutes les architectures, et ça n'a jamais été un problème majeur. Le noyau se charge de détecter les extensions présentent et les utilise ou pas.
Par contre, le fait de pouvoir n'en sélectionner que quelques unes et un avantages pour réduire le nombre de portes et multiplier les cœurs à nombre de transistors équivalents.