180

Pollux
a écrit : Justement, comme GCC ne supporte pas la modification des options de compilation juste pour une seule fonction, on est obligé de compiler tout le fichier en -O3

Pas nécessairement. -funroll-loops suffit.
Relis mon post. Je parle de code ASM, c'est bcp plus propre (et bcp plus simple à modifier) avec des #macro qu'avec des dizaines de copier-coller.

Tu mets un asm("") dans une boucle C et le dérouleur de boucles fait le reste du travail. Évidemment, cela sous-entend qu'il y a un dérouleur de boucles, mais tout compilateur optimisant qui se respecte en a un...
Ben ça permet quand même de porter pour TI-GCC tongue

Sauf si la moitié de la source est constitué de #macro comme ça...
Ce n'est pas une question de défaillance de l'optimiseur (cf plus haut).

Si. (Et je n'ai pas dit que l'optimisation de GCC est parfaite.)
Plus lisible, cf plus haut aussi : c bcp plus propre pour dérouler du code ASM (évidemment c pas le genre de truc qu'il doit y avoir dans BackGammon embarrassed)

Cf. plus haut (boucle C contenant asm("") à dérouler automatiquement avec -funroll-loops).
En tout cas tu ne respectes pas ta propre parole : "Et donne-moi un exemple avec une variable à portée locale. Je suis certain qu'il y a une solution qui ne nécessite pas tes extensions."

Je pensais à l'utilisation de cdefined seul, pas en combinaison avec #macro.
Illisible?

if ((FILE *in=fopen("data","rb"))
 && (FILE *out=fopen("save","w"))
 && (void *temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

C'est totalement illisible. Ton écriture est beaucoup trop chargée. Je préfère:
FILE *in,*out; void *temp;
if ((in=fopen("data","rb"))
 && (out=fopen("save","w"))
 && (temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

Et personnellement, j'utiliserais plutôt:
FILE *in=fopen("data","rb");
if (in) {
  FILE *out=fopen("save","w");
  if (!out) goto erreur;
  void *temp=malloc(TEMP_DATA_SIZE);
  if (!temp) goto erreur;
  // ...
} else {
  erreur: ST_showHelp("Loading error");
}

Les 2 solutions n'ont pas besoin de tes extensions et sont moins chargées.
#undef FORMAT_SIZE
#define FORMAT_SIZE 300

ou, plus proprement, grâce à #macro : SET_FORMAT_SIZE(300)

Mais pourquoi toute cette complexité quand il suffit d'une ligne pour déclarer ce f**tu buffer???
... et alors on ne profite pas du mode PC-relatif dans ces cas-là

Sauf en compilant en -Wa,-l.
(et il n'y a pas de switch pour forcer ce mode pour les progs de plus de 32k)

Normal, ce n'est pas possible pour les programmes de plus de 32 KO.
A titre d'exemple, quel programme utilise les différents switch de compilation pour différentes parties du prog (menus, jeu...) ?

TI-Chess.
Je pense que c vraiment négligeable, justement parce que c'est très chiant de devoir grouper les fonctions arbitrairement dans des fichiers différents juste parce qu'une fonction a besoin d'être plus rapide.

Si on programme proprement et que le programme dépasse une certaine taille, il est tout à fait normal de le couper en unités logiques. Et de ces unités logiques, il y en a qui ont besoin de vitesse et d'autres qui n'en ont pas besoin.
Pourtant tu m'as assuré qu'elles étaient inutiles? Il faudrait savoir...

Elles sont inutiles, mais les programmeurs vont quand-même les utiliser.
"vraiment utile", OK, mais c'est vraiment idiot de se limiter à des extensions aussi simples.

Ce n'est pas idiot, c'est penser à la portabilité.
"fortement dépendentes de la structure interne de ton compilateur" : pas d'accord, même avec un préprocesseur "classique" on peut implémenter 'cdefined' (mais c'est effectivement "non trivial").

En faisant faire au préprocesseur une partie du travail du compilateur, probablement oui. Mais c'est sale.
Quant à #macro, excuse-moi, mais c vraiment assez facile à implémenter,

C'est probablement faisable en traffiquant un paquet de trucs dans cpp*.c. À voir.
et le changement du mode de compilation doit quand même pouvoir se faire. (parce que côté optimisation globale, à part les fonctions inline et les variables statiques inutilisées qui disparaissent, franchement je vois pas)

Ça dépend où tu changes le mode de compilation. Entre 2 fonctions seulement ou au plein milieu d'une fonction. GCC ne compile pas instruction par instruction, il traduit la fonction entière en "trees", puis en "register transfer language", puis en assembleur.
Et puis, d'après les discussions que j'ai lues sur les archives de la mailing list de GCC, les versions futures de GCC compileront le programme entier à la fois (plus fonction par fonction) pour pouvoir faire des optimisations interprocédurales, donc ça devient encore compliqué.
Mais n'importe quoi! C'est vraiment impossible de faire un compilo efficace sur TI qui supporte le regparm(4) (ou sinon j'invite ceux qui me contredisent sur ce point à me montrer le contraire, ou tout au moins des algorithmes pour appuyer leur point de vue grin)

Revois ta routine d'allocation de registres. Il y a plusieurs algorithmes possibles. GCC 3.3 en connaît 2 différents (mais le nouveau ne fonctionne pas encore grin, du moins pas dans TIGCC, mais c'est normal parce qu'il est documenté comme "experimental").
Donc je ne vois absolument pourquoi tigcclib.9xz serait incompatible avec les progs on-calc. Tu essayes simplement de semer la discorde (pour que GTC et/ou tigcclib.9xz perdent de l'influence - d'ailleurs je trouve vraiment détestable cette mentalité de "concurrence", mais bon embarrassed), mais manifestement ça n'a pas marché smile
D'ailleurs je ne vois pas comment je pourrais "extinguish"er quoi que ce soit en ce qui concerne TI-GCC par le simple fait de ne supporter que regparm(2)...

Je dis qu'il ne faut pas se soucier de la compatibilité avec GTC parce que tu ne te soucies pas de la compatibilité avec TIGCC, mais qu'au contraire tu essayes exprès de rajouter des extensions pour que les programmes ne se compilent pas avec TIGCC.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

181

Kevin Kofler a écrit :
Pas nécessairement. -funroll-loops suffit.

Et tu m'expliques pourquoi ce switch n'est pas activé par défaut? Tout simplement parce que toutes les boucles ne doivent pas être déroulées... C'est vraiment débile de faire des fichiers display_optimsize.c, display_optimspeed_nounroll.c, display_optimspeed_unroll.c

Tu mets un asm("") dans une boucle C et le dérouleur de boucles fait le reste du travail. Évidemment, cela sous-entend qu'il y a un dérouleur de boucles, mais tout compilateur optimisant qui se respecte en a un...

Je parle de routine 100% asm là... TI-GCC garantit qu'il ne va pas rajouter des méchantes instructions au milieu? (déjà les link et unlk au début et à la fin de la procédure, c relou smile)

Ensuite est-ce que TI-GCC optimise :

int sh;
for (sh=0;sh<30*6;sh+=30)
  asm("move.b (%%a0)+,%1(%%a1)"::"i"(sh));

Sauf si la moitié de la source est constitué de #macro comme ça...

Alors c'est qu'il y en a besoin. Est-ce que je te demande de désactiver les extensions GNU?
Si. (Et je n'ai pas dit que l'optimisation de GCC est parfaite.)

Non. Un script sera tjs bcp plus puissant que tous les hacks utilisant l'optimisation (car il s'agit bien de hacks puisque demander à un compilo de générer un code ASM précis c un peu risqué...)
Cf. plus haut (boucle C contenant asm("") à dérouler automatiquement avec -funroll-loops).

cf plus haut tongue
Je pensais à l'utilisation de cdefined seul, pas en combinaison avec #macro.

Ha ha facile, mais je ne vois pas pkoi je m'en priverais grin
Oui évidemment, seul, cdefined() perd de son intérêt (dans la mesure ou defined() sert uniquement dans les headers ou pour la compil conditionnelle, et donc cdefined() ne sert pas dans les headers (on n'inclut pas un header au milieu d'une fonction), et ça n'avance pas les choses pour la compilation conditionnelle).
Mais cdefined() reste utile dans les macros smile

C'est totalement illisible. Ton écriture est beaucoup trop chargée. Je préfère:
FILE *in,*out; void *temp;
if ((in=fopen("data","rb"))
 && (out=fopen("save","w"))
 && (temp=malloc(TEMP_DATA_SIZE))) {
  ... suite du prog ...
} else ST_showHelp("Loading error");

Et personnellement, j'utiliserais plutôt:
FILE *in=fopen("data","rb");
if (in) {
  FILE *out=fopen("save","w");
  if (!out) goto erreur;
  void *temp=malloc(TEMP_DATA_SIZE);
  if (!temp) goto erreur;
  // ...
} else {
  erreur: ST_showHelp("Loading error");
}
Les 2 solutions n'ont pas besoin de tes extensions et sont moins chargées.

Oups pardon, j'avais oublié le code de fermeture. C'est là qu'on voit la puissance de ces extensions :
if ((FILE *in=fopen("data","rb"))) {
  if ((FILE *out=fopen("save","w"))) {
    if ((void *temp=malloc(TEMP_DATA_SIZE))) {
      ... suite du prog ...
      return;
    }
    free(temp);
  }
  fclose(out);
}
fclose(in);
ST_showHelp("Loading error");

C bcp plus propre qu'avec des goto, et en plus, les variables ont une portée qui se limite à celle de leur validité. Que demande le peuple?
Mais pourquoi toute cette complexité quand il suffit d'une ligne pour déclarer ce f**tu buffer???

Parce que c'est bcp plus rapide d'écrire :
if (!(frame%8))
  gl_put_large_string(sc,0,0,format("%d fps",fps));


que :
if (!(frame%8)) {
  char buf[100];
  sprintf(buf,"%d fps",fps);
  gl_put_large_string(sc,0,0,buf);
}


Sauf en compilant en -Wa,-l.

Oui, mais comme tu dis :
Normal, ce n'est pas possible pour les programmes de plus de 32 KO.


Alors qu'à l'intérieur d'un même fichier, ce serait possible.
TI-Chess.

Tu serais bien incapable de me citer d'autres exemples.
Si on programme proprement et que le programme dépasse une certaine taille, il est tout à fait normal de le couper en unités logiques. Et de ces unités logiques, il y en a qui ont besoin de vitesse et d'autres qui n'en ont pas besoin.

Cf début de mon post, elles ne sont pas si logiques que ça. Une routine isolée au milieu d'un fichier peut très bien avoir besoin de dérouler une boucle.
Elles sont inutiles, mais les programmeurs vont quand-même les utiliser.

roll
En faisant faire au préprocesseur une partie du travail du compilateur, probablement oui. Mais c'est sale.

Sale? Bof.
C'est probablement faisable en traffiquant un paquet de trucs dans cpp*.c. À voir.

C'est plutôt simple tongue
Ça dépend où tu changes le mode de compilation. Entre 2 fonctions seulement ou au plein milieu d'une fonction. GCC ne compile pas instruction par instruction, il traduit la fonction entière en "trees", puis en "register transfer language", puis en assembleur.

Evidemment pas au milieu d'une fonction roll
Et puis, d'après les discussions que j'ai lues sur les archives de la mailing list de GCC, les versions futures de GCC compileront le programme entier à la fois (plus fonction par fonction) pour pouvoir faire des optimisations interprocédurales, donc ça devient encore compliqué.

Ah bon. (vive les demandes en mémoire wink) Mais il doit y avoir moyen de modifier le comportement localement, non? Et puis de toutes façons si il y a de telles optimisations, ça devient encore plus idiot de segmenter en plein de fichiers puisqu'on ne peut alors plus profiter des optimisations globales...
Revois ta routine d'allocation de registres. Il y a plusieurs algorithmes possibles. GCC 3.3 en connaît 2 différents (mais le nouveau ne fonctionne pas encore grin, du moins pas dans TIGCC, mais c'est normal parce qu'il est documenté comme "experimental").

LOL rotfl

Je ne me suis certainement jamais penché sur le problème roll
Ce n'est pas vraiment simple de faire un allocateur rapide avec des besoins en mémoire limités...
Je dis qu'il ne faut pas se soucier de la compatibilité avec GTC parce que tu ne te soucies pas de la compatibilité avec TIGCC, mais qu'au contraire tu essayes exprès de rajouter des extensions pour que les programmes ne se compilent pas avec TIGCC.

Tu vas me faire croire que tu ne t'en es jamais soucié? A essayer de forcer PpHd à utiliser regparm(4) ?

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

182

Pollux
a écrit : Et tu m'expliques pourquoi ce switch n'est pas activé par défaut? Tout simplement parce que toutes les boucles ne doivent pas être déroulées... C'est vraiment débile de faire des fichiers display_optimsize.c, display_optimspeed_nounroll.c, display_optimspeed_unroll.c

Non, tu compiles par exemple display.c en -Os -funroll-loops et le reste en -Os.
Je parle de routine 100% asm là... TI-GCC garantit qu'il ne va pas rajouter des méchantes instructions au milieu?

Euh, non. Mais si c'est pour répéter bêtement de l'assembleur pur, tu utilises .rept:
http://tigcc.ticalc.org/doc/gnuasm.html#SEC116
C'est le boulot de l'assembleur, pas du préprocesseur C.
(déjà les link et unlk au début et à la fin de la procédure, c relou smile)

On n'utilise pas une fonction C pour une routine 100% ASM!
Ensuite est-ce que TI-GCC optimise :

int sh;
for (sh=0;sh<30*6;sh+=30)
  asm("move.b (%%a0)+,%1(%%a1)"::"i"(sh));

Tu te fous de ma gueule? On ne mélange pas une boucle C avec de l'assembleur comme ça. Voilà comment on code ça proprement:
  asm(".set sh,0
       .rept 6
       move.b (%a0)+,sh(%a1)
       .set sh,sh+30
       .endr");

Non. Un script sera tjs bcp plus puissant que tous les hacks utilisant l'optimisation (car il s'agit bien de hacks puisque demander à un compilo de générer un code ASM précis c un peu risqué...)

Donc tu utilises des directives pour l'assembleur. Évidemment, il faut que l'assembleur comprenne ces directives... Mais c'est le boulot de l'assembleur, pas du préprocesseur C.
Mais cdefined() reste utile dans les macros smile

Mais en C, une macro est un #define. Tes #macro n'ont pas leur place dans un préprocesseur C.
Oups pardon, j'avais oublié le code de fermeture. C'est là qu'on voit la puissance de ces extensions :
if ((FILE *in=fopen("data","rb"))) {
  if ((FILE *out=fopen("save","w"))) {
    if ((void *temp=malloc(TEMP_DATA_SIZE))) {
      ... suite du prog ...
      return;
    }
    free(temp);
  }
  fclose(out);
}
fclose(in);
ST_showHelp("Loading error");

Là, elle est carrément inutile:
FILE *in=fopen("data","rb")
if (in) {
  FILE *out=fopen("save","w");
  if (out) {
    void *temp=malloc(TEMP_DATA_SIZE);
    if (temp) {
      ... suite du prog ...
      return;
    }
    free(temp);
  }
  fclose(out);
}
fclose(in);
ST_showHelp("Loading error");

Pas besoin de tes extensions qui ne font qu'alourdir le code.
C bcp plus propre qu'avec des goto, et en plus, les variables ont une portée qui se limite à celle de leur validité.

Justement, ta portée est mauvaise. Elle va au-delà du bloc.
Qu'affiche GTC dans l'exemple suivant de code C99 (à condition que GTC comprenne)?
int i;
void _main(void)
{
  i=1234;
  for (int i=1;i<3;i++);
  printf("%d",i);
}

Que demande le peuple?

Que tu arrêtes d'utiliser des extensions totalement inutiles comme les déclarations en plein milieu d'une instruction. Entre 2 instructions, c'est normal, mais pas au plein milieu d'une instruction.
Parce que c'est bcp plus rapide d'écrire :
if (!(frame%8))
  gl_put_large_string(sc,0,0,format("%d fps",fps));


que :
if (!(frame%8)) {
  char buf[100];
  sprintf(buf,"%d fps",fps);
  gl_put_large_string(sc,0,0,buf);
}

Sauf que tu devrais déclarer char buf[100]; tout au début de la fonction et utiliser:
#define format(x...) (sprintf(buf,x...),buf)
Ça donne l'écriture d'en haut sauf toutes les macros complexes à déclarer. Juste une seule ligne de déclaration du buffer.
Tu serais bien incapable de me citer d'autres exemples.

Tu avais demandé un exemple ("quel programme", pas "quels programmes"). tongue
Et un exemple montre déjà que c'est faisable.
Cf début de mon post, elles ne sont pas si logiques que ça. Une routine isolée au milieu d'un fichier peut très bien avoir besoin de dérouler une boucle.

Alors on compile ce fichier-là avec -funroll-loops. Si on a besoin d'une boucle déroulée dans une routines, les routines qui y ressemblent ont de bonnes chances d'être elles aussi des routines nécessitant de la vitesse.
Je ne me suis certainement jamais penché sur le problème roll

C'est bien ce que je te reproche. smile
Tu vas me faire croire que tu ne t'en es jamais soucié? A essayer de forcer PpHd à utiliser regparm(4) ?

Pas forcer. C'était juste un conseil.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

183

Kevin Kofler a écrit :
Je sais, mais si on ne veut pas créer un monopole, on n'a pas d'autre choix que de continuer à supporter les kernels qui ne sont pas à jour.

Grossière Erreur !! roll
il existe une autre issue : fais un (ou même plusieurs) kernel(s) #huhu#

184

Kevin, si tu veux faire chier PpHd, passe GenLib en staticwink
avatar
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.

185

hum ça va être tendu grin
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

186

Kevin Kofler a écrit :
Non, tu compiles par exemple display.c en -Os -funroll-loops et le reste en -Os.

Ben non, en général c pas le cas. Certaines fonctions d'affichage ont besoin d'être optimisé (affichage de caractère, de ligne), d'autres non (affichage d'un cadre - ça n'arrive pas 100x par seconde...) On est obligé de faire des distinctions plus ou moins arbitraires.
Euh, non. Mais si c'est pour répéter bêtement de l'assembleur pur, tu utilises .rept:
http://tigcc.ticalc.org/doc/gnuasm.html#SEC116
C'est le boulot de l'assembleur, pas du préprocesseur C.

  asm(".set sh,0
       .rept 6
       move.b (%a0)+,sh(%a1)
       .set sh,sh+30
       .endr");

OK (mais petite nuance : c'est le boulot du préprocesseur ASM, pas de l'assembleur smile donc dans GTC c'est le même).
Mais appelle-moi si tu arrives à faire des macros pour GNU AS qui assemblent ça :
asm {
_main:
	PUSH_REGS d3-d4/a2
	OPT_RCALL a2	// allows the code to be a bit smaller :)
	RCALL ST_showHelp,ADDR("This is a demo of the power of GTC's assembly support")
	RCALL EM_moveSymFromExtMem,ADDR($(asm_in)),ADDR(NULL)
	RCALL SymFind,ADDR($(asm_in))
	tst.l d0
	beq \not_found
	RCALL DerefSym,d0
	RCALL HeapDeref,__offset_of__(SYM_ENTRY,handle)(a0)
	addq.l #7,a0
\loop
	move.b (a0)+,d3
	beq \end
	cmp.b #'\r',d3
	beq \newline
	move.b (a0)+,d4
	cmp.b #'\r',d4
	beq \newline
	move.b d3,-1(a0)
	move.b d4,-2(a0)
	bra \loop
\newline
	move.b (a0)+,d3	// skip the following space...
	bne \loop
\end
	POP_REGS
	rts
\not_found
	RCALL ST_showHelp,ADDR("Please create a text named 'asm_in'")
	bra \end
};

tonguetonguetonguetongue
(et la macro RCALL type correctement les arguments, détermine leur taille, les empile et les dépile, etc... - si tu veux je peux poster la source ici)
Bon évidemment, tu vas me dire qu'une fonction C serait mieux adaptée ici. Mais ce n'est qu'un exemple, et ça montre ce qu'on peut faire avec #macro smile

On n'utilise pas une fonction C pour une routine 100% ASM!
Tu te fous de ma gueule? On ne mélange pas une boucle C avec de l'assembleur comme ça.

Je suis entièrement d'accord, mais tu disais dans ton post précédent que -funroll-loops suffisait pour tous les besoins de déroulement. Ca n'est manifestement pas le cas (tu le dis toi-même).
Donc tu utilises des directives pour l'assembleur. Évidemment, il faut que l'assembleur comprenne ces directives... Mais c'est le boulot de l'assembleur, pas du préprocesseur C.

Du préprocesseur ASM gni (cf plus haut)
Mais en C, une macro est un #define. Tes #macro n'ont pas leur place dans un préprocesseur C.

Non. La preuve, format. Et vu ce qu'on peut faire avec (cf RCALL et tout ça plus haut), je ne vois pas pourquoi limiter l'utilisateur. On peut, par exemple, faire un petit script qui génère une table précalculée.
Là, elle est carrément inutile:
FILE *in=fopen("data","rb")
if (in) {
  FILE *out=fopen("save","w");
  if (out) {
    void *temp=malloc(TEMP_DATA_SIZE);
    if (temp) {
      ... suite du prog ...
      return;
    }
    free(temp);
  }
  fclose(out);
}
fclose(in);
ST_showHelp("Loading error");
Pas besoin de tes extensions qui ne font qu'alourdir le code.

... et 2x plus de lignes ...
Enfin bon ça c une question de goût. Ca m'horripilait de devoir faire une déclaration en plus de chaque initialisation, mais bon après c up to the user.
Justement, ta portée est mauvaise. Elle va au-delà du bloc.

Non. La déclaration in-expression se comporte comme la déclaration in-statement, elle se limite au bloc qui l'entoure.
Qu'affiche GTC dans l'exemple suivant de code C99 (à condition que GTC comprenne)?
int i;
void _main(void)
{
  i=1234;
  for (int i=1;i<3;i++);
  printf("%d",i);
}

La seule déclaration C99 que je n'ai pas supportée est celle du for, parce que à mon sens 1) ça incite à utiliser des boucles for dans le sens positif 2) ça incite à déclarer plus de variables-compteur que nécessaire (on déclare une variable par boucle)
Que tu arrêtes d'utiliser des extensions totalement inutiles comme les déclarations en plein milieu d'une instruction. Entre 2 instructions, c'est normal, mais pas au plein milieu d'une instruction.

roll
Et pourquoi pas?
Sauf que tu devrais déclarer char buf[100]; tout au début de la fonction et utiliser:
#define format(x...) (sprintf(buf,x...),buf) Ça donne l'écriture d'en haut sauf toutes les macros complexes à déclarer. Juste une seule ligne de déclaration du buffer.

Les "macros complexes" sont intégrées aux headers, bref rien de complexe pour l'utilisateur. Et pourquoi vous ne faites pas un hack sale comme vous avez fait pour SYMSTR/SYMSTR_CONST ?
Tu avais demandé un
exemple ("quel programme", pas "quels programmes"). tongue Et un exemple montre déjà que c'est faisable.

Tu joues sur les mots wink Et puis j'ai regardé, c'est quand même assez grossier (i.e. il fait des fichiers "logiques", résultat il peut moins contrôler la qualité de l'optimisation)
Alors on compile ce fichier-là avec -funroll-loops. Si on a besoin d'une boucle déroulée dans une routines, les routines qui y ressemblent ont de bonnes chances d'être elles aussi des routines nécessitant de la vitesse.

Non, cf début du post.
> Je ne me suis certainement jamais penché sur le problème roll
C'est bien ce que je te reproche. smile

C'était ironique je précise. grin
Pas forcer. C'était juste un conseil.

En toute amitié wink C'est gentil de conseiller tes "ennemis" sur des logiciels auxquels tu es fondamentalement opposé wink Quel saint ce Kevin bouquet

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

187

Pollux
a écrit : Ben non, en général c pas le cas. Certaines fonctions d'affichage ont besoin d'être optimisé (affichage de caractère, de ligne), d'autres non (affichage d'un cadre - ça n'arrive pas 100x par seconde...) On est obligé de faire des distinctions plus ou moins arbitraires.

Pas forcément. Et puis, on n'est certainement pas "obligé". On peut aussi s'adapter. TI-Chess fait ça très bien.
OK (mais petite nuance : c'est le boulot du préprocesseur ASM, pas de l'assembleur smile

Il n'y a pas de préprocesseur dans GNU as. Le .rept est totalement intégré à l'assembleur.
donc dans GTC c'est le même).

Tiens, je me demandais où était passé ton asm { dans ta liste d'extensions... Tu en avais parlé avant, mais c'était quand-même à mettre dans ta liste.
Mais appelle-moi si tu arrives à faire des macros pour GNU AS qui assemblent ça

Ce n'est carrément plus de l'assembleur là. Et on peut exprimer la même chose en GNU as en mettant les chaînes de caractères là où elles ont leur place, quelque part en dehors de la fonction, et en codant du vrai assembleur (pas un langage de macros bâtard), c'est-à-dire en passant les arguments explicitement. Et tes macros sont une catastrophe du point de vue de l'optimisation. Par exemple, on ne peut pas optimiser addq.l #2,%a7;move.w #123,-(%a7) en move.w #123,(%a7) si on ne contrôle pas le code utilisé pour le passage de paramètres.
Du préprocesseur ASM gni (cf plus haut)

Ce n'est pas un préprocesseur.
Non. La preuve, format. Et vu ce qu'on peut faire avec (cf RCALL et tout ça plus haut), je ne vois pas pourquoi limiter l'utilisateur.

Pour la compatibilité avec TIGCC.
Si TIGCC est trop limité pour toi, écris les patches qui implémentent cette fonctionnalité sous TIGCC, nous les prendrons...
On peut, par exemple, faire un petit script qui génère une table précalculée.

On ne fait pas ça dans le compilateur/assembleur/préprocesseur/...! On autogénère le code avec un programme spécialisé et on passe le résultat au compilateur!
... et 2x plus de lignes ...

Moins chargées.
Enfin bon ça c une question de goût.

Non, c'est une question de respect des standards.
Ca m'horripilait de devoir faire une déclaration en plus de chaque initialisation, mais bon après c up to the user.

And up to the compiler and to the standard. roll
Non. La déclaration in-expression se comporte comme la déclaration in-statement, elle se limite au bloc qui l'entoure.

Mais une déclaration dans un if devrait avoir la portée limitée à l'intérieur du if. De même que dans mon exemple de for, le résultat devrait être 1234.
La seule déclaration C99 que je n'ai pas supportée est celle du for, parce que à mon sens 1) ça incite à utiliser des boucles for dans le sens positif 2) ça incite à déclarer plus de variables-compteur que nécessaire (on déclare une variable par boucle)

Et c'est justement la seule déclaration au milieu d'une instruction prévue par le standard! Tu te fiches totalement des standards et donc de la compatibilité avec les compilateurs existants!!!

Quant à tes arguments, ils sont totalement bidons:

>1) ça incite à utiliser des boucles for dans le sens positif
C'est faux. Il n'y a aucune différence de ce point de vue-là entre:
for (int i=1;i<3;i++);
et:
int i;
for (i=1;i<3;i++);

ni entre:
for (int i=2;i>0;i--);
et:
int i;
for (i=2;i>0;i--);


>2) ça incite à déclarer plus de variables-compteur que nécessaire (on déclare une variable par boucle)
Et c'est le boulot de ton allocateur de registres de réutiliser le même registre.
roll Et pourquoi pas?

Parce que:
* c'est illisible.
* ce n'est pas permis par le standard.
* je ne connais aucun autre compilateur (autre que le tien) qui permet ça.
* ça n'apporte rien à l'expressivité du langage.
Les "macros complexes" sont intégrées aux headers, bref rien de complexe pour l'utilisateur. Et pourquoi vous ne faites pas un hack sale comme vous avez fait pour SYMSTR/SYMSTR_CONST ?

On verra quand GTC sera sorti, pas avant. En ce moment, rien ne nous dit:
* que tu vas vraiment le sortir.
* que tu ne vas pas changer la syntaxe de tes extensions au dernier moment.
Tu joues sur les mots wink Et puis j'ai regardé, c'est quand même assez grossier (i.e. il fait des fichiers "logiques",

Ben oui. Je dis depuis le début qu'on peut très bien faire ça.
résultat il peut moins contrôler la qualité de l'optimisation)

Compromis nécessaire.
C'était ironique je précise. grin

Je n'en avais pas l'impression...
En tout cas, tu devrais te pencher sur ce problème encore plus.
En toute amitié wink C'est gentil de conseiller tes "ennemis" sur des logiciels auxquels tu es fondamentalement opposé wink Quel saint ce Kevin bouquet

rotfl
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité