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

[Mist2024]

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.

[Guesset]

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

[Bktero]

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

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 :

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 :

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 :

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 :

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 :

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

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

[Guesset]

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

[boboss123]

Personnellement, j'évite d'utiliser ce genre de choses vu que l'implémentation peut dépendre du compilateur, de la plateforme et des paramètres d'optimisation.
... donc à chaque fois que tu modifies l'un des ces paramètres, il faut revalider que tout est bon.

Surtout que l'endianness peut aussi avoir un impacte : https://incenp.org/notes/2017/c-endianness.html

[kaitlyn]

Salut,

Attention @Bktero à la confusion entre l'action d'agencer et celle d'ordonner, leurs définitions sont bien différentes.

Après, effectivement, du point de vue du standard (pour des motifs historiques), il y a une très grande liberté quant aux champs de bits. Le tout pouvant changer de manière assez radicale en fonction d'options de compilation (toutefois bien spécifiques) et des leviers à dispositions.
En fait, en terrain inconnu, les seules manières d'avoir une certitude quant à l'organisation interne de ces structures sont les tests de précompilation, d'autoconfiguration, d'assertion, éventuellement de réflexion.

Cela dit, dans la pratique, les compilateurs ont tout intérêt à forcer une certaine constance, et ils le font, ne serait-ce que pour des raisons d'interfaçages binaires (ABI) notamment avec le système hôte. Je pense par exemple à Win32, si c'est l'objet de cette discussion. Ou encore aux standards industriels automobile et aérospatial, où ce genre de structure, bien que très encadrée, sert à mapper des registres matériels ou de trames de bus, si ça peut rassurer certains (@henderson, @boboss123).
Donc, pour un compilateur donné, un écosystème donné, les risques de se fourvoyer sont quand même assez faibles, et la résultante tout à fait prédictible. Il suffit d'adopter quelques règles de prudence ou de lire la doc du compilateur en question pour savoir exactement ce qu'il en sera.
Au passage, c'est ce qu'a fait @Obsidian dans son message, que j'avais complété par le mien. Ensuite @foetus est passé (dire bonjour, désolée, je n'ai pas pu m'empêcher ). À sa décharge, il n'avait pas remarqué les points de suspension de la ligne 5

Plus sérieusement, les seuls problèmes que posent vraiment les champs de bits sont la portabilité et l'interopérabilité.
Pour le premier, un test de boutisme (ou d'endianess) est généralement suffisant, le second nécessite une sérialisation (ou conversion) vers un adressage conventionnel (tcp/ip, idl, ...). En plus, rien n'interdit d'implémenter des interfaces (éventuellement patterns) de type proxy ou façades, par exemple.

Pour en revenir à l'objet de cette discussion, le principal intéressé et certains autres sur le forum restent quand même assez évasifs dans leurs messages ou leurs besoins réels (conf. le message avec Delphi). Ce faisant, ils se privent de réponses adéquates avec des solutions claires et précises. C'est dommage qu'ils ne s'en rendent pas compte, enfin, surtout pour eux.

[boboss123]

Je tiens à préciser que je programme essentiellement sur µControlleur, l'architecture (passage de 8 à 32bits, passage de MIPS à ARM, ...) et la toolchain peut changer d'un projet à l'autre. J'ai déjà eu des cas où juste le fait de mettre à jour la toolchain apportait des problèmes, c'est pour ça que je suis assez sensible à ce type de problématiques qui sont beaucoup moins fréquentes que sur PC : donc moins j'utilise de cas indéterminés par la norme, moins je risque de devoir faire de modifications lors d'une migration.

[Bktero]

Attention @Bktero à la confusion entre l'action d'agencer et celle d'ordonner, leurs définitions sont bien différentes.

Oui enfin bon, le Robert donne "agencer" comme premier synonyme de "ordonner". Donc je veux bien qu'on puisse faire une nuance, mais je pense que c'était quand même clair, non ?

Il suffit d'adopter quelques règles de prudence ou de lire la doc du compilateur en question pour savoir exactement ce qu'il en sera.

Sais-tu me dire où sont documentés les "implementation-defined behaviors" pour chaque version de GCC pour chaque architecture ? C'est une information que je n'ai jamais vu passer.

Donc, pour un compilateur donné, un écosystème donné, les risques de se fourvoyer sont quand même assez faibles, et la résultante tout à fait prédictible.

Je vais aller dans le sens de @boboss123 : ton raisonnement est très centré PC, toujours sur la même architecture Intel x64. Se reposer sur des implementation-defined behaviors (encore pire : sur du undefined ou unspecified), c'est quand même risqué.

Et puis... Est-ce que la sortie de ce programme très simple est vraiment prédictible (en se basant sur la norme ou de la doc) ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <stdio.h>
#include <stdint.h>
 
struct Foo16 {
    uint16_t foo:7;
    uint32_t bar:7;
};
 
struct Foo32 {
    uint32_t foo:7;
    uint32_t bar:7;
};
 
struct Foo64 {
    uint64_t foo:7;
    uint32_t bar:7;
};
 
int main() {
    printf("%lu\n", sizeof(struct Foo16));
    printf("%lu\n", sizeof(struct Foo32));
    printf("%lu\n", sizeof(struct Foo64));
}

[dalfab]

Bonjour,

Il est facile de vérifier qu'il n'est pas prédictible en utilisant des compilateurs différents, en particuler MSVC ne donne pas les même valeurs que GCC.

De plus pour :

Code :

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

1
2
3
4
struct Foo64 {
    uint64_t foo:7;
    uint32_t bar:7;
};

un processeur 16 ou 32 bits peut aligner le uint64_t sur 2 ou 4 octets et forcément donner une taille de structure différente.

Et l'exemple suppose que sizeof retourne un résultat sous la forme d'un nombre d'octets. Ça n'est pas toujours le cas, c'est le nombre de char c-à-d le nombre de bytes; et il existe des processeurs qui n'ont pas d'accès octet, et alors le byte peut faire 16 ou 32 bits.
Donc pour ce dernier cas, on peut supposer comme possibles valeurs: 3, 4, 6, 8, 12, 16.

[Guesset]

Bonjour,

Oui c'est prédictible mais cela demande de regarder toute la doc (mais qui le fait ? ). Mais il n'est pas portable, alors la prédictibilité ne se limite pas à espérer un comportement invariant.

En fait, le niveau champs de bits est certainement l'un des plus bas offert par le C (je mets de côté l'asm embarqué). C'est pourquoi la portabilité du champs de bits n'est pas son point fort et son spectre d'usage est naturellement réduit.

Vouloir l'utiliser comme structure de haut niveau me paraît déconseillé (dépendance vis à vis du matériel). En revanche, pouvoir, par exemple, l'utiliser pour préparer des transmissions sérielles sur un MPU (de préférence 32 bits) reste tout à fait appréciable.

Salutations

[Guesset]

Bonjour dalfab,

...Un processeur 16 ou 32 bits peut aligner le uint64_t sur 2 ou 4 octets et forcément donner une taille de structure différente.

L'alignement mémoire fait perdre éventuellement de la place mais ce sont des trous entre structures qui ne changent pas leurs tailles individuelles. Dans le cas d'un champ de bits, il peut y avoir des trous au sein même de la structure si la taille globale est supérieure à celle du mot naturel de la cible. C'est trous n'ont pas vocation à faire de l'alignement mémoire mais à éviter qu'un champ soit à cheval sur deux mots. En effet, on n'accède pas à un champ de bits particulier par adresse (même si parfois on peut supposer que certains tombent pile poil).

Salutations

[Bktero]

Oui c'est prédictible mais cela demande de regarder toute la doc (mais qui le fait ? ).

Again : es-tu capable de me pointer la documentation de GCC qui explique ce comportement ?

PS : je trouve cette page mais rien sur les bit-fields par exemple.

PS2 : ah j'ai trouvé ! https://gcc.gnu.org/onlinedocs/gcc-1...mentation.html )=> Il faut maintenant savoir quelle ABI est utilisé et trouver sa doc

[henderson]

Pour en revenir au sujet initial, en partant du principe que l'on déclare un WORD comme conteneur des champs, j'aurais rajouté le champs non utilisé :

Code :

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

1
2
3
4
5
6
7
8
 
struct tag_struc{
    WORD    Champ1         :4;
    WORD    Champ2         :2;
    WORD    Champ3         :1; 
    WORD    NotUsed	   :9;    
...
} struc;

Juste pour bien fixer les choses !