Journal #define CHAR_BIT 8

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
19
18
oct.
2024

Un séisme cataclysmique fait trembler jusqu'aux fondations du web et ébranle tout le monde connu, les réseaux sociaux sont en feu, Stroustrup refuse de répondre au téléphone, tandis que nous attendons impatiemment une déclaration de nos dirigeants éclairés : le über geek JF Bastien vient de publier une proposition de changement du standard C++ décrétant qu'il y aurait exactement 8 bits dans un byte, prouvant au passage que les français étaient une fois de plus précurseurs en généralisant le terme octet.

Alors vous le savez sans doute, une immense majorité des architectures aujourd'hui font effectivement ce choix, et les compilos modernes sont construits sur ce modèle. L'argument de JF Bastien est donc que non seulement il n'existe presque plus de systèmes où ce n'est pas vrai, mais qu'en plus la minorité de développeurs qui pourraient travailler sur ces architectures n'ont aucun besoin d'un compilateur C++ moderne: "The question isn’t whether there are still architectures where bytes aren’t 8-bits (there are!) but whether these care about modern C++… and whether modern C++ cares about them."

Je sens confusément que je devrais avoir une opinion tranchée sur la question, il ne me reste plus qu'à déterminer laquelle.

  • # Mauvaise idée ?

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

    Celui qui a fait cette proposition parle de la situation présente avec une majorité d'architectures qui codent sur 8 bits, mais il ne semble pas regarder vers le futur.

    Dans le futur, on aura peut-être besoin d'octets plus gros, par exemple 10 bits. Les nouveaux écrans codent déjà les couleurs sur 10 bits au lieu de 8.

    Donc figer la taille d'un octet à 8 bits, c'est peut-être une mauvaise idée.

  • # Question probablement bête

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Quelqu'un peut expliquer le rapport entre char et octet ?

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: Question probablement bête

      Posté par  (site web personnel, Mastodon) . Évalué à 3 (+1/-0).

      Actuellement il n'y en a pas vraiment. En C et en C++, on définit que sizeof(char) vaut 1. Quand on incrémente un pointeur sur un char, il s'incrémente donc de 1. Il est impossible d'avoir un type de données plus petit (sauf les booléens et les bitfields), et les types plus gros sont des multiples de la taille d'un char. Mais, on peut implémenter le C et le C++ avec n'importe quel nombre de bits dans un char.

      Il existe quelques architectures incapables d'adresser la mémoire plus finement que 16 ou même 32 octets. En particulier: des machines dont le jeu d'instruction n'est pas un lointain descendant du PDP-11; et certaines familles de DSP conçus par exemple pour le traitement du son en 16 bit.

      Pour aaoir récement implémenté un compilateur C sur une telle architecture, je confirme qu'il a été relativement difficile de trouver une chaîne d'outils capable de prendre cela en compte (mais j'ai finalement convaincu les développeurs de vbgc et de vasm de se pencher sur le problème). Je regrette de ne pas pouvoir faire de C++ sur ce système pour l'instant, c'est un langage intéressant pour réaliser de nombreuses optimisations à la compilation qui me seraient bien utiles,

      • [^] # Re: Question probablement bête

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        Je posais la question car l'auteur de la proposition a l'air de considérer évident et implicite (dès le titre) que char et byte c'est la même chose, alors que ça pourrait me semble à étayer dans un doc de normalisation. :)

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: Question probablement bête

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

        Alors, je serais vous, je vérifierais systématiquement que sizeof(char) == 1.

        Retour quasi 10 ans en arrière. R&D pour le développement d'une enceinte Bluetooth.
        Est-ce qu'on pourrait faire tout avec la puce à la mode à l'époque, à savoir, la CSR 8670 ?

        NB: CSR est une boîte anglaise spécialisée dans ce genre de puce. Était, puisque rachetée par Qualcomm en 2015.

        Globalement : non, pas possible. Mais il a fallu passer quelques mois pour prendre la mesure de la perfidie des grands bretons. Sur le papier, elle est géniale cette puce : en plus du Bluetooth évidemment, un MCU accompagné de son DSP, trop cool.

        En pratique … Énormément de pipo des commerciaux et technico-commerciaux …

        Outre les limitations de ressources hallucinantes, les limites très mal documentées de l'unique fonction pour communiquer sur le bus I2C, après quelques bizarreries, j'ai fini par afficher la valeur de sizeof(uin8_t).

        Réponse : 2.

        Oui, 2.

        Le support a été incapable de m'expliquer pourquoi.
        J'ai trouvé la réponse seul, par hasard, sur le forum concernant une autre de leurs puces.
        Réponse : c'est légal, c'est autorisé par la norme C, un octet ne fait pas forcément 8 bits.

        OK. Pour l'I2C en particulier, c'était déjà la merˆWpanade, alors transférer de la data stockée dans un tableau dont on ignore comment seront traités les "trous" …
        Et quid de l'arithmétique des pointeurs ? Il avance de 1 ou de 2 quand je fais ++ ? Pour coller au sizeof, ce serait 2. Pour revenir à cette fonction de transfert sur l'I2C : est-ce que les "trous" sont transférés ? Est-ce que je dois plutôt gérer un tableau de uint16_t ? Quid de l'endianess ?…

        Cette épée de Damoclès en permanance sur ce qui se passe au plus bas niveau … Stressant …
        Je vous raconte pas les nœuds au cerveau et le doute permanent sur le comportement du chip.

        Conclusion : le gars qui customise un compilo pour en arriver là, c'est le diable en personne !

        À moins que quelqu'un connaisse un cas de figure où c'est justifié ? Est-ce que c'est plus répendu que je ne le pense ?

        Non, récupérer apacher une vieille architecture moisie des années 80s n'est pas une excuse acceptable !

        • [^] # Re: Question probablement bête

          Posté par  (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 19 octobre 2024 à 13:54.

          Réponse : c'est légal, c'est autorisé par la norme C, un octet ne fait pas forcément 8 bits.

          Alors une chose de sûr, un octet fait forcément 8 bits, c'est sa définition, dans un dico et tout et tout (octet, et du latin), j'imagine donc que tu voulais parler d'une byte ou multiplet

          Ensuite, la j'aimerai l'argument, qu'on me corrige si je me trompe mais il me semble que le standard dit que :
          uint8_t fait exactement 8 bit
          sizeof(char) fait forcément 1
          la taille minimum de char est 8
          Partant de ces postulats, mathématiquement sizeof(uint8_t) ne peut pas être autre chose que 1 (aucune taille de char, la seule chose variable, peut faire une autre valeur sans manquer de respecter une des règles, genre il faudrait que la taille d'un char soit 4 qui n'est pas valide).

          Conclusion : le gars qui customise un compilo pour en arriver là, c'est le diable en personne !

          Clairement, et on peut supposer que c'est un gros bug mais qu'ils ne veulent pas corriger à cause de conséquences chiantes à gérer.

  • # J'hésite

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

    Aucun doute qu'en dehors de quelques architectures exotiques on aura 8 bits dans un char. Néanmoins, comme pour trop de nouveautés du C++ de ces dix dernières années, je me demande quel problème ce papier essaye de résoudre.

    The complexity of supporting non-8-bit byte architectures sprinkles small but unnecessary burden in quite a few parts of language and library;

    Sans doute. Des exemples peut-être ? Histoire qu'on puisse juger de cette charge ajoutée.

    Compilers and toolchains are required to support edge cases that do not reflect modern usage;

    Oui ce n'est pas moderne, mais faut-il jeter tout ce qui n'est pas moderne ? Le C++ n'est pas un langage moderne de toute façon.

    New programmers are easily confused and find C++'s exotic tastes obtuse;

    Et ? Les nouveaux programmeurs on en effet tout à apprendre du langage et de son histoire.

    Some seasoned programmers joyfully spend time supporting non-existant platforms "for portability" if they are unwise;

    Un peu de temps perdu pour quelques programmeurs. Okay, pas vraiment un problème mais pourquoi pas.

    Our language looks silly, solving problems that nobody has.

    Avec un lien vers un tweet. Bon, un type sur Internet trouve le langage idiot. Qui ça intéresse ?

    À mon humble avis le comité passe beaucoup trop de temps à essayer de se convaincre que ce langage n'est pas dépassé. On peut mettre autant de qualificatifs modern ou contemporary à côté de son nom, le C++ est factuellement un langage de vieux. La plupart des programmes écrits en C++ sont de vieux trucs, et c'est normal vu son âge. Si vous voulez un langage moderne et performant il y a d'autres candidats plus pertinents.

    L'argument de l'attention aux jeunes programmeur est fallacieux. Chaque couche de modernisation est une chose supplémentaire à comprendre pour les devs C++.

    • [^] # Re: J'hésite

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

      En quoi le C++ serait dépassé ?

      C'est un langage vieux, et alors ?

      Quel est l'intérêt d'utiliser un langage apparu récemment ?

      Et quels sont les langages performants plus pertinents que le C++ ?

  • # Fortran

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    Sur les 681 pages de la norme Fortran 2023, le mot byte n'apparaît que dans la section consacrée à l'interopérabilité avec le C. Le mot octet apparaît deux fois.

    Le FORTRAN est né avant que le byte se stabilise sur 8 bits, d'où cette prudence qui peut bien sûr être parfois gênante quand on vit dans les systèmes actuels. Le module intrinsèque iso_fortran_env, introduit avec Fortran 2008, définit néanmoins un KIND INT8 pour les INTEGER.

Envoyer un commentaire

Suivre le flux des commentaires

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