Version imprimable
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.
Quelle est la taille de cette structure ?Code:
2
3
4
5
6
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
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.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.
Salut,
Sa taille est définie par l'implémentation et ici elle a pour valeur sizeof(struct tag_struc).Citation:
Envoyé par Mist2024
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,
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).Citation:
Envoyé par foetus
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 :
En tout nous avons 16 bits soit 2 octets.Code:
2
3
4
5
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 :
Le sizeof, donne cette fois ci, 2 octets !Code:
2
3
4
5
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 :
APage suivante, le point 12 dit :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
Et enfin, point 13 :Citation:
Each non-bit-field member of a structure or union object is aligned in an implementation-
defined manner appropriate to its type
Pour reprendre la question initiale :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.
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).Citation:
je souhaite comprendre la règle qui gère l'alignement des champs dans C Microsoft
Pour la seconde question :
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 ?Citation:
Quelle est la taille de cette structure ?
PS : j'ai un exemple qui semble confirmer mon interprétation.
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).Code:
2
3
4
5
6
7
8
9
10
11
12
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
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
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 :aie: ). À 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.
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.
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 ?Citation:
Envoyé par kaitlyn
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.Citation:
Envoyé par kaitlyn
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é.Citation:
Envoyé par kaitlyn
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:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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 :
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.Code:
2
3
4
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.
Bonjour,
Oui c'est prédictible mais cela demande de regarder toute la doc (mais qui le fait ? :oops: ). 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
Bonjour dalfab,
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).Citation:
Envoyé par dalfab
Salutations
Again : es-tu capable de me pointer la documentation de GCC qui explique ce comportement ? :?Citation:
Envoyé par Guesset
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 :aie:
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é :
Juste pour bien fixer les choses !Code:
2
3
4
5
6
7
8
