Discussion :

[Mist2024]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Obsidian]

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

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.

[kaitlyn]

Salut,

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).

[foetus]

Tiens bizarre personne n'a répondu sur la limitation des bits
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.

[Guesset]

Bonjour 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

[henderson]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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) !

[Guesset]

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.

Ce qu'il faudrait faire en 8 bits pour récupérer le champ à cheval


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