Ces variables temporaires... - Page 1

Dans une source en C, on a toujours besoin d'un petit pack de variables pour faire quelques calculs, des variables qui ne serviront qu'une dizaine de lignes, et après qu'on utilisera plus.

Alors au lieu de créer au tout début de main() un petit set de variables locales standard, comme handle1, handle2, SymPtr1, Symptr2, etc. qui serviront tout au long du programme comme variable temporaires à différents endroits, ce qui ne rend pas super claire la source, je me suis dis pourquoi ne pas faire à chaque fois que j'ai besoin de variables temporaires un petit bloc avec des variables locales qui n'appartient qu'à ce petit bloc.

cad au milieu du programme :

...
{
HANDLE HandleOfTheList; // les var temporaires
SYM_ENTRY *PrgmSymPtr;

<le petit calcul a effectuer

}
...

Ce qui permet d'avoir des noms de variables temporaires un peu plus parlant.
Mais je me suis demandé comment le compilo se débrouillait pour gérer ça (il utilise un autre pointeur sur la pile des variables ? il utilise la même pile ? si c'est le cas les variables temporaires d'un autre bloc pourront prendre plus tard la même place sur la pile ?)
Et finalement ça revient au même que de créer toutes ces variables au tout début de main() : les variables temporaires des différents blocs sont créées dès le début sur la pile de variable de main(). Ca veut dire que si on crée tout plein de petits bloc ({}) comme ça, toute la pile sera mangée dès le lancement du programme, c'est pas une bonne solution. La seule utilité est que dans 2 blocs différents on peut utiliser le même nom de variable, c'est tout.

Alors comment faites vous pour gérer ce problème, pour obtenir une source lisible ?

Normalement l'optimiseur de GCC est censé se rendre compte que les 2 variables peuvent occuper le même endroit sur la pile (voire le même registre) parce qu'elles ne sont pas actives en même temps.

Bizarre, dans le petit test que j'avais fait il ne se rendait pas compte

Tu as essayé avec quelle version de GCC?

Je ne comprend rien à ta question

Tu peux la résumer clairement s'il te plaît ?

Thibaut : Quoi, je suis pas clair ? J'ai fais ce que je pouvais, relis. Et puis Kevin a très bien compris

Kevin : j'utilise la v3.0.4.

Par exemple ça (compilé avec ffixed-a2 -ffixed-a3 -ffixed-a4 -ffixed-d3 -ffixed-d4 -ffixed-d5 -ffixed-d6 -ffixed-d7 pour qu'il utilise absolument la pile pour mettre stocker les variables) : void _main(void) {      short i = ngetchx();  {       short     j = ngetchx();       ngetchx();    // pour que la variable       pushkey (j);  // soit vraiment stockée  }  {       short     k = kbhit();      ngetchx();      pushkey (k);  }      pushkey (i); }

me donne ça :      move.l 0xC8,%a5 #NO_APP      link.w %a6,#-8 #$00010     ngetchx();     {   shortj =      move.l 324(%a5),%a1      jbsr (%a1)      move.w %d0,-2(%a6) #$0001A     ngetchx();      move.l 324(%a5),%a1      jbsr (%a1)      move.w %d0,-4(%a6) #$00024     ngetchx();    // pour que la variable      move.l 324(%a5),%a1      jbsr (%a1) #$0002A     pushkey (j);  // soit vraiment stockée   }     {   shortk =      move.w -4(%a6),-(%sp)      move.l 320(%a5),%a1      jbsr (%a1) #$00034     kbhit();      move.l 328(%a5),%a1      jbsr (%a1)      move.w %d0,-6(%a6) #$0003E     ngetchx();      move.l 324(%a5),%a1      jbsr (%a1) #$00044     pushkey (k);   }      move.w -6(%a6),-(%sp)      move.l 320(%a5),%a1      jbsr (%a1) #$0004E     pushkey (i);      move.w -2(%a6),-(%sp)      move.l 320(%a5),%a1      jbsr (%a1) #$00058     }      unlk %a6      rts
Il crée 2 espaces sur la pile pour stocker les variables j et k au lieu d'utiliser le même. Ou alors c'est parce que l'exemple et trop simple, dans un plus gros programme il optimiserait ça ?

oups, un peu trop fluo le vert des registres GNU asm.

Le code est presque le même avec TIGCC 0.94 Beta 19 (GCC 3.2-tigcc-1). Donc l'optimisation laisse à désirer. Mais si on laisse GCC mettre les variables dans les registres, il n'y a pas ce problème.

Ha j'ai relu, et j'ai compris ta question
Tu n'es pas clair

Théoriquement, l'espace est alloué en même temps que les variables "globales" de la fonction. La taille allouée est tout simplement la plus grande taille demandée par les blocs. Je suis pas clair ? on est quittes

Exemple :

void Fonction(void)
{
  short var_hierarchie_1;  // 2 octets
  
  // blabla
  
  {
    long var1_hierarchie_2;  // 4 octets
    char var2_hierarchie_2;  // 1 octet + alignement = 2 octets
                             // total : 6 octets
    // blabla
  }
  
  // blabla
  
  {
    char var1_hierarchie_2;  // 1 octet
    char var2_hierarchie_2;  // 1 octet
                             // total : 2 octets
    // blabla
  }
}

Combien d'espace va être alloué à l'entrée de la fonction ?
Déjà 2 octets pour var_hierarchie_1, puis 6 octets car parmi les blocs possédants des variables locales, le plus gourmand demande 6 octets.

Donc, le second bloc verra ses variables adressées dans les 4 premiers octets des 6 octets réservés aux "sous-variables locales".

===========

Voilà, ça c'est en théorie, mais GCC est vraiment très mauvais en optimisation, j'ai longtemps cru que c'était un bon compilo, mais en fait il est largement dépassé par les compilateurs commerciaux de M$ et... peut-être bientôt par Borland : les compilateurs de Borland produisent un code presque aussi bon que GCC, mais en un temps considérablement plus court.

Donc si j'ai bien compris iser en tant que char dans le deuxième bloc char var2_hierarchie_2;

 il faut optimiser manuellement. Dans ton exemple, il faudra déclarer:
  short var_hierarchie_1;
  long var1_hierarchie_2;  //que l'on pourra réutil

une déclaration dans un bloc ne servira qu'à la lisibilité...

... avec GCC !

Avec un compilateur mieux conçu, il n'y a pas de gaspillage de mémoire.

D'ailleurs je me rappelle que les premières version de GTC avaient ce même défaut.

On peut toujours utiliser ça:

int var1,var2,var3,var4;
{
 #define nomplusadaptepourcebloc var1
 #define autrenomadapte var2
 #define encoreunnomadapte var3
 #define etunquatrieme var4
 // ...
 #undef nomplusadaptepourcebloc
 #undef autrenomadapte
 #undef encoreunnomadapte
 #undef etunquatrieme
}
// ...
{
 #define toto var1
 #define foo var2
 #define bar var3
 #define baz var4
 // ...
 #undef toto
 #undef foo
 #undef bar
 #undef baz
}

Ça permet de réutiliser les variables tout en changeant leurs noms.