Journal Raspberry-Pi entre dans la fondation Risc-V

Posté par (page perso) . Licence CC by-sa.
14
9
jan.
2019

Cher journal,

Pour faire suite à la dépêche sur l'année de la libération des microprocesseurs, voici une nouvelle petite information concernant le jeux d'instructions libre RISC-V : Raspberry-Pi entre dans la fondation RISC-V.

La prochaine raspberry-pi sera-t-elle à base de Risc-V ?

Voila une info qui boostera peut-être la liberté des processeurs. Peut-être que l'année 2019 sera celle du RISC-V sur le desktop, à moins que ça soit dans le salon car on voit plus souvent la Raspberry-Pi dans le salon que dans le bureau.

  • # conclusion peu convaincante du journaliste

    Posté par . Évalué à 7 (+5/-0).

    La prochaine raspberry-pi sera-t-elle à base de Risc-V ?

    Je pense que le journaliste prend ses désirs pour des réalités. Normalement ça va être du Broadcom et très certainement en ARM. Le Videocore 5 est très attendu des framboisiers depuis des années donc les prochaines cartes ne seront fort probablement pas Risc-V

    Pour moi, ça ressemble davantage à un effet d'annonce pour "motiver" leur fabricant exclusif (Broadcom).
    C'est le même principe que Apple qui laisse planer le doute sur son passage à ARM pour ses laptop pour pouvoir avoir une meilleure offre de la part d'Intel. Quand un gros client envisage de voir ailleurs, tu essaies de le garder. À moyen terme, soi Broadcom se mettra à faire du Risc-V soi RPi trouvera un autre fabricant mais pour l'instant les SoC Risc-V ne correspondent pas aux besoins du produit (que ce soit en terme de prix ou de fonctionnalités)

    Les questions que je me pose sont plutôt de savoir si le SoC Broadcom de la RPi 4 aura une architecture bIG.Little comme ce qu'on voit arriver chez les cartes concurrentes et si le Videocore 5 sera enfin un esclave du processeur plutôt que le chef d'orchestre du système comme son actuel prédécesseur.

    • [^] # Re: conclusion peu convaincante du journaliste

      Posté par . Évalué à 3 (+2/-0).

      Je pense que le journaliste prend ses désirs pour des réalités.
      Ca tombe bien, il n'y a pas de journalistes :D

      Ensuite je pense que tu as lu ce que tu voulais lire car. Il n'a pas dis que la prochaine génération de RPI serait du RISC-V. Il a posé la question… de manière un peu ironique. Disons que cela laisse pensé que dans un avenir plus ou moins lointain cela pourrait être le cas. Et cela fais sens. Raspberry PI intéresse beaucoup de libriste, RISC-V n'est pour le moment pas un processeur destiné a de grosse performances en calcul tout en en ayant l'ambition à termes. Enfin une carte est idéal pour tester un nouveaux processeur et l'éprouver. le premier produit grand public RISC-V a de grande chance d'être de ce type.

      Mais évidemment qu'il y a une trop grosse communauté adapté à ARM pour basculer demain. Dans tous les cas cela sera une gamme de produit. Il y a le mini, il y aurait le RISC-V.

      • [^] # Re: conclusion peu convaincante du journaliste

        Posté par . Évalué à 1 (+0/-1).

        Ca tombe bien, il n'y a pas de journalistes :D […] Il a posé la question… de manière un peu ironique.

        Je ne parle pas de martoni mais de Gareth Halfacree, le journaliste qui a écrit l'article lié dans ce journal.

        le premier produit grand public RISC-V a de grande chance d'être de ce type.

        Le premier produit grand public RISC-V sera plus probablement un disque dur multimédia de chez Western Digital et restera quasi-intégralement fermé. Tout ça j'en ai déjà parlé sous le précédent journal.

      • [^] # Re: conclusion peu convaincante du journaliste

        Posté par . Évalué à 3 (+4/-0). Dernière modification le 10/01/19 à 18:30.

        RISC-V n'est pour le moment pas un processeur destiné a de grosse performances en calcul tout en en ayant l'ambition à termes.

        Attention, comme Martoni le rappelait avec justesse dans sa dépêche titrée 2018, l’année de la libération des processeurs ?, je le cite : « le RISC-V, pour Reduced Instructions Set Computing version V, n’est pas un microprocesseur. C’est une définition du jeu d’instructions ainsi que des registres internes du processeur. […] Libre aux fondeurs de développer leurs architectures de processeur compatible RISC-V ».

        Je me doute bien que tu en as conscience, mais il est préférable d'utiliser les bons termes.

    • [^] # Re: conclusion peu convaincante du journaliste

      Posté par . Évalué à 2 (+1/-1).

      a mon avis tu te plante complétement, le but de RPI n'est pas d'augmenter les dividendes de leur actionnaires mais que l'informatique deviennent de nouveau facile pour des jeunes pas trop idiot et pas trop riche afin de faire des bricolages comme au temps de l'amiga et minitel.

      si risc-V correspond bien a ce besoin ils y passeront, je pense qu'il vont y passer au vue du tuning possible du proc possible et de l’arrêt de devoir gérer des bloatwares sur leur PI

      • [^] # Re: conclusion peu convaincante du journaliste

        Posté par . Évalué à 4 (+2/-0).

        le but de RPI n'est pas d'augmenter les dividendes de leur actionnaires

        Oui et ça n'empèche pas de vouloir pousser au cul leur fournisseur historique. Ce sont les seules cartes de cette gamme à rester en DDR2 (à l'heure où la concurrence commence à passer à la DDR4) et les seules à imposer l'usage d'une carte SD pour le boot.

        Contrairement à d'autres fabricants de SoC ARM comme Qualcomm, Mediatek, Allwinner, Nvidia, Marvell et NXP, Broadcomm n'est pas membre de la fondation RISC-V.

        si risc-V correspond bien a ce besoin ils y passeront

        C'est exactement ce que j'ai écrit. Sauf que RISC-V est encore très cher dû à sa jeunesse et pour l'instant il n'y a aucun SoC qui correspond aux besoins du RPi notamment concernant l'affichage graphique.
        Pour moi, c'est trop tôt pour que eux puissent passer à RISC-V et à la fois dans deux ans quand des SoC intéressants pour eux sortiront ce sera trop tard pour la fenêtre de sortie d'un RPi 4.

        Pour le RPi 5 je ne dis pas mais pour le 4 c'est très peu probable.

  • # Le rêve

    Posté par (page perso) . Évalué à 1 (+0/-0).

    ARM c'est bien, mais c'est pas aussi ouvert que RISC-V qui lui est 100% opensource. Il faut que le RISC-V se déploie à grande échelle :)

    l'azerty est ce que subversion est aux SCMs

    • [^] # Re: Le rêve

      Posté par . Évalué à 3 (+1/-0).

      RISC-V c'est bien, mouis, c'est à peu de chose près un clone du MIPS, ISA qui ne date pas d'hier..
      Et d'ailleurs MIPS va devenir opensource..

      Le RISC-V n'apporte rien coté sécurité par exemple, un CPU comme https://forwardcom.info/ ça aurait quand même + d'intérêt.

      • [^] # Re: Le rêve

        Posté par (page perso) . Évalué à 5 (+3/-0).

        RISC-V et MIPS proviennent du même terreau de Berkley. Ce qui change c'est la date de conception, RISC-V est plus récent et a pu apprendre des erreurs de MIPS (ainsi que de ARM d'ailleurs).

        Je comprend pas vraiment l'argument de la sécurité, en quoi le RISC-V apporterait ou non de la sécurité ?
        Au contraire d'ailleurs le fait d'avoir une ISA ouverte ne peut-être qu'un plus au moins niveau logiciel.

        Avec RISC-V il y a vraiment une volonté de mettre le plus possible d'acteurs du processeur autour de la table pour optimiser l'isa au mieux (par le biais de la fondation). C'est d'ailleurs la raison pour laquelle tout le spectre de l'ISA n'est pas encore stabilisé (Les base RV32E, RV128, et une partie des extensions ne sont pas encore dans leurs version final).

        Et MIPS a été poussé à l'opensource par RISC-V justement.

        • [^] # Re: Le rêve

          Posté par . Évalué à 3 (+1/-0).

          Je comprend pas vraiment l'argument de la sécurité, en quoi le RISC-V apporterait ou non de la sécurité ?

          Et bien l'ISA du CPU peut aider pour la détection de débordement entier comme le fait le MIPS mais pas le RISC-V, la détection de dépassement d'index de tableau, etc.
          Si tu veux en savoir plus va lire le lien que j'avais donné.

          Mais le seuil intérêt du RISC-V est d'avoir une ISA ouverte, l'ISA en elle même est juste un CPU "de base" qui n'apporte presque aucun progrès technique, dommage..

          • [^] # Re: Le rêve

            Posté par . Évalué à -3 (+0/-2). Dernière modification le 11/01/19 à 20:48.

            J'ai lu tout le texte de la page d'accueil de ForwardCom.info, j'ai analysé chaque détail, je suis ébahi.

            À la première citation de ton lien, j'avais cliqué, mais texte en anglais et long, avec Martoni qui simili-bluffe (humour) en mode y a pas de mal et lapin compris, puis tu insistes, et me revoilà ayant cliqué (1), quelques heures plus tard.

            À ce stade, je dis quelque chose comme Banzaï ! :

            • une convergence entre RISC et CISC pour en tirer le meilleur ;
            • un format d'instruction flexible (avec notamment la possibilité d'ajouter des instructions spécifiques à des applications) ;
            • des mécanismes de sécurité à profusion (contre le débordement de la pile d'appels, du fait qu'elle est distincte de la pile de données ; vérification de limites de tableaux ; un espace mémoire protégé par thread, etc.) ;
            • de la compatibilité descendante (Forward compatibility, d'où le nom du projet), avec prise en compte de l'évolution de la taille des registres vectoriels sur les CPU ultérieurs comportant une architecture similaire, sans nécessité de re-compilation des logiciels) ;
            • une gestion efficace des boucles logicielles (dans le cas de traitements parallélisables, à partir des éléments d'un tableau à parcourir), plus optimisée qu'avec les processeurs vectoriels classiques ;
            • une gestion mémoire efficace, limitant la fragmentation, avec un découpage de la mémoire en sections de taille variable, en nombre limité, de manière à ce que chaque processus ou chaque thread accède à un nombre limité de blocs mémoire pouvant tous tenir sur une table au sein du processeur ; ce faisant, il n'y a pas de mémoire virtuelle paginée au sens classique, qui implique d'énormes tables de page multi-niveaux, consommatrices de ressources CPU pour calculer la transposition entre adresses virtuelles et physiques, et il n'y a pas non plus de TLB (Translation lookaside buffer, Wikipédia francophone), le TLB étant une mémoire cache du processeur utilisée par l'unité de gestion mémoire (MMU) dans le but d'accélérer la traduction des adresses virtuelles en adresses physiques ;
            • j'en passe…

            Bon, il reste un peu de boulot, mais déjà beaucoup a été fait !

            Ah si, au-delà de Banzaï !, il me vient à l'esprit un C'est quoi ce bordel ? Pourquoi le danois Agner Fog n'a-t-il pas déjà une statue à son effigie présentée dans une page Wikipédia dédiée ? À quand une fondation ForwardCom pour dépoussiérer la démarche de cette fondation RISC-V du coup vieillissante ? Va-t-on laisser Libre Silicon (2) graver du CPU à l'architecture obsolète ? À quand un Raspberry Pi mis à jour selon l'état de l'art ?

            (1) Je n'ai pas consulté le reste, or je note qu'il y a aussi un manuel en PDF de 167 pages, une page de comparaison avec d'autres jeux d'instructions, un dépôt Github avec des logiciels (assembleur haut niveau ; désassembleur ; éditeur de liens ; gestionnaire de bibliothèques de fonctions; émulateur ; débogueur non interactif ; exemples de code), un forum de discussions, une page de ressources pour l'optimisation logicielle.

            (2) site officiel de LSA (Libre Silicon Alliance) : http://libresilicon.com/ — liens pour visionner la conférence « Libre Silicon » produite au 35c3 (35e édition du Chaos Communication Congress), il y a deux semaines.

            • [^] # Status actuel du projet ForwardCom

              Posté par . Évalué à 0 (+1/-1).

              Le travail de spécifications n'est pas totalement terminé, mais l'implémentation sur FPGA est déjà discutée. C'est exprimé dans la section titrée « Current status of the ForwardCom project » de la page d'accueil de ForwardCom.info (je traduis exhaustivement cette section) :

              • l'architecture fondamentale du jeu d'instruction a été conçue et un jeu complet d'instructions au niveau applicatif est défini ;
              • quelques instructions au niveau système ne sont pas encore complètement développées ;
              • la structure du format de fichier binaire a été définie en détails pour les fichiers objets, les bibliothèques de fonctions, et les fichiers exécutables ;
              • les détails du standard ABI (application binary interface, Wikipédia francophone), le standard de gestion mémoire, etc., ont été définis ;
              • les outils logiciels suivants on été développés [NDR : déjà cités au commentaire parent] : assembleur haut niveau, désassembleur, éditeur de liens, gestionnaire de bibliothèques de fonctions, émulateur, débogueur (non interactif à ce stade).
              • des implémentations matérielles sur FPGA sont en cours de discussion.
            • [^] # Re: Le rêve

              Posté par . Évalué à -4 (+0/-4).

              En dehors du premier huluberlu (1) qui a mis automatiquement une note négative au commentaire parent, je suppose que le second aura pu tiquer sur la référence au processeurs vectoriels, avec la prétention (qui est de moi, non pas dans le texte à la source) d'une optimisation de l'architecture ForwardCom supérieure à ceux-là dans leur version classique. Cette idée me vient au titre qu'un commentateur m'a prétendu sur /board que tous les processeurs sont vectoriels de nos jours (et qu'à ce titre je passerais pour une truffe), ce qui est une ineptie (et par charité je ne renverrai pas ici le bon mot de truffe à son auteur).

              Déjà, la distinction entre processeur scalaire (traitant des opérandes atomiques) et processeur vectoriel (améliorant l’exécution de programmes utilisant massivement des tableaux grâce au traitement parallélisé, avec des registres non pas scalaires mais vectoriels) a du sens encore de nos jours. Si historiquement seuls de gros calculateurs comportaient un (ou des) processeur(s) vectoriel(s), de plus en plus de machine communes sont dotées de CPU avec une architecture au moins partiellement vectorielle, cf. la simulation par des instructions MMX/SSE bas niveau de type vectoriel, dans les PC. Par ailleurs, les microcontrôleurs restent pour certains purement scalaires, cf. par exemple l'architecture du Intel 8051 encore utilisée.

              Ensuite, si je me suis permis de prétendre une optimisation supérieure des boucles dans le cas de l'architecture ForwardCom, c'est parce que l'auteur en fait la démonstration. Il n'y a qu'à lire et interpréter correctement. En effet, avec cette architecture, le parcours logiciel d'un tableau de données avec chargement de plusieurs cellules à la fois dans un registre vectoriel (pour ensuite appliquer un même traitement à chaque cellule), nécessite d'appeler à répétition une instruction unique qui s'adaptera d'elle-même en fin de tableau, par un mécanisme ingénieux, alors que dans les architectures vectorielles classiques (dans lesquels les registres vectoriels sont de taille fixe), le processeur doit déclencher l'appel d'une instruction scalaire similaire à l'instruction vectorisée quand il arrive en fin de tableau et que le nombre de cellules restant à traiter est inférieur à la taille d'un registre vectorisé, ce qui implique un surcoût, puisqu'il faut itérer autant de fois cet appel qu'il y a de cellules restantes à traiter. Par ailleurs, avec l'architecture ForwardCom, si la taille des registres vectoriels s'accroît avec une nouvelle génération de CPU, le code logiciel des boucles n'a pas à être changé, le surplus de parallélisation est directement exploité.

              Si je prends le temps de compléter mon propos pédagogiquement, c'est en hommage au travail de qualité qu'Agner Fog me semble avoir produit et pour favoriser une bonne réceptivité de la lumière à tous les étages des esprits des lecteurs…

              (1) un certain Single, qui s'avilit en cliquant sur inutile dès qu'il voit passer une référence à un de mes commentaires, par exemple parce que j'en présente la référence sur /board, comme ça s'est très exactement passé dans le cas d'espèce (attesté par l'observation de la chronologie et l'absence de réfutation à mon affirmation que ça s'était une nouvelle fois produit…)

            • [^] # Re: Le rêve

              Posté par . Évalué à 3 (+1/-0).

              Note que l'absence de TLB dans le ForwardCom (*) est quand même un peu "inquiétante" dans le sens de la compatibilité Linux, comme le x86 l'a montré la compatibilité logiciel est reine donc si le ForwardCom ou le Mill ne sont pas "bien" compatibles avec Linux alors ils sont morts, quelque soient leurs avantages..

              *: comme d'ailleurs dans le Mill: https://en.wikipedia.org/wiki/Mill_architecture

              • [^] # Re: Le rêve

                Posté par . Évalué à -1 (+0/-1). Dernière modification le 14/01/19 à 19:25.

                [ Sur la compatibilité de l'architecture ForwardCom (sans TLB) avec Linux ]

                Je ne me rends pas compte de l'importance du travail qu'il faudrait réaliser pour avoir une version de Linux compatible avec cette architecture sans TLB. Si la compatibilité n'est pas acquise par défaut, te semble-t-elle très difficile à obtenir ? Tu peux argumenter ? J'imagine idéalement une situation dans laquelle l'approche sans TLB serait intégrée à terme dans la branche principale de Linux, en tant qu'alternative sélectionnable par des options de compilation avec possibilité de compiler pour la cible ForwardCom.

                [ Sur le cas de l'architecture Mill ]

                Par ailleurs, pour ce qui est de l'architecture Mill (que je découvre), en entamant la lecture, dès le chapeau de l'article Wikipédia, je lis ceci (je traduis (1)) : Mill Computing prétend que « [son architecture Mill] présente un gain en performance sur les traitements mono-thread qui est multiplié par 10 par rapport aux architectures conventionnelles super-scalaires du type out-of-order », mais qu' « elle exécute les mêmes programmes, sans ré-écriture ». Je n'ai pas lu l'article plus loin pour l'instant, mais déjà s'il n'y a véritablement pas besoin de ré-écrire les programmes, alors il n'y a pas de problème de compatibilité avec Linux.

                (1) Pour référence, voici la phrase originelle en anglais : « Mill Computing claims it has a "10x single-thread power/performance gain over conventional out-of-order superscalar architectures" but "runs the same programs, without rewrite" ».

    • [^] # Re: Le rêve

      Posté par . Évalué à -1 (+0/-2).

      ARM c'est bien, mais c'est pas aussi ouvert que RISC-V qui lui est 100% opensource. Il faut que le RISC-V se déploie à grande échelle :)

      Ainsi les chinois domineront le marché du CPU comme à l'habitude : sans rien avoir financé, sans avoir participé, en ayant tout copié.

      🇪🇺 Donation : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat (Bitcoin | Bitcoin Cash)

      • [^] # Re: Le rêve

        Posté par (page perso) . Évalué à 2 (+1/-0).

        On est pas obligé de les acheter :)

        La raspberry pi est bien fabriquée au Royaume-Uni non ?

        l'azerty est ce que subversion est aux SCMs

        • [^] # Re: Le rêve

          Posté par . Évalué à 5 (+3/-0).

          La raspberry pi est bien fabriquée au Royaume-Uni non ?

          En partie assemblé en UK mais le SoC Broadcom il ne vient pas de là bas et les autres composants sont de toute façon en majorité fabriqués en RPC.

          Mais au-delà de ça, les chinois font leurs propres processeurs et microcontroleurs depuis quelques années déjà.

        • [^] # Re: Le rêve

          Posté par . Évalué à -1 (+1/-3). Dernière modification le 10/01/19 à 16:32.

          On est pas obligé de les acheter :)

          C'est avec cet argument que la génération d'avant à laisser nos industries se délocaliser.
          Note que je ne suis pas contre le hardware libre, loin de là, mais je suis septique face à ce genre de techno alors que nos usines sont toutes parties aux pays des esclaves.

          La raspberry pi est bien fabriquée au Royaume-Uni non ?

          Tu as le choix entre la version made in UK et la version made in China.

          🇪🇺 Donation : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat (Bitcoin | Bitcoin Cash)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.