Alignement d'une structure contenant des champs de bits

Bonjour,

je souhaite comprendre la règle qui gère l'alignement des champs dans C Microsoft, j' ai trouvé une structure dont tous les membres sont champs de bits en total ils font 16 bits qui correspond à la taille d'un WORD.

Code:

---

1 2 3 4 5 6

struct tag_struc{ WORD Champ1 :4; WORD Champ2 :2; WORD Champ3 :1; ... } struc;

---

Quelle est la taille de cette structure ?

Bonjour,

Tant que le type reste identique d'un champ au suivant, c'est le même espace qui est progressivement rempli par les champs de bits successifs. En outre, on peut lire clairement ici : https://learn.microsoft.com/fr-fr/cp...?view=msvc-170

Citation:

---

Les champs de bits sont alloués dans un entier du bit de poids le plus faible au bit de poids le plus fort.

---

Lorsque l'on change de type (à vérifier) ou lorsque que la largeur totale des champs de bits cumulés dépasse celle du type, un nouveau champ est alloué dans la structure et on recommence directement à partir du bit0 de ce nouveau champ. Les champs de bits ne sont jamais « à cheval » sur deux instances. J'imagine également que dans ce cas, les règles d'alignement (pragma pack) s'appliquent de façon ordinaire sur les plages réservées.

Salut,

Citation:

---

Envoyé par Mist2024

Quelle est la taille de cette structure ?

---

Sa taille est définie par l'implémentation et ici elle a pour valeur sizeof(struct tag_struc).

Tiens bizarre personne n'a répondu sur la limitation des bits :koi: :koi:
en gros Champ1 va occuper 4 bits (:4), Champ2 2 bits (:2) et Champ3 1 bit (:1)

Ta structure n'est pas complète mais avec ses 3 champs, ta structure devrait faire 1 octet
4 + 2 + 1 = 7, mais comme le dit @Obsidian, et d'après mes souvenirs la structure est toujours alignée sur 8 ou 16 bits.
Par exemple si tu rajoutes 1 champs mais de + de 2 bits, le champ sera mis dans 1 autre octet et tu perdras 1 bit dans le premier octet.

Bonjour foetus,

Citation:

---

Envoyé par foetus

...4 + 2 + 1 = 7, mais comme le dit @Obsidian, et d'après mes souvenirs la structure est toujours alignée sur 8 ou 16 bits.
Par exemple si tu rajoutes 1 champs mais de + de 2 bits, le champ sera mis dans 1 autre octet et tu perdras 1 bit dans le premier octet.

---

C'est vrai sur une machine 8 bits mais pas sur une machine (et donc un compilateur) traitant des opérations de tailles supérieures. Aujourd'hui, avec une taille 64 bit, le chevauchement évoqué ne peut apparaître que sur des champs binaires de taille > 64. Comme la technique de récupération des valeurs est de type décalage et masquage, je suppose que SSE et autres SIMD ne sont pas mis à contribution (sinon on peut aller jusqu'à 512 bits avant rupture de champ). D'autant qu'il est vraisemblable que les champs d'un bit soient simplement gérés avec les opérations de bit test (BT, BTC, BTR et BTS).

La taille de la structure est toujours arrondie à des multiples de 8, 16, 32 voire 64. Ce qui, combiné avec les alignements mémoires, peut se traduire par une consommation de nx32 voire nx64 bits. L'argument de l'économie de place n'est donc pas très fort.

De même l'argument d'efficacité n'est pas moteur, car l'extraction, même si elle est masquée, prend plus de temps qu'accéder à un élément de base. L'exemple souvent donnée d'une date y:12, m:4, d:5 en est la démonstration. Les 21 bits impliquent un mot de 32 bits pour les accueillir soit la même place que uint16_t y, uint8_t m, uint8_t d qui présente une accessibilité directe (les champs restent adressables).

Cependant les champs de bits sont particulièrement pratiques dans les protocoles de transmission car ils facilitent la sérialisation. Ils sont intéressants également dans les unions où ils peuvent donner un accès simple à des parties, par exemple aux couleurs sur 16 bits (G:6, R:5, B:5), tout en pouvant les manipuler comme uint16_t.

De plus, les champs de bits peuvent servir à implémenter des set en C (certes limités).

Salut

Le tout est est de savoir si s'est optimisé automatiquent ou s'il faut donner un coup de pouce :

Posons dans la structure :

Code:

---

1 2 3 4 5

BYTE Idle : 7; BYTE Fct : 7; BYTE Status : 1; BYTE Data : 1;

---

En tout nous avons 16 bits soit 2 octets.

Malheureusement, le sizeof, dans ce cas présent, nous donne 3 octets !
Par conséquent, rien ne semble optimisé !

Donnons maintenant un petit coup de pouce :

Code:

---

1 2 3 4 5

BYTE Idle : 7; BYTE Status : 1; BYTE Fct : 7; BYTE Data : 1;

---

Le sizeof, donne cette fois ci, 2 octets !

Mais le problème, c'est que je ne sais pas, à priori comment ça s'organise et on pourra toujours me garantir que ...
Moi ... je traite les champs de bits manuellement pour être sûr de ce que je fais !

Vous voulez un petit exemple :
Le status byte d'un message MIDI : 1fffcccc (bit7 à 1, fff : 8 fonctions, cccc : 16 canaux)
Dans ce domaine (musique) on a intérêt à rester dans les rails (et c'est vrai aussi pour mes locomotives) !

Bonjour,

Il n'y a pas d'optimisation par réordonnancement et c'est une bonne chose si les données devaient être sérialisées.

Il est vraisemblable que l'exemple donné par henderson soit vers un MPU 8 bits auquel cas 7711 et 1177 ne peuvent tenir sur 2 octet (et non pas 16 bits), mais que 1717, 7171, 1771 et 7117 le peuvent. On peut alors supposer que, dans ce cas de figure, un champ de plus de 8 bits poserait problème.

Pièce jointe 670100
Ce qu'il faudrait faire en 8 bits pour récupérer le champ à cheval

Pièce jointe 670101
Et pourquoi on préfère un format plus grand

La règle est qu'il y a risque de fractionnement si la longueur totale des champs dépasse le plus grand format naturel entier de la cible.

Salutations

Bonjour à tous, merci pour vos réponses et précisions,
J'ai fait un test avec sizeof elle renvoie 2 octets, je tente importer une structure vers Delphi si je n'ajoute pas 2 autres octets derrière cette structure(celle des champs de bits) toutes les valeurs des autres champs sont farfelues.

Bonjour,

Sauf erreur, il n'y a pas de champs de bits sous Delphi. Les set s'en rapprochent un peu, mais les bits y sont individualisés (un bit = présence ou absence d'un élément du set). Bien sûr, on peut créer un objet champ de bit qui en aura les fonctionnalités, mais pas l'implémentation, et donc pas les mêmes contraintes. Notamment celles du C et du CPU cible.

Salutations

J'ai jetté un oeil dans la norme C99 (je suppose que ça n'a pas fondalement dû changer depuis) pour obtenir une réponse "officielle".

Page 102, la point 10 de la section 6.7.2.1 Structure and union specifiers dit :

A

Citation:

---

An implementation may allocate any addressable storage unit large enough to hold a bit-
field. If enough space remains, a bit-field that immediately follows another bit-field in a
structure shall be packed into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is
implementation-defined. The order of allocation of bit-fields within a unit (high-order to
low-order or low-order to high-order) is implementation-defined. The alignment of the
addressable storage unit is unspecified

---

Page suivante, le point 12 dit :

Citation:

---

Each non-bit-field member of a structure or union object is aligned in an implementation-
defined manner appropriate to its type

---

Et enfin, point 13 :

Citation:

---

Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a
structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
padding within a structure object, but not at its beginning.

---

Pour reprendre la question initiale :

Citation:

---

je souhaite comprendre la règle qui gère l'alignement des champs dans C Microsoft

---

C'est le point 12 cité ci-dessus qui s'applique : c'est implementation-defined. La fin du point 9 va aussi dans ce sens (c'est même pire puisque c'est unspecified).

Pour la seconde question :

Citation:

---

Quelle est la taille de cette structure ?

---

La taille de la structure est a priori également non prédictible. Le point 13 dit qu'on ne peut pas réagencer les membres, et le point 12 dit que les champs sont regroupés dans des unités, sans overlap. On devrait donc pouvoir faire un calcul pour retrouver la taille totale. Toutefois, j'interprète la 1ère phrase de ce point 12 comme : l'unité de stockage peut être de n'importe quelle taille, et donc on ne peut pas vraiment savoir quelle taille aura la structure globale. Vous comprenez aussi ça comme ça ?

PS : j'ai un exemple qui semble confirmer mon interprétation.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> #include <stdint.h>   struct Foo { uint16_t foo:7; uint32_t bar:7; uint32_t zorg; };   int main() { printf("%lu\n", sizeof(struct Foo)); }

---

Il affiche 8 sur Compiler Explorer, ce qui implique que les types indiqués pour les 2 champs de bits n'ont pas été respectés, car sinon la taille sera 10 (voire plutôt 12 avec le probable padding).

Bonjour,

J'interprète l'exemple de Bktero ainsi :

• Si la cible est une machine 64 bit, il a 7+7+32 = 46 bits donc 1x64 bits d'hébergement soit 8 octets.
• Je ne crois pas qu'il utilise l'hétérogénéité (mélange de types d'hébergement), donc sur une machine 32 bits : 2x32 bits soit 8 octets (et non 1x16 bits + 1x32 bits soit 6 octets).
• Sur les cibles inférieures, je pense qu'il doit refuser l'obstacle.

Salutations