bonjour à tous,
voila si j'ai
struct A{
int m_value ;
char c;
}
struct B{
int m_value;
char c;
}__attribute__((packed))
B aura une taille de 5 octets alors que la structure de A aura une taille de 8 octets. Le compilateur rajoute des octets de padding mais pourquoi?
sur un pc 64 bits, le bus de donné et de 128 bits, donc on peut recupérer a chaque coup d'horloge jusqu'a 16 octets de mémoire. Donc si mon processus a besoin de récupérer la valeur de m_value quel est l'interet
d'ajouter des octets de padding. ca ne va rien changer car je peux lire facilement mon octets avec ou sans padding.
Merci d'avance pour votre aide
# À cause des accès aligné par les instructions en asm
Posté par ninis666 . Évalué à 4. Dernière modification le 12 septembre 2019 à 16:54.
En demandant à gcc de générer l'assembleur d'un truc qui itère sur des tableaux de A ou B, tu verras pourquoi :
C'est pourquoi il faut aligner correctement les champs des structures ou de n'utiliser les attributs d'alignement que si on n'a pas le choix …
De mon temps, c'était plus facile de lire l'assembleur produit par gcc, (c'était du 32 bits) !
[^] # Re: À cause des accès aligné par les instructions en asm
Posté par David Marec . Évalué à 6.
Précisez
-fverbose-asm
à GCC.[^] # Re: À cause des accès aligné par les instructions en asm
Posté par ninis666 . Évalué à 1.
Excellent, merci !
[^] # Re: À cause des accès aligné par les instructions en asm
Posté par AncalagonTotof . Évalué à 2.
De mon temps, c'était du 68000 ! Et puis j'ai fait un peu de 8086 … Que c'est moche …
Bref …
Pour la petite histoire, en embarqué, quand il s'agit de coller au plus près à l'architecture d'un microcontrôleur (Atmel, STM8 ou 32, Microchip PIC …), il est fréquent de "packer" à 1, histoire que tel champ corresponde à tel registre du CPU (sans trop rentrer dans les détails).
Et pour revenir au 68000, je me rappelle vaguement que tout était autorisé, y compris utiliser des adresses impaires, voire non multiples de 4, mais avec un surcoût à l'exécution. C'était pas gratuit …
Ça ne l'est toujours pas je suppose, ça fait des dizaines d'années que j'ai pas ouvert un bouquin d'assembleur de CPU.
<mode dystopie>Imaginez un peu, si IBM avait choisi Motorola à la place de Intel, fin des 70s, début des 80s … Le premier IBM PC avec un 68000 ! Le beau rôle ! Même pas de EMM386 ! Et le mauvais à Apple avec ses pauvres Apple ][ à base de 8088/8086 !</mode dystopie>
<mode réaliste>Le 68000 était pas sorti il me semble.</mode réaliste>
[^] # Re: À cause des accès aligné par les instructions en asm
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Voir aussi la configurabilité du comportement noyau en cas d'accès non aligné, sur certaines plateformes (ARM) → https://www.kernel.org/doc/html/latest/arm/mem_alignment.html
Debian Consultant @ DEBAMAX
[^] # Re: À cause des accès aligné par les instructions en asm
Posté par cosmoff . Évalué à 4.
dsl mais je n'ai pas compris ton explication, tout ce que je vois c'est du code assembleur^
[^] # Re: À cause des accès aligné par les instructions en asm
Posté par benoar . Évalué à 2.
En gros, le code utilisant la structure non-alignée est plus complexe et plus coûteux. Le padding qui te fait « perdre » de l'espace mémoire te fait gagner en performance et en compacité de code.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.