Discussion :

[Guyt54]

On n'a pas eu la réponse à la question de gangsoleil me semble t-il ^^


Un jour, il faudrait que je regarde l'assembleur généré pour voir ce que ça fait

Pour la question de gangsoleil, j'ai fait des tests avec les deux premières versions de "BinToHexChar":

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
char BinToHexChar1(int data)
// Code: 14 bytes
{
  char c ;

  c= data&0xF ;
  c=(c<10)?c+48:c+55;
  return c ;
}
char BinToHexChar2(int data)
// Code: 14 bytes

{
  char car ;

  car = data & 0xF ;
  if (car < 10)
    car = car + '0' ;
  else
    car = car - 10 + 'A' ;
  return car ;
}

Peut importe les options d'optimisations choisies, les deux versions sont toujours vu comme étant identiques par le compilateur.

L'opérateur "?" a finalement un seul intérêt: minimiser le nombre de touche à taper, en supposant que ça soit une priorité.

J'ai vu un sujet qui rejoint pas mal de quoi on parle ici, je vais le rejoindre.

A+

[prgasp77]

Pour l'approche "table lookup", je vous reviens là-dessus, y a des résultats qui me surprennent.

Ca me rassure de voir qu'ici ou ailleurs, les profs distribuent toujours les copies bien plus tard qu'ils ne les avaient annoncées .

[Guyt54]

Ca me rassure de voir qu'ici ou ailleurs, les profs distribuent toujours les copies bien plus tard qu'ils ne les avaient annoncées .

C'est que les résultats obtenus remettent en question mes convictions les plus profondes, alors j’hésite à les publier

[Guyt54]

Bon voilà, j'ai regardé ce que donnait l'autre variante de la fonction "BinToHexChar", celle avec une table de "lookup" tel que proposé prgasp77:

Code :

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

1
2
3
4
5
6
char BinToHexByte5B(int data)
{
  static const char* digits = "0123456789ABCDF" ;
  return digits[data & 0x0F] ;
}

Comme je m'y attendais, la taille est plus grande, soit 20 octets pour la fonction à la quelle on ajoute 18 bytes dans le segment code pour l'initialisation de la chaine digits (le +2, c'est pour le NULL et le fait que le code est sur 16 bits pour un atmel).

Je me suis ensuite amusé avec les quatre possibilités de définitions de la chaine "digits", soit:

Code :

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

1
2
3
4
5
   static const char* digits = "0123456789ABCDF" ;
   static char* digits = "0123456789ABCDF" ;
   const char* digits = "0123456789ABCDF" ;
   char* digits = "0123456789ABCDF" ;

Première constatation: le qualificatif "const" n'a aucun effet sur le code généré.

Deuxième constatation: contre toute attente, la version optimalisée ( 8 octets de moins!), est obtenue avec:

Code :

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

1
2
3
4
5
6
char BinToHexByte5B(int data)
{
  char* digits = "0123456789ABCDF" ;
  return digits[data & 0x0F] ;
}

Si un étudiant m'arrivait avec la fonction précédente, je lui expliquerais que puisque la variable "digits" est définie localement, son contenu sera réinitialisé à chaque appel de la fonction, ce qui n'est pas exact dans ce cas-ci, "digits" a été mis dans le code segment (en flash, donc non modifiable!).

Bon, je veux bien comprendre que les compilateurs sont de plus en plus intelligent. Comme il voit bien que "digits" n'est pas modifié, aussi bien mettre ses valeurs figées en ROM. Mais générer du code plus court si on omet "static const"? Là, je suis flabbergasté...

[prgasp77]

Bon, je veux bien comprendre que les compilateurs sont de plus en plus intelligent. Comme il voit bien que "digits" n'est pas modifié, aussi bien mettre ses valeurs figées en ROM. Mais générer du code plus court si on omet "static const"? Là, je suis flabbergasté...

Effectivement ... c'est vraiment étrange. Pourrait-on voir le code objet généré ? Pourquoi le compilateur trait-t-il différemment les deux versions de la fonction oO ?



PS:

C'est que les résultats obtenus remettent en question mes convictions les plus profondes, alors j’hésite à les publier

C'est l'effet tiroir !

[Guyt54]

Pourquoi le compilateur trait-t-il différemment les deux versions de la fonction oO ?

Pour le code en asm, version "static const char* digits":

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
24
25
26
27
@00000041: BinToHexByte5A
---- test_cpy.c -----------------------------------------------------------------------------------
3:        {
+00000041:   708F        ANDI      R24,0x0F       Logical AND with immediate
+00000042:   7090        ANDI      R25,0x00       Logical AND with immediate
+00000043:   91E00070    LDS       R30,0x0070     Load direct from data space
+00000045:   91F00071    LDS       R31,0x0071     Load direct from data space
+00000047:   0FE8        ADD       R30,R24        Add without carry
+00000048:   1FF9        ADC       R31,R25        Add with carry
7:        }
+00000049:   8180        LDD       R24,Z+0        Load indirect with displacement
+0000004A:   9508        RET                      Subroutine return
@0000004B: main
19:       {
+0000004B:   CFFF        RJMP      PC-0x0000      Relative jump
19:       {
+0000004C:   94F8        CLI                      Global Interrupt Disable
+0000004D:   CFFF        RJMP      PC-0x0000      Relative jump
+0000004E:   3130        CPI       R19,0x10       Compare with immediate
+0000004F:   3332        CPI       R19,0x32       Compare with immediate
+00000050:   3534        CPI       R19,0x54       Compare with immediate
+00000051:   3736        CPI       R19,0x76       Compare with immediate
+00000052:   3938        CPI       R19,0x98       Compare with immediate
+00000053:   4241        SBCI      R20,0x21       Subtract immediate with carry
+00000054:   4443        SBCI      R20,0x43       Subtract immediate with carry
+00000055:   0046        ???                      Data or unknown opcode

Version char* digits:

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
24
25
26
27
@00000041: BinToHexByte5B
---- test_cpy.c -----------------------------------------------------------------------------------
11:       {
+00000041:   01FC        MOVW      R30,R24        Copy register pair
+00000042:   70EF        ANDI      R30,0x0F       Logical AND with immediate
+00000043:   70F0        ANDI      R31,0x00       Logical AND with immediate
+00000044:   5AE0        SUBI      R30,0xA0       Subtract immediate
+00000045:   4FFF        SBCI      R31,0xFF       Subtract immediate with carry
14:       }
+00000046:   8180        LDD       R24,Z+0        Load indirect with displacement
+00000047:   9508        RET                      Subroutine return
@00000048: main
19:       {
+00000048:   CFFF        RJMP      PC-0x0000      Relative jump
19:       {
+00000049:   94F8        CLI                      Global Interrupt Disable
+0000004A:   CFFF        RJMP      PC-0x0000      Relative jump
+0000004B:   3130        CPI       R19,0x10       Compare with immediate
+0000004C:   3332        CPI       R19,0x32       Compare with immediate
+0000004D:   3534        CPI       R19,0x54       Compare with immediate
+0000004E:   3736        CPI       R19,0x76       Compare with immediate
+0000004F:   3938        CPI       R19,0x98       Compare with immediate
+00000050:   4241        SBCI      R20,0x21       Subtract immediate with carry
+00000051:   4443        SBCI      R20,0x43       Subtract immediate with carry
+00000052:   4645        SBCI      R20,0x65       Subtract immediate with carry
+00000053:   0000        NOP                      No operation

Dans les deux cas, la table est mis dans le code (dans le main), mais le code pour l’accéder est différent. Comme disait Brigitte Bardot quand elle est venue sur notre banquise, "Ouatte de phoque???"

[3DArchi]

Première constatation: le qualificatif "const" n'a aucun effet sur le code généré.

C'est pas son objectif premier. const est donne une information sémantique au compilateur et apporte une contrainte à ce moment. En revanche, le compilateur ne peut systématique s'appuyer dessus pour une optimisation ou un placement en mémoire (à l'exception du static const).