Codage du float et structure

Résolu/Fermé

jehutyy Messages postés 51 Date d'inscription lundi 5 septembre 2011 Statut Membre Dernière intervention 1 mai 2015 - 20 avril 2012 à 12:55
nicocorico Messages postés 799 Date d'inscription dimanche 19 juin 2011 Statut Membre Dernière intervention 3 juillet 2018 - 20 avril 2012 à 18:37

Bonjour,

Voila mon soucis, je suis en pleine révision et j'ai un petit problème
On me demande de donner la taille en octet de structure.

typedef struct matiere{
char nom;
float coef;
}matiere;

voila la structure dont je dois calculer la taille, selon moi un char est codé sur 1 octet et un float sur 4 octets donc apriori la taille de la structure serai de 5 octets.
Or en faisant printf("%d", sizeof(matiere)), le résultat est 8.

Je ne comprend pas le résultat et donc ai du mal a l'interpréter.

En espérant m'être fait comprendre, j'espère que vous pourrez m'aider.

cordialement
jehutyy

A voir également:

Codage du float et structure
Codage ascii - Guide
Codage binaire - Guide
Logiciel calcul structure bois gratuit - Télécharger - Architecture & Déco
Structure d'un rapport de stage - Guide
Fichier word illisible codage - Guide

1 réponse

Réponse 1 / 1

Char Snipeur Messages postés 9813 Date d'inscription vendredi 23 avril 2004 Statut Contributeur Dernière intervention 3 octobre 2023 1 298
20 avril 2012 à 16:08

Salut.
En ISO C une structure n'a pas de taille définie, a taille dépendra de l'implementation du compilateur et d'options de compilation.
Sa taille minimum est bien entendu celle de ses membres. Mais ensuite, pour des raisons de rapidité, les données sont alignés en mémoire selon une alternance de 4 octet je crois (je n'ai pas compris exactement la raison profonde du bazard). L'alignement veux dire que le compilateur laisse de la place de libre entre ta première variable et la seconde. C'est pour ça qu'on recommande de mettre dans les structures en premier les variables les plus grosses et de finir par les plus petites.

Pour reprendre ton exemple, il y a 3 octets d'inutiles entre nom et coef.
Par contre, tu empiles les petites variables, ainsi struct{char a[4];float coef;} devrait aussi valoir 8. Si tu passes à a[5] la taille devrait être de 12 etc.

En espérant avoir été claire. Sinon, je te passerai la référence du livre électronique où j'ai lu cette explication.

le père
20 avril 2012 à 16:24

je n'ai pas compris exactement la raison profonde du bazard
C'est que les processeurs ont aujourd'hui des bus de données de plus de 8 bits, par exemple 32 bits (=4 octets)
Je raisonne sur une machine en little endian ( poids faible à l'adresse faible)
Si tu as une structure
char a
int b;
sans 'laisser de trou' entre les deux, pour aller lire b, le processeur va être obligé de faire 2 lectures. Car les accès ne se font pas par octet, mais par paquets de 4 octets.
Si b est 'bien cadré',la première lecture donnera b et 3 octets de a, la seconde le dernier octet de a.De plus, le processeur sera obligé de décaler les bits car lors de la 1ère lecture, il faudra ranger les bits 8 à 31 du bus de données dans les bits 0 à 23 du processeur, et idem (enfin, avec d'autres bits) pour la seconde lecture.

nicocorico Messages postés 799 Date d'inscription dimanche 19 juin 2011 Statut Membre Dernière intervention 3 juillet 2018 138
20 avril 2012 à 17:05

Pas exactement, le processeur n'a aucun problème à accéder directement à 8 ou 16 bits même à une position décalée à 1 octet près. Cependant, c'est en mémoire cache que le problème se pose, car elle lit 32 bits alignés sur 4 octets uniquement -mod (not(03))- et donc c'est pour les valeurs supérieures à 1 octet que le problème se pose lorsqu'elles chevauchent 2 dwords, impliquant que la mémoire cache charge 2 dwords...entrainant une petite carence en vitesse de lecture et un gonflement de la mémoire cache, mais c'est vrai pour les valeurs alignées aussi.
Un bon contournement de ce problème consiste donc à faire des enregistrements compactés, pour le gain en espace, mais dans lequel on place tous les dwords en 1er, les words ensuite puis les octets. Les enregistrements devant idéalement être alignés tout de même entre eux.

le père
20 avril 2012 à 17:57

donc c'est pour les valeurs supérieures à 1 octet que le problème se pose lorsqu'elles chevauchent 2 dwords,
C'est ce que je croyais avoir dir, à ceci près que j'ignorais que le problème ne se posait que pour la mémoire cache. Je ne comprends pas pourquoi il ne se pose pas pour la mémoire externe, mais j'avoue avoir de compétences très limitées sur le sujet. Mon éducation dans ce domaine remonte à un stage sur le 8086, sans mémoire cache et pas capable de lire un mot de 16 bits cadré sur une adresse impaire (si ma mémoire ne me trahit pas...)
Merci pour la précision

nicocorico Messages postés 799 Date d'inscription dimanche 19 juin 2011 Statut Membre Dernière intervention 3 juillet 2018 138
20 avril 2012 à 18:37

oui en fait je voulais préciser que le processeur n'a nul besoin de décaler pour accéder à une valeur non alignée, et que le seul problème est sur le temps de chargement de deux dword au lieu d'un à partir du moment où on lit une valeur supérieure à 1 octet à une adresse finissant par 3, par exemple. Mais ce problème est inexistant si on accède aussi aux valeurs alentour, les valeurs étant alors déjà en cache. Donc en fait l'unique problème porte sur l'accés aux dword s'ils ne sont pas alignés sur 4 octets et qu'on ne les lit qu'une fois de temps en temps...autrement dit pour moi il vaut mieux faire que des enregistrements compactés, permettant globalement d'économiser la mémoire vive et les 2 niveaux de mémoire cache.
Quant à l'accés à la mémoire externe, il se fait sur 64 bits ce qui limite le problème.

Discussions similaires

controleur de codage/décodage PCI

Codage de texte

huffman

Table des matières dont les titres n'apparaissent pas..

Aider moi à codée S.V.P