Pile et allocation mémoire - Page 3

>C'est vraiment débile de votre part de les inclure par défaut, de ne pas laisser le programmeur les choisir dans l'assistant de création de projets.
Qui t'empêche de mettre ça dans l'assistant toi-même ? Il me semble que tu as dis que tu connaissais le langage Delphi: vas-y, fais la modification toi-même. Ca sera sympa pour tout le monde...

on va peut-être dire que je manque d'originalité...


Mais on le sait très bien où elles sont ces options, mais personnellement, je dois chaque fois ouvrir la doc pour mettre les defines pour avoir un executable qui fasse moins de 100 octets. J'aimerais bien moi aussi qu'il existe une page pour choisir les options.
De plus le choix des options par défaut est plus que discutable, en particulier pour le support des exit

Vous n'avez qu'à les apprendre par cœur.

ma foi, qd on bosse sur des gros projets, c pas tous les jours qu'on crée un projet...

Pourquoi l'option OPTIMIZE_ROM_CALLS n'est pas active par défaut ?

Parce que ça ne marche pas avec les fonctions callback. (Il faut rajouter:
void *olda5=__jmp_tbl;
__jmp_tbl=*(void**)0xc8;
au début de ces callbacks et:
__jmp_tbl=olda5;
à la fin pour que ça marche.)

Heureusement que GTC a un "auto optimize ROM_CALLs"

Pourrais-tu préciser ce que c'est qu'un "auto optimize ROM_CALLs" ?

en gros il n'active optimize_rom_calls que quand il le juge nécessaire

A mon avis, c'est un peu bête (parce que l'utilisateur peut ne pas vouloir OPTIMIZE_ROM_CALLS).

> parce que l'utilisateur peut ne pas vouloir OPTIMIZE_ROM_CALLS
Ah oui, et pkoi? (ne me parle d'incompatibilité avec les callback puisqu'il n'y a pas de méthode gore de stockage comme dans TI-GCC)

Pollux
a écrit : (ne me parle d'incompatibilité avec les callback puisqu'il n'y a pas de méthode gore de stockage comme dans TI-GCC)

Tu fais comment pour avoir la bonne valeur en a5 alors? Tu la remets à chaque entrée de fonction? Ce n'est pas du vrai OPTIMIZE_ROM_CALLS alors. Le but de OPTIMIZE_ROM_CALLS est de ne charger l'adresse de la table des ROM_CALLs qu'une seule fois dans le programme.

... mais a5 reste disponible pour les fonctions qui ont besoin de bcp de registres ...

> parce que l'utilisateur peut ne pas vouloir OPTIMIZE_ROM_CALLS Ah oui, et pkoi? (ne me parle d'incompatibilité avec les callback puisqu'il n'y a pas de méthode gore de stockage comme dans TI-GCC)

pour avoir un regsitre de plus libre, notament si on n'utilise que peu de RC dans le programme, voila pkoi

avec une super vieille version de TIGCC (ça date de plus d'un an), j'ai gagné pas mal de place sur un gros prog utilisant peu de RC en supprimant le optimize_RC...

Pollux
a écrit : ... mais a5 reste disponible pour les fonctions qui ont besoin de bcp de registres ...

Certes. Mais l'optimisation des ROM_CALLs à l'intérieur d'une fonction n'est pas une innovation du tout. C'est le boulot de l'optimiseur. S'il faut un cas particulier pour les ROM_CALLs, l'optimiseur n'est pas bon. Le seul cas où OPTIMIZE_ROM_CALLS a un intérêt est l'optimisation globale.

mais a5 reste disponible pour les fonctions qui ont besoin de bcp de registres

arf... bon, alors ma foi, ne tenez pas compte de ce que j'ai dit plus ho.
g du mal comprendre quelque chose

Son OPTIMIZE_ROM_CALLS n'est pas un vrai OPTIMIZE_ROM_CALLS, c'est juste une optimisation locale qui devrait être traîtée par une optimisation plus générale (common subexpression elimination), pas par un cas particulier pour les ROM_CALLs.

je n'ai pas essayé avec GCC 3.3, mais il me semble que GCC ne le fait pas?

Il me semble qu'il le fait dans certains cas. Mais le pass CSE de GCC n'est pas parfait. (Je n'ai jamais dit que GCC était parfait. Juste qu'il n'y a pas mieux. )

Je viens de vérifier: GCC est tout à fait capable de mettre la table des ROM_CALLs en un registre parmi a2-a6 automatiquement, et il le fait automatiquement s'il le juge utile. Ça n'a strictement rien à voir avec OPTIMIZE_ROM_CALLS. Si tu as dû mettre un cas particulier pour les ROM_CALLs, c'est un workaround pour une déficience générale de ton optimiseur.

Au fait (et je demande ça surtout par pure curiosité): il fonctionne comment, l'optimiseur de GTC? Par "peepholes" (c'est-à-dire remplacement d'expressions régulières dans le code assembleur, ou quelque chose d'équivalent sur une représentation interne) uniquement? Ou y a-t'il des optimisations plus évoluées, de style common subexpression elimination, constant propagation, copy propagation etc.?

> Je viens de vérifier: GCC est tout à fait capable de mettre la table des ROM_CALLs en un registre parmi a2-a6 automatiquement, et il le fait automatiquement s'il le juge utile.
Autant pour moi. J'avais du regarder une vieille version.

> Si tu as dû mettre un cas particulier pour les ROM_CALLs, c'est un workaround pour une déficience générale de ton optimiseur.
Non.

> Au fait (et je demande ça surtout par pure curiosité): il fonctionne comment, l'optimiseur de GTC? Par "peepholes" (c'est-à-dire remplacement d'expressions régulières dans le code assembleur, ou quelque chose d'équivalent sur une représentation interne) uniquement? Ou y a-t'il des optimisations plus évoluées, de style common subexpression elimination, constant propagation, copy propagation etc.?

Il y a le peephole et le CSE, et d'autres (follow branches par exemple). Je ne sais pas ce que tu entends par "constant propagation" ou "copy propagation".

Constant propagation: si une variable est égal à une constante partout dans un morceau de code, on remplace la variable par la constante dans ce morceau de code.
Copy propagation: si une variable est égal à une autre variable partout dans un morceau de code, on remplace la variable par l'autre variable dans ce morceau de code.

GCC fait tout ça. Il fait aussi le "branch following". Il y a plein d'optimisations intéressantes dans GCC.

Aussi, je me demandais, est-ce GCC convertit le code récursif en itératif équivalent où non ?

> est-ce GCC convertit le code récursif en itératif équivalent ou non ?
Tu veux dire dérouler les boucles, ou transformer les fonctions récursives ?

Par exemple, cette fonction :

short somme(short n)
{
 if(n)
  n+=somme(n-1);
 return n;
}

serait compilée comme ça :

short somme(short n)
{
 short resultat=0;

 while(n)
 {
  Empiler(n);
  n--;
 }
 while(!PileVide())
 {
  n+=Depiler();
 }
 return n;
}

Je sais bien entendu qu'il y a des implémentations itératives beaucoup plus fines que ma deuxième solution, mais c'est juste pour essayer de représenter le travail du compilo s'il doit "dérécursiviser" du code. D'ailleurs, je pense que ce que j'ai mis est faux. Je n'arrive pas trop à donner l'équivalence itérative à du code récurif.

Moi ça me parait dément de passer le récursif en itératif!

jackiechan
a écrit : Aussi, je me demandais, est-ce GCC convertit le code récursif en itératif équivalent où non ?

Non. Si tu veux de l'itératif, code de l'itératif.

Pour faire du récursif, il faut que ça en vaille la peine. Le récursif, c'est bien pour le quicksort, entre autres; mais il faut être *bizarre* pour faire du récursif pour calculer une factorielle, par exemple.
(jackiechan, je ne critique pas ton exemple; je donne mon avis sur le fait d'utiliser du récursif ou de l'itératif).

oui, mais c'est quand même à celui qui code de choisir et non au compilo.

XDanger
a écrit : Pour faire du récursif, il faut que ça en vaille la peine.

Pourquoi il FAUT que ça en vaille la peine ?

(jackiechan, je ne critique pas ton exemple; je donne mon avis sur le fait d'utiliser du récursif ou de l'itératif).

Pas de pb, c'était juste pour expliquer ma question.

Ximoon
a écrit : oui, mais c'est quand même à celui qui code de choisir et non au compilo.

Complètement d'accord