Quelles plates-formes sont autre chose que 8 bits char ?

Question

Chaque maintenant et puis, quelqu'un sur tant de points qu' char (aka 'octet') n'est pas nécessairement de 8 bits.

Il semble que les 8 bits char est presque universel. J'aurais pensé que pour les principales plates-formes, il est nécessaire de disposer d'un 8-bit char afin d'assurer sa viabilité sur le marché.

À la fois maintenant et dans l'histoire, quel plates-formes utilisent un char qui n'est pas de 8 bits, et pourquoi seraient-ils différents de la "normale" 8 bits?

Lors de l'écriture de code, et de penser à la croix-plate-forme de soutien (p. ex. pour l'utilisation générale des bibliothèques), ce genre de considération est-il utile de donner à des plates-formes avec les 8 bits char?

Dans le passé, j'ai rencontré certains Appareils Analogiques Dsp pour qui char est de 16 bits. Les dsp sont un peu d'une niche de l'architecture, je suppose. (De nouveau, à la fois à la main codé en assembleur facilement battu ce que l'compilateurs C pourrait le faire, donc je n'ai pas vraiment beaucoup d'expérience avec C sur cette plate-forme.)

Answer 1

char est également 16 bits sur le Texas Instruments C54x Dsp, qui a donné par exemple dans OMAP2. Il y a d'autres Dsp avec 16 et 32 bits char. Je pense que j'ai même entendu parler d'un 24-bit DSP, mais je ne me souviens pas de ce que, peut-être que je l'avais imaginé.

Une autre considération est que POSIX mandats CHAR_BIT == 8. Ainsi, si vous utilisez POSIX vous pouvez le supposer. Si quelqu'un plus tard besoins à port votre code le plus proche,-la mise en œuvre de la norme POSIX, qui se trouve juste à avoir les fonctions que vous utilisez, mais une taille différente char, c'est leur mauvaise chance.

En général, cependant, je pense qu'il est presque toujours plus facile de travailler autour de la question que d'y penser. Juste type CHAR_BIT. Si vous voulez une exacte: 8 bits type, utilisez int8_t. Votre code bruyamment ne parviennent pas à compiler sur des implémentations qui ne fournissent pas, au lieu de s'en silence à l'aide d'un taille vous ne vous attendiez pas. À tout le moins, si j'ai frappé un cas où j'ai eu une bonne raison de supposer, alors je vous l'affirmer.

Answer 2

Lors de l'écriture de code, et de penser à la croix-plate-forme de soutien (p. ex. pour l'utilisation générale des bibliothèques), ce genre de considération est-il utile de donner à des plates-formes avec les 8 bits de char?

Ce n'est pas tellement que c'est "la peine de donner de la considération à quelque chose, comme il est des règles du jeu. En C++, par exemple, la norme dit que tous les octets aura "au moins" de 8 bits. Si votre code suppose que les octets 8 bits, vous êtes violation de la norme.

Cela peut sembler idiot maintenant -- "bien sûr, tous les octets de 8 bits!", Je vous entends dire. Mais beaucoup de gens très intelligents ont compté sur des hypothèses qui n'étaient pas garanties, et puis tout s'est cassé. L'histoire est remplie d'exemples de ce genre.

Par exemple, la plupart au début des années 90, les développeurs de supposer qu'un particulier non-op CPU retard de synchronisation de prendre un nombre fixe de cycles de prendre un montant fixe de temps de l'horloge, parce que la plupart des Processeurs étaient à peu près équivalent en puissance. Malheureusement, les ordinateurs a obtenu plus rapidement, très rapidement. Ce qui a engendré la hausse des boîtes avec "Turbo" boutons -- dont le but est, ironiquement, était à ralentissent l'ordinateur ainsi que les jeux en utilisant le temps de retard technique pourrait être joué à une vitesse raisonnable.

---

Un intervenant a demandé où dans la norme, il est dit que le char doit avoir au moins 8 bits. C'est dans la section 5.2.4.2.1. Cette section définit CHAR_BIT, le nombre de bits dans la plus petite adressable entité, et a une valeur par défaut de 8. Il dit aussi:

Leur mise en œuvre-la définition des valeurs doit être égale ou de plus grande ampleur (valeur absolue) à celles indiquées, avec le même signe.

Donc, n'importe quel nombre égal à 8 ou plus est adapté pour le remplacement par une mise en œuvre en CHAR_BIT.

Answer 3

Les machines avec des architectures de 36 bits ont 9 octets. Selon Wikipedia, les machines avec des architectures de 36 bits incluent :

• Digital Equipment Corporation PDP-6/10
• IBM 701/704/709/7090/7094
• UNIVAC 1103/1103A/1105/1100/2200,

Answer 4

Quelques uns dont je suis conscient :

• DEC PDP-10 : variable, mais les caractères 7 bits plus souvent emballés 5 par mots de 36 bits, sinon 9 bit chars, 4 par mot
• Gros systèmes de données de contrôle (CDC-6400, 6500, 6600, 7600, Cyber 170, Cyber 176 etc.) caractères de 6 bits, emballés 10 par mot 60 bits.
• Mainframes Unisys : 9 bits/octets
• Windows CE : simplement ne supporte pas du tout le type « char »--requiert 16 bits wchar_t plutôt

Answer 5

Il n'y a pas une telle chose comme un complètement du code portable. :-)

Oui, il peut y avoir différentes octet/char tailles. Oui, il peut y avoir des C/C++ implémentations pour les plates-formes avec de très inhabituel valeurs de CHAR_BIT et UCHAR_MAX. Oui, parfois, il est possible d'écrire du code qui ne dépend pas de char de taille.

Cependant, presque tout le code réel, n'est pas autonome. E. g. vous avez peut-être d'écrire un code qui envoie les messages binaires sur le réseau (protocole n'est pas important). Vous pouvez définir les structures qui contiennent les champs nécessaires. Que vous avez à sérialiser. Juste binaire de la copie d'une structure dans une mémoire tampon de sortie n'est pas portable: en général, vous ne connaissez ni l'ordre des octets pour la plate-forme, ni de la structure des membres de l'alignement, de sorte que la structure tient juste les données, mais pas décrit la manière dont les données doivent être sérialisé.

Ok. Vous pouvez effectuer l'ordre des octets de transformations et de déplacer les membres de structure (par exemple, uint32_t ou similaire) à l'aide d' memcpy dans le tampon. Pourquoi memcpy? Parce qu'il ya beaucoup de plates-formes où il n'est pas possible d'écrire des 32-bits (16 bits, 64 bits -- pas de différence) lorsque l'adresse de destination n'est pas correctement aligné.

Donc, vous avez déjà fait beaucoup pour atteindre la portabilité.

Et maintenant la dernière question. Nous avons une mémoire tampon. Les données sont envoyées au réseau TCP/IP. Ce réseau suppose octets de 8 bits. La question est: de quel type de la mémoire tampon doit être? Si vos caractères sont de 9 bits? Si elles sont en 16 bits? 24? Peut-être que chaque caractère correspond à un octet de 8 bits envoyés au réseau, et à seulement 8 bits sont utilisés? Ou peut-être plusieurs réseau octets sont emballés dans 24/16/9 bits caractères? C'est une question, et il est difficile de croire qu'il existe une réponse unique qui convient à tous les cas. Beaucoup de choses dépendent de la prise de la mise en œuvre de la plate-forme cible.

Alors, de quoi je parle. Habituellement, le code peut être relativement facilement portable, dans une certaine mesure. Il est très important de le faire si vous vous attendez à utiliser le code sur différentes plates-formes. Cependant, l'amélioration de la portabilité au-delà de cette mesure est une chose qui exige beaucoup d'efforts et donne souvent à peu, comme le code réel presque dépend toujours de l'autre code (socket mise en œuvre dans l'exemple ci-dessus). Je suis sûr que pour environ 90% du code de la capacité de travail sur les plates-formes avec des octets autre que le 8-bit est presque inutile, car il utilise de l'environnement qui est lié à 8 bits. Il suffit de vérifier la taille en octets et d'effectuer de temps pour la compilation de l'assertion. Vous seront presque certainement avoir à réécrire un lot pour une grande plate-forme inhabituelle.

Mais si votre code est très "autonome" -- pourquoi pas? Vous pouvez écrire dans une manière qui permet à différentes longueurs d'octets.