Discussion :

[dourouc05]

La nouvelle version de LLVM et de Clang est sortie. Alors que LLVM fournit l'infrastructure générique d'un compilateur, Clang fait l'interface avec du code C, C++ et Objective-C. Cette version apporte notamment une implémentation finalisée de la génération de code pour RISC-V, l'architecture libre de processeur — auparavant, elle était marquée comme expérimentale. LLVM étant très utilisé pour développer des interpréteurs et compilateurs pour des langages divers et variés (comme Julia), le projet se doit d'avoir une excellente interface de programmation : outre deux nouveaux points d'extension pour l'optimisation du code lors de l'édition des liens (LTO), l'interface ORCJIT a été révisée. La version actuelle reste disponible, mais son emploi est découragé, au profit de la nouvelle version, largement améliorée pour une utilisation parallèle.

Au niveau des plateformes, le code assembleur peut désormais directement accéder à de nombreuses instructions ARM supplémentaires : SVE2 (scalable vector extension) et MVE (M-profile vector extension) pour l'exécution en simultané d'une même instruction sur plusieurs données, MTE (memory tagging extension) pour indiquer quelles parties de la mémoire peuvent être écrites et ainsi limiter les risques de sécurité. LLVM intègre aussi un modèle plus complet du processeur Cortex-M4, pour générer du code plus performant.

Au niveau des langages, Clang s'ouvre aux versions futures de C et de C++, avec l'inclusion d'un mode C2x ; le mode C++2a active par défaut les modules. Côté OpenCL, on peut désormais utiliser toutes les fonctionnalités de C++17 en conjonction avec OpenCL 2.0, grâce à des améliorations au niveau des attributs concernant l'espace d'adressage. Cette implémentation est cependant toujours expérimentale.

Le point mineur le plus important est cependant l'implémentation des instructions ASM GOTO. Ce petit détail a toute son importance, puisque désormais Clang peut compiler avec succès le noyau Linux pour des processeurs x86_64, après des années de travail acharné pour y arriver (Clang 4 arrivait déjà à compiler Linux pour un certain nombre d'architectures, comme ARM ou PowrePC). Android et ChromeOS sont déjà en train d'effectuer la transition depuis GCC.

Sources : notes de version de LLVM et Clang.

[matthius]

Un processeur 32 et 64 bits n'a aucun intérêt. L'intérêt du partage de ces sources est surtout qu'on peut enfin créer une compatibilité avec ce processeur.

Comprendre un processeur c'est surtout comprendre comment les produire en série.

Le partage des microcodes Intel et AMD est bien plus intéressant. Ces processeurs sont bien plus puissants mais CISC effectivement.

Il est plus difficile de sécuriser quelque chose de complexe. C'est une raison pour ne pas utiliser cette architecture.

L'intérêt réel pourrait être la faible consommation d'énergie, ce qui est inatteignable avec du 32/64.

[Andarus]

Un processeur 32 et 64 bits n'a aucun intérêt.

Je ne comprend pas cette phrase 🤔

[Steinvikel]

Le problème c'est que l'emploi de dénomination non standardisé tel que "x86_64" introduit des doubles sens. Quand moi je lis "un processeur 64 bit (capable de faire tourner un programme 32bit)", d'autres lisent "un processeur capable d'interpréter des instructions 64bit et 32bit".
C'est bien ça matthius ?

"Il est plus difficile de sécuriser quelque chose de complexe. C'est une raison pour ne pas utiliser cette architecture."
+1 ...c'est, il me semble, un point que beaucoup perdent de vue quand ça commence à parler nouveaux CPU et évolutions techniques.

[matthius]

Je ne comprend pas cette phrase 🤔

Il y a des processeurs dans les processeurs. Les processeurs dans les processeurs nous incitent maintenant à en mettre dans les câbles et les écrans, alors qu'un simple partage d'instructions donc de processeurs permettrait plus de vitesse.

Ce partage est intéressant. Il montre qu'il n'y a plus besoin d'en chercher de cachés. En effet, du 32 bits reste rapide s'il n'est pas changé. Je doute qu'un processeur soit rapide et simple donc efficace autrement. Le 32 bits dans un processeur peut être logiciel, donc aucune raison d'en mettre en hardware dans un processeur. Donc l'inutilité de ce partage montre qu'on ne sait plus quoi trouver pour nous occuper.

Je pense que certains partages libres d'instructions Nvidia ou ATI permettaient à la communauté libriste de croire à du nouveau, alors qu'il ne s'agissait que de comprendre pourquoi ils le faisaient.

Ce partage d'instructions peut servir à des pays qui n'ont pas de processeur RISC, pas à la France qui en a des meilleurs ou peut en créer en 64 bits uniquement.

[Invité]

Il y a des processeurs dans les processeurs. Les processeurs dans les processeurs nous incitent maintenant à en mettre dans les câbles et les écrans, alors qu'un simple partage d'instructions donc de processeurs permettrait plus de vitesse.

Ce partage est intéressant. Il montre qu'il n'y a plus besoin d'en chercher de cachés. En effet, du 32 bits reste rapide s'il n'est pas changé. Je doute qu'un processeur soit rapide et simple donc efficace autrement. Le 32 bits dans un processeur peut être logiciel, donc aucune raison d'en mettre en hardware dans un processeur. Donc l'inutilité de ce partage montre qu'on ne sait plus quoi trouver pour nous occuper.

Je pense que certains partages libres d'instructions Nvidia ou ATI permettaient à la communauté libriste de croire à du nouveau, alors qu'il ne s'agissait que de comprendre pourquoi ils le faisaient.

Ce partage d'instructions peut servir à des pays qui n'ont pas de processeur RISC, pas à la France qui en a des meilleurs ou peut en créer en 64 bits uniquement.

Soit j'ai rien compris, soit ton message n'a aucun sens ni aucun rapport avec la news.