Optimisation taille des projets en plusieurs .c (switch ?) - Page 1

Le fait de placer différentes fonctions d'un programme dans des fichiers .c séparés augmente sa taille de façon significative. Je crois me souvenir qu'il y a un switch qui réduit (annule ?) cette augmentation de taille, mais j'ai vaguement parcouru la liste des switchs de GCC dans la doc sans trouver (à vrai dire, chercher un switch quand on ne sait pas exactement ce qu'on veut trouver, c'est pas évident ).

J'en profite pour une autre petite question : TIGCC 0.95 est pour l'instant un "vaporware" au même titre que GTC, ou bien si on demande gentillement on l'a ?

au même titre que GTC tu veux dire ?
le switch, il n'est pas plutôt dans les options de l'assembleur ? -Wa,-l ou quelque chose comme ça, je crois.

Heu oui GTC pas GCC (Kevin pourra rebondir là dessus pour expliquer une fois de plus que GTC n'aurait pas du avoir ce nom-là, tiens...)

-l You can use the '-l' option to shorten the size of references to undefined symbols. If you do not use the '-l' option, references to undefined symbols are wide enough for a full long (32 bits). (Since as cannot know where these symbols end up, as can only allocate space for the linker to fill in later. Since as does not know how far away these symbols are, it allocates as much space as it can.) If you use this option, the references are only one word wide (16 bits). This may be useful if you want the object file to be as small as possible, and you know that the relevant symbols are always less than 17 bits away.

Ça doit être ça.

Ok vais tester, thx.

Vertyos
: Kevin pourra rebondir là dessus pour expliquer une fois de plus que GTC n'aurait pas du avoir ce nom-là, tiens...

Heu le but c'était qu'il comprenne qu'il aurait l'air stupide à faire ça, tu vas pas t'y mettre toi non plus quand même ?

Pour en revenir au sujet :

- 1 seul .c, pas de switch : 8445 octets
- 3 .c, pas de switch : 9041 octets
- 3 .c, switch -l : 8765 octets

Donc on perd encore beaucoup en passant en plusieurs .c... Y'a pas d'autres solutions ?

Si, y'en a une, mais heu... Kevin va pas apprécier
Tu fais monprojet.c avec #include "fichier1.c", #include "fichier2.c", etc... et tu compiles ce fichier uniquement. Bien sûr, il faut revoir un peu au niveau des fichiers .h, mais ça devrait marcher

Si. Cette solution s'appelle GTC. Einstein a perdu 3,3 ko avec
Il y a aussi TIGCC 0.95 qui fait gagner de la place.

Thibaut > A vrai dire je cherchais à réellement annuler cette augmentation de taille, pas à la compenser avec une meilleure optimisation de la part du compilateur. Ça m'étonne qu'il n'y ait pas un switch dans TIGCC pour pallier une différence aussi grosse (320 octets sur un programme de 8ko, c'est loin d'être négligeable)

GoldenCrystal > Beurk... Autant faire un seul .c...

Vertyos> Comme l'a dit Thibaut, il te faudra attendre TIGCC 0.95 pour obtenir la même taille que lorsque tu n'avais qu'un .c

A vrai dire je cherchais à réellement annuler cette augmentation de taille, pas à la compenser avec une meilleure optimisation de la part du compilateur.

On est bien d'accord : tu trouves que ton programme a trop grossi et tu veux retrouver la taille d'origine.
Moi je te réponds que tu peux faire mieux : avoir une taille inférieure à la taille d'origine.
Quel que soit ce qui permet d'atteindre ton but, il est atteind et même dépassé

On en revient donc au premier post qui s'adresse à Kevin

Vertyos :
J'en profite pour une autre petite question : TIGCC 0.95 est pour l'instant un "vaporware" au même titre que GTC, ou bien si on demande gentillement on l'a ?

Vertyos :
Le fait de placer différentes fonctions d'un programme dans des fichiers .c séparés augmente sa taille de façon significative. Je crois me souvenir qu'il y a un switch qui réduit (annule ?) cette augmentation de taille, mais j'ai vaguement parcouru la liste des switchs de GCC dans la doc sans trouver (à vrai dire, chercher un switch quand on ne sait pas exactement ce qu'on veut trouver, c'est pas évident ).

On passe -l à l'assembleur GNU. Mais ça n'annule l'augmentation de la taille que pour les sauts et pas pour les trucs de style move label,%d0 (corrigé dans TIGCC 0.95), ne peut pas donner des bxx.s (juste des bxx.w) et surtout ne fonctionne que pour les programmes <24 KO. Le nouveau linker pourra faire mieux.

J'en profite pour une autre petite question : TIGCC 0.95 est pour l'instant un "vaporware" au même titre que GTC, ou bien si on demande gentillement on l'a ?

C'est à voir avec Sebastian. Je pense qu'il n'a pas encore le setup prêt, donc au mieux il peut t'envoyer les composants un par un, et je ne pense pas qu'il ait le temps de t'envoyer tout ça, ça fait quand-même beaucoup à mailer. Je pense que le mieux est d'attendre, la release est pratiquement prête. Il ne manque plus que quelques mises à jour de la documentation.

Vertyos :
Pour en revenir au sujet :

- 1 seul .c, pas de switch : 8445 octets
- 3 .c, pas de switch : 9041 octets
- 3 .c, switch -l : 8765 octets

Donc on perd encore beaucoup en passant en plusieurs .c... Y'a pas d'autres solutions ?

Attendre le nouveau linker et/ou la nouvelle version de l'assembleur de TIGCC 0.95 bêta 1 qui sortira courant septembre.

Si vraiment tu ne peux pas attendre, maile-moi les sources et je les compile pour toi.

Kevin Kofler
: C'est à voir avec Sebastian. Je pense qu'il n'a pas encore le setup prêt, donc au mieux il peut t'envoyer les composants un par un, et je ne pense pas qu'il ait le temps de t'envoyer tout ça, ça fait quand-même beaucoup à mailer. Je pense que le mieux est d'attendre, la release est pratiquement prête. Il ne manque plus que quelques mises à jour de la documentation.

Mouais... Assez détourné comme réponse, du coup tu m'as embrouillé
Sachant que j'ai Delphi 6 et 7, et que je devrais pouvoir recompiler TIGCC sans trop de problèmes, si vous ne voulez pas m'envoyer les sources tu m'excusera mais vous faites exactement la même chose que Pollux

Kevin Kofler
: Si vraiment tu ne peux pas attendre, maile-moi les sources et je les compile pour toi.

Super pratique, quand c'est un prog que je compile pour quelques ß-testeurs et pour moi-même assez fréquement

PS: L'offre de compiler les sources pour toi est sérieuse. Ça fera beaucoup moins d'octets à transférer que si on doit t'envoyer une pré-bêta de TIGCC 0.95.

Si vraiment tu ne peux pas attendre, maile-moi les sources et je les compile pour toi.

Je lui conseille plutôt de mailer Pollux. Il gagnera sans doûte plus de place. Et il poura compiler lui-même... parceque c'est pas très pratique s'il faut t'envoyer l'ensemble des .c à chaque fois qu'on fait une modification

Thibaut
:

Si vraiment tu ne peux pas attendre, maile-moi les sources et je les compile pour toi.

Je lui conseille plutôt de mailer Pollux. Il gagnera sans doûte plus de place. Et il poura compiler lui-même... parceque c'est pas très pratique s'il faut t'envoyer l'ensemble des .c à chaque fois qu'on fait une modification

Connaissant Pollux, je ne pense pas qu'il lui enverra la bêta sur simple demande. Et il devra probablement changer pas mal de trucs. TIGCC 0.95 devrait (je ne peux rien garantir, évidemment, mais c'est ce qui est censé être le cas) compiler sa source telle quelle.

Oui mais Thibaut a deviné le problème avant que je le poste : je ne vais pas t'envoyer les sources à chaque fois qu'une modification a été faite. On en revient au premier point de mon post #15

Les sources à m'envoyer pour la compilation, ce ne serait qu'une solution totalement temporaire. À moins qu'il n'y ait de gros imprévus, la bêta 1 sortira dans moins de 2 semaines, peut-être même dans moins d'une semaine.

---
(Zut, j'ai cliqué sur "Citer" à la place de "Éditer".)

Attendre le nouveau linker et/ou la nouvelle version de l'assembleur

Juste une question : tu veux dire qu'il faut qu'il attende les deux ou un seul des deux, quand tu mets "et/ou" ?
(c'est HS mais j'étais justement en train de dire sur un autre topic que "et/ou" n'est pas du français...)

Kevin : Non, j'ai eu très peu de modifications à apporter sur un gros projet nommé Einstein.
Aucune sur Azur.
Aucune sur la partie C de GraphX.
Aucune sur TILTmaze.
Pollux a aussi compilé TIChess avec très peu de modifs, et AS et Side sans modifs.

Vertyos : je pense que Pollux te fera confiance, demande-lui. Ca ne coûte rien d'essayer

Thibaut > Pourquoi pas
Il devrait déjà voir ce topic, si il ne donne pas signe de vie je verrais si je lui demande ou si je considère qu'il n'est pas d'accord.

Mais je ne comprend pas pourquoi Kevin ne répond pas au premier point de mon post #15

Sally
:

Attendre le nouveau linker et/ou la nouvelle version de l'assembleur

Juste une question : tu veux dire qu'il faut qu'il attende les deux ou un seul des deux, quand tu mets "et/ou" ?

Chacun tout seul peut réduire la taille (même l'assembleur tout seul parce que -l a été amélioré par Sebastian), mais pour l'effet optimal il faut les deux. Le linker a besoin d'informations supplémentaires de la part de l'assembleur pour pouvoir optimiser au maximum.

#24 : Il faut CygWin pour compiler leur linker et gcc lui-même

Vertyos :
Mais je ne comprend pas pourquoi Kevin ne répond pas au premier point de mon post #15

Il y a plusieurs MO de source! La source prend encore nettement plus de place que les binaires, et on ne peut pas t'envoyer les binaires sans les sources à cause de la GPL (du moins pour les projets qui ne sont pas à nous, comme GCC et GNU as). Et le linker tout seul:
1. n'est pas pratique sans les mises à jour de l'IDE et de tigcc.exe.
2. ne peut faire qu'une partie de son travail sans la version patchée de l'assembleur.

Thibaut :
#24 : Il faut CygWin pour compiler leur linker et gcc lui-même

Ou MSYS (ce que j'utilise).

Kevin Kofler :
Il y a plusieurs MO de source! La source prend encore nettement plus de place que les binaires, et on ne peut pas t'envoyer les binaires sans les sources à cause de la GPL (du moins pour les projets qui ne sont pas à nous, comme GCC et GNU as). Et le linker tout seul:
1. n'est pas pratique sans les mises à jour de l'IDE et de tigcc.exe. 2. ne peut faire qu'une partie de son travail sans la version patchée de l'assembleur.

Je suppose que les sources que vous auriez à envoyer font à peu de choses près la même taille que les sources de TIGCC 0.94 SP4 disponible sur votre site ?
Bien.
Donc ça fait... Estimation grossière, dans les 4mo. Ok, c'est "plusieurs Mo", mais vous ne me ferez pas croire que c'est mission impossible
Je sens là comme un *leger* refus inavoué pour ne pas que je te reproche de faire la même chose que Pollux, je me trompe ?