Structure avec champs binaires - Page 1

Voilà je possède ce genre de structure:

typedef struct {
  union {
      unsigned char FACULT : 1, NOT_ATTRIB : 4, VARTABLE : 1, VAR : 1, VALUE : 1;
      unsigned char bit_field;
  } container;
		
   union { 
       unsigned char NOT_ATTRIB : 1, CANAL : 1, STRING : 1, BOOLEAN : 1, FLOAT : 1, S32 : 1, S16 : 1, U8 : 1;
       unsigned char bit_field;
   } type;
} GFA_lib_Param;

Je tests ma structure de cette façon:

printf("%d - %d\n", (short)params[j].container.bit_field, (short)params[j].type.bit_field);
printf("%d - %d\n", (short)params[j].container.VAR, (short)params[j].type.U8);

J'obtiens comme affichage:
2 - 15
0 - 0

Je ne comprend pas pourquoi j'obtiens 0 - 0 alors que je devrais obtenir 1 - 1.
Est-ce la structure mal rédigée? Ou une mauvaise utilisation. Bref comment résoudre ce pb?

Je ne vois pas

- Déclare une variable statique et regarde comment TIGCC génère son contenu (en explorant le .s généré)
- Combien vaut sizeof(GFA_lib_Param) ?

sizeof(GFA_lib_Param) est bien égal à 2:
Voici le code en ASM généré par TIGCC:

move.b 1(%a3),%d0
lsr.b #7,%d0
move.w %d0,%d1
and.w #1,%d1
move.w %d1,-(%sp)
move.b (%a3),%d0
lsr.b #7,%d0
move.w %d0,%d1
and.w #1,%d1
move.w %d1,-(%sp)
pea .LC0
jbsr (%a2)

%a3 est bien valide mais TIGCC reste obstiné par lsr.b #7
Le toto : 1 signifie bien que je prend 1 bit et non le bit 0 ?

> Le toto : 1 signifie bien que je prend 1 bit et non le bit 0 ?
Oui.

Mais l'utilisation de bit fields donne du code horriblement inefficace, comme tu peux le voir. C'est pareil avec (symptr->flags.bits.hidden) et ((symptr->flags.flags_n) & SF_HIDDEN) (j'écris de mémoire). En passant à la deuxième forme, j'ai gagné des dizaines d'octets dans tthdex et tictex/tictexpl.
Mon conseil est donc de passer à la deuxième forme: utiliser des & avec un masque #define'd. Tu peux même faire des macros pour te simplifier l'écriture.

TIGCC n'optimise pas ce genre de code? Par exemple dans des conditions? Inutile de faire un lsr, plutôt faire un simple and dans certains cas!
Bon j'ai trouvé le pb. Mon union est pas top:
Le code devient ainsi:

typedef struct {
  union {
     struct {
          unsigned char FACULT : 1;
          unsigned char NOT_ATTRIB : 4;
	  unsigned char VARTABLE : 1;
          unsigned char VAR : 1;
	  unsigned char VALUE : 1;
     };
     unsigned char bit_field;
  } container;
		
  union { 
      struct {
	  unsigned char NOT_ATTRIB : 1;
	  unsigned char CANAL : 1;
	  unsigned char STRING : 1;
	  unsigned char BOOLEAN : 1;
	  unsigned char FLOAT : 1;
	  unsigned char S32 : 1;
	  unsigned char S16 : 1;
	  unsigned char U8 : 1;
      };
      unsigned char bit_field;
   } type;
} GFA_lib_Param;

(pourquoi CANAL et pas CHANNEL )

Arf pas bête

> TIGCC n'optimise pas ce genre de code?
Je n'ai jamais vu le GCC de TIGCC donner du code correct en pareil cas, mais c'est peut-être parce qu'on écrit mal le code... Par exemple, des comparaisons == 1, alors qu'il suffit de les faire ( ) (la "feature" du C qui permet de tester si c'est non-zéro en rajoutant une paire de parenthèses !). Je ne sais pas, essaie
> Par exemple dans des conditions? Inutile de faire un lsr, plutôt faire un simple and dans certains cas!
Parfaitement d'accord.

moi je connais des compilo qui font du code optimisé dans ce genre de cas

des, ou un ?

au moins un

tous les compilos pour microcontrolleur gérent en général très bien celà.

GCC n'est malheureusement plus un compilo pour micro-contrôleurs. Les mainteneurs upstream le massacrent: casts-as-lvalue, cast constructor/compound literals, etc...
Je ne suis pas sûr qu'il l'ait jamais vraiment été, en fait.

Heuu a propos des bitfield, il faut faire gaffe a l'endianess et l'ordre d'écriture du bitfield... (j'ai eu des soucis a passer d'un x86 a un 68k a cause de bitfield..)

Lionel Debroux :
GCC n'est malheureusement plus un compilo pour micro-contrôleurs. Les mainteneurs upstream le massacrent: casts-as-lvalue, cast constructor/compound literals, etc...

casts-as-lvalue c'est vraiment pas indispensable du point de vue performance, le compilo pourrait très bien réécrire en interne *(int *)ptr = x, ptr+=sizeof(int) en *((int *)ptr)++ = x ^^
cast constructor je vois pas l'intérêt de l'extension GNU par rapport à la version prévue en C99 ?

Pour les casts-as-lvalue, outre la facilité d'écriture disparue dans le GCC upstream, si tu arrives à faire générer un code ressemblant à

move.b <ea>,(an)+
move.b <ea>,(an)+
move.w <ea>,(an)+
move.l <ea>,(an)+

au lieu d'un code ressemblant à

move.b <ea>,(an)
lea 1(an),an
move.b <ea>,(an)
lea 1(an),an
move.w <ea>,(an)
lea 2(an),an
move.l <ea>,(an)
lea 4(an),an

ou

move.b <ea>,(an)
move.b <ea>,1(an)
move.w <ea>,2(an)
move.l <ea>,4(an)
lea 8(an),an

à partir d'un
*((unsigned char *)ptr)++ = x;
*((unsigned char *)ptr)++ = y;
*((unsigned short *)ptr)++ = z;
*((unsigned long *)ptr)++ = t;

à GCC 4.x dans TI-Chess, je prends


Pour les cast constructors, Kevin a annulé des modifs stupides de GCC upstream, dont celles qui retardent au run-time le calcul des cast constructors constants, ce qui génère une quantité potentiellement importante de code totalement inutile, car ça se fait très bien au compile-time...
La taille de je ne sais plus quel programme de Zeljko explosait au-delà de 64K, alors que le programme en fait normalement beaucoup moins.
Mais je ne connais pas les finesses des standards, donc je ne sais pas ce que prévoient le standard C99 et l'extension GNU

j'ai pas dit que GCC générait effectivement du code optimisé, juste qu'au lieu de s'embêter avec des extensions bizarroïdes ça aurait été 100x plus simple d'implémenter proprement les optimisations correspondantes ^^ (de même que, je sais pas, on pourrait s'amuser à rajouter une instruction __rotate__(x,n), mais c'est nettement plus propre de détecter le motif x<<n | x>>32-n, parce que ça permet d'écrire du code portable facilement)

Pour les cast constructors, Kevin a annulé des modifs stupides de GCC upstream, dont celles qui retardent au run-time le calcul des cast constructors constants, ce qui génère une quantité potentiellement importante de code totalement inutile, car ça se fait très bien au compile-time...

c'est un problème du programme, ça : il suffit de déclarer les compound literals comme "const" pour qu'ils ne soient pas recopiés sur la pile, c'est permis par c99...