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
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)
)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)
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
, 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
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.
) 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...
ça va être tendu 
(cf plus haut)
