C n’est pas un langage de bas niveau (2018)

• Un article qui soutient que, contrairement à une croyance répandue, C n’est pas un langage de bas niveau
• L’auteur, David Chisnall, avance que les vulnérabilités Meltdown et Spectre sont dues à la capacité des processeurs à exécuter des instructions en contournant les vérifications d’accès, une fonctionnalité ajoutée pour permettre aux programmeurs C de croire qu’ils programment dans un langage de bas niveau.
• Chisnall affirme qu’être « proche du métal » signifie qu’un langage doit fournir une machine abstraite qui se mappe facilement sur les abstractions exposées par la plateforme cible, et il soutient que ce n’est pas le cas de C.
• L’auteur suggère que la cause profonde des vulnérabilités Spectre et Meltdown tient au fait que les architectes processeur ont essayé de concevoir des processeurs rapides exposant une machine abstraite semblable au PDP-11, ce qui a permis aux programmeurs C de continuer à croire que leur langage était proche du matériel sous-jacent.
• Chisnall soutient que pour exécuter rapidement du code C, il faut des transformations de compilation complexes et des milliers d’années-homme pour construire des compilateurs suffisamment intelligents.
• L’auteur avance qu’une propriété essentielle d’un langage de bas niveau est que les programmeurs doivent pouvoir comprendre facilement comment la machine abstraite du langage se mappe sur la machine physique sous-jacente, et il affirme que ce n’est pas le cas avec C.
• Chisnall conclut qu’il est peut-être temps d’arrêter d’essayer de rendre le code C rapide, et de réfléchir plutôt à ce à quoi devrait ressembler un modèle de programmation pour des processeurs rapides. Selon lui, des processeurs conçus uniquement pour la vitesse prendraient probablement en charge un grand nombre de threads, disposeraient de larges unités vectorielles et d’un modèle mémoire bien plus simple.

[GN⁺]

Avis sur Hacker News

• L’article affirme que C n’est pas un langage de bas niveau en raison de la gestion manuelle de la mémoire et des appels explicites à l’allocateur.
• Certains commentateurs soutiennent que, pour ceux qui le comprennent et l’utilisent de manière experte, C est bel et bien un langage de bas niveau.
• L’affirmation de l’auteur selon laquelle le jeu d’instructions du CPU devrait exposer davantage l’implémentation du processeur est contestée, avec des références à des tentatives passées qui ont échoué.
• La notion de bas niveau à haut niveau semble former un spectre, et C se situe du côté le plus bas parmi les langages qui exposent des primitives machine comme la mémoire et la gestion des threads.
• L’affirmation de l’article selon laquelle la programmation parallèle n’est pas difficile est jugée trompeuse par certains commentateurs.
• Le postulat de l’article selon lequel les ordinateurs ne ressemblent pas à l’architecture du PDP-11 semble plus juste que jamais, mais la conclusion invitant à imaginer des processeurs non-C paraît moins convaincante.
• Certains commentateurs estiment que l’article a raison de dire que les ordinateurs ne sont pas des PDP-11 rapides, mais qu’il est erroné de relier cela à C.
• L’affirmation de l’article selon laquelle C n’est pas un langage de bas niveau, en raison notamment du padding des struct et du fait que le dépassement signé est un comportement indéfini, paraît constructive.
• L’idée que la domination de C a contraint les concepteurs de CPU à créer naturellement des processeurs capables d’exécuter C semble logique, mais le lien avec l’affirmation initiale et le titre de l’article reste flou.
• Si les techniques sophistiquées des CPU modernes font que C n’est plus un langage « bas niveau », alors le même raisonnement s’applique aussi à l’assembleur.
• L’article rappelle à certains commentateurs le VLIW, où une seule instruction VLIW peut contenir plusieurs instructions indépendantes exécutables en parallèle.