champ de bits de padding dans C

De la norme ISO C standard:

Une mise en œuvre peut attribuer tous adressable de l'unité de stockage assez grand pour contenir un peu-
champ. (et plus tard), Il peut être sans nom rembourrage à la fin d'une structure ou d'une union.

Donc il n'y a pas d'obligation de toujours choisir la plus petite partie de la mémoire pour la structure. Et depuis 32 bits mots sont probablement la taille d'origine de votre compilateur, c'est ce qu'il choisit.

OriginalL'auteur Imre Kerr

Pour une raison que je ne pas comprendre, la mise en œuvre de la norme C décidé que la spécification d'un numberic type avec un champ de bits doit allouer de l'espace suffisant pour tenir que de type numérique, à moins que le précédent, le champ est un champ de bits, affectés du même type, qui avait juste assez d'espace pour manipuler le champ suivant.

Pour votre exemple, sur une machine 16 bits unsigned short, vous devez modifier les déclarations dans votre champ de bits pour unsigned short. Comme il arrive, unsigned char également de travailler, et de produire les mêmes résultats, mais ce n'est pas toujours le cas. Si de manière optimale-paniers bitfields chevauchent char limites, mais pas à court limites, puis de déclarer bitfields comme unsigned char aurait besoin de rembourrage pour éviter de telles chevauchant.

Bien que certains processeurs n'ont aucune difficulté à la génération de code pour bitfields qui chevauchent le stockage de l'unité de limites, la présente norme C interdirait l'emballage de cette façon (encore une fois, pour des raisons que je n'ai pas l'imaginer). Sur une machine avec typique 8/16/32/64 bits types de données, par exemple, un compilateur n'a pas pu permettre à un programmeur de spécifier un 3 octets de la structure contenant huit à trois octets des champs, depuis les champs aurait à cheval sur les limites d'octets. Je peux comprendre la spec pas nécessitant compilateurs de manipuler des champs qui chevauchent les frontières, ou d'exiger que bitfields être mis dans un mode particulier (j'avais les considérer comme infiniment plus utile si l'on peut spécifier qu'un champ de bits doit par exemple utiliser les bits 4 à 7 de un certain endroit), mais la présente norme semble donner le pire des deux mondes.

Dans tous les cas, la seule façon d'utiliser bitfields efficacement est de savoir où l'unité de stockage de limites, et de choisir les types de la bitfields convenablement.

PS - Il est intéressant de noter que, si je me souviens compilateurs utilisés pour interdire volatile des déclarations pour les structures contenant des bitfields (depuis la séquence des opérations lors de l'écriture d'un champ de bits ne peut pas être bien définie), en vertu des nouvelles règles de la sémantique pourrait être bien définis (je ne sais pas si la spécification exige en fait). Par exemple, étant donné:

typedef struct {
  uint64_t b0:8,b1:8,b2:8,b3:8, b4:8,b5:8,b6:8,b7:8;
  uint64_t b8:8,b9:8,bA:8,bB:8, bC:8,bD:8,bE:8,bF:8;
} FOO;
extern volatile FOO bar;

la déclaration bar.b3 = 123; va lire les 64 premiers bits de bar, puis écrire les 64 premiers bits de bar avec une mise à jour de la valeur. Si bar n'ont pas été volatile, un compilateur peut remplacer cette séquence avec un simple 8-bits à écrire, mais bar pourrait être quelque chose comme un matériel de registre qui peut uniquement être écrit en 32-bits ou 64-bits morceaux.

Si j'avais tenait qu'à moi, il serait possible de définir bitfields en utilisant quelque chose comme:

typedef struct {
  uint32_t {
    baudRate:13=0, dataFormat:3,
    enableRxStartInt: 1=28, enableRxDoneInt: 1, enableTxReadyInt: 1, enableTxEmptyInt: 1;};
  };
} UART_CONTROL;

indiquant que le débit en bauds est de 13 bits de départ au bit 0 (LSB), le format est de 3 bits à partir après le débit en bauds, enableRxStartInt est peu 28, etc. Une telle syntaxe permettrait à de nombreux types de données, l'emballage et le déballage d'être écrite de façon nomade, et devrait permettre à beaucoup d'I/O enregistrer les manipulations à faire dans un compilateur indépendant de la mode (même si un tel code serait évidemment de matériel spécifique).

OriginalL'auteur supercat