forcer TIGCC a utiliser les registres - Page 1

-

Tu peux effectivement réécrire cette fonction toi même en ASM, ça n'est pas très compliqué comme fonction.

Sinon, tu peux essayer :

{
  register short i,j,k;
  nvertex1=0;
  for(k=0;k<30;k+=5)
  {
    for(j=0;j<30;j+=5)
    {
      for(i=0;i<30;i+=5)
      {
        objdata1[nvertex1  ].x=i-15;
        objdata1[nvertex1  ].y=j-15;
        objdata1[nvertex1++].z=k-15;
      }
    }
  }
}

Ton code est pas très optimisé. Je sais pas si c'est important ?

-

Sasume :
Tu peux effectivement réécrire cette fonction toi même en ASM, àa n'est pas très compliqué comme fonction.

Sinon, tu peux essayer :

{
  register short i,j,k;
[...]
}

Ça ne sert à rien. GCC se contrefiche du mot-clé register. Il faut lui donner un registre spécifique à utiliser pour qu'il le fasse vraiment, style:
register short i asm("d0"),j asm("d1"),k asm("d2");

Ah, c'est dommage.
Pourquoi ça ?
Si on spécifieun registre qui était utilisé par quelque chose avant, ça fait qu ce qq ch doit être sauvé autre part ? Ou bien GCC se débrouille pour ne rien mettre qui doive être retrouvé après ?
(je ne sais pas si c'est très clair ma question)

-

Tu compiles avec -O3 ?

(ou -O2 ou -Os ou même -O, ça ne devrait rien changer dans ce cas)

Je comprends pas comment il peut perdre autant d'octets sur si peu de code, à moins que les boucles soient déroulées (-O3).

Ah, bon, c'est pour ça que tu parlais de -O3. Mais -funroll-loops est aussi activé en -O2. Pour optimiser en taille, c'est -Os qu'il faut mettre et pas autre chose.

Quelque chose me dit que Orion compilait en -Os

Heu, Kevin, il me semble que GCC comprend le mot cle register. Si, si. Du moins, gcc 2.95.

-

PpHd
:Heu, Kevin, il me semble que GCC comprend le mot cle register. Si, si. Du moins, gcc 2.95.

Il comprend, mais il ne l'utilise pas.

Orion_ :
j'ai besoin de place pas de vitesse !! (./4)

Des conseils pour optimiser mieux en taille?
* Utiliser la version la plus récente de GCC (3.3.1-tigcc-pre19).
* inline est à proscrire sauf pour les fonctions appelées exactement une fois, qui elles doivent être déclarées static inline.
* goto peut être très utile pour gagner de la place.
* Regarde du côté de USE_FLINE_ROM_CALLS.

pour les fonctions appelées exactement une fois

Euh, ça marche aussi pour les fonctions appelées zéro fois...

LOL
Les fonctions appelées 0 fois, je conseille de les supprimer tout simplement.

Si elles sont declarees static inline, elles ne consomeront que 0 octets

Certes, mais autant les mettre en #if 0.

-

Bah de toute façon, si tu fais un petit prog qui a besoin d'une lib plus ou moins grosse, ça casse tout.

C'est un peu de la triche, tant que tu y es, fais un prog d'une dizaine d'octets qui fait simplement un jmp lib@0000...

Arg... On est reparti dans ce calcul infame de savoir s'il faut oui ou non inclure les libs dans la taille du programme. Pour changer, je dirais que ca a pas de sens.

Bah disons que là, son but est de faire un programme tout petit, donc pour mesurer correctement, il faut que son exe contienne TOUT le code (excéptés les ROM_CALL).

A la rigueur, ce qui aurait un sens, ce serait de calculer la consommation RAM complete. Puis c'est tout.

merci pour les conseils, permet moi juste de faire une remarque
ton " " est un peu paradoxal, je dit que je veut optimiser en place un prog, alors que tu preconise le nostub qui repete les même fonctions de tigcclib dans tout les programmes contrairement à une lib dynamique kernel qui prend beaucoup moins de place au final si beaucoup de programme l'utilise (rien que si on faisait une lib pour les NVG ça serait déja 900octets * le nombre de prog qui utilise les gray en moins )

C'est plus ou moins vrai. Mais ca dépends énormément de la situation.
Si le prog est très court il peut-être avantageux de ce passer de la taille du stub.
Et certaines libraires sont assez folkloriques(ne servent qu'a 1 ou 2 programmes) et petites pour que la lib dynamique ne soient pas rentable.

PpHd
: A la rigueur, ce qui aurait un sens, ce serait de calculer la consommation RAM complete. Puis c'est tout.

Son défi n'est pas la consommation en RAM, mais la taille du code. Si du code est caché dans une librairie dynamique, c'est de la triche.

Mais c'etait juste pour dire que justement ca n'avait pas de sens.

Ben si. Programme plus petit = moins de mémoire archive consommée.

Oui mais alors on repard dans nos comptages d'octets et de differentes configuration types.