Améliorer GTC ? - Page 1

Bonjour tout le monde !

Eh ben voila je crée ce topic pour discuter des améliorations possibles que l'on pourrait donner à GTC (en attendant que le petit "problème de licence" soit réglé).

1ère question : peut-on faire en sorte que GTC ne nous dise plus qu'il n'y a pas assez de ram pour compiler ? On pourrait (je sais pas si c'est possible mais bon, quand on veut on peut) faire plusieurs "petites" compilations, c'est-à-dire compiler d'abord les includes et headers et mettre tout ça en archive pour ne pas gaspiller de ram, puis continuer la compilation en plusieurs petits morceaux de programme puis les assembler.

Est-ce que c'est possible ? Suis-je un futur savant fou ?



PS : Postez vos idées ! (pas trop folles bien sûr...)

En imaginant que Pollux ait le temps de faire évoluer GTC ! C'est pas gagné je crois

L'idée que tu donnes est pas trop réalisable je pense. Quand GTC manque de mémoire, c'est surtout quand les fonctions sont trop grosses (Pollux donnera plus de précisions).

Au fait, c'est un peu hors topic, Pollux, tu fais quoi en ce moment dans le cadre de tes études (à moins que tu ne bosses déjà) ?

Faire plusieurs petites compilations n'est pas possible parce que GTC n'utilise pas de vrai linker.

donc...

Améliorer GTC == écrire un linker oncalc?

Ou porter ld-tigcc, c'est du C pur après tout, et même du C qui nettoie ses allocations avant de quitter (interface DLL pour TIGCC IDE oblige), mais quand j'ai regardé la consommation de mémoire de ld-tigcc un jour, je me suis dit que ce ne sera pas vraiment faisable. (La consommation pour linker un programme de quelques KO se mesure en MO.)

héhé

en même temps c'est grâce à ça qu'il peut optimiser.

mais même si on lui demande juste de merger toutes les sections de même nom et de faire les cross références, sans optimiser, ça doit lui demander pas mal de mémoire pour charger tous les .o et plein de petites structures pour les symboles, et ça doit pas être réductible

Kevin Kofler (./4) :
Faire plusieurs petites compilations n'est pas possible parce que GTC n'utilise pas de vrai linker.

On s'en fout. La largeur de GTC est limitée à celle d'une fonction il me semble. Donc compiler fichier par fichier ne changera pas vraiment la consommation mémoire.
Compiler les fichiers séparément n'a vraiment pas d'intérêt pour un compilateur embarqué sur un petit système (càd destiné à des projets de taille raisonnable la plupart du temps) et ralentirait la compilation. Remarque, si on n'a modifié qu'un ou deux fichiers source, ça serait sans doute plus rapide que tout compiler, à condition que Pollux code son linker lui-même, parceque le tien est loin d'être un modèle de subtilité dirait-on.
Quand à la version PC, tout se passe comme si elle compilait séparément.

je comprends rien à ce que t'as dit.

Thibaut (./8) :
La largeur de GTC est limitée à celle d'une fonction il me semble.

Il fait toujours du function at a time? Quel compilateur obsolète! Unit at a time rulez!

Pour le linker:
ld-tigcc charge les fichiers objet entièrement en mémoire, toutes les opérations sur les fichiers objet sont effectuées complètement en RAM sur la représentation interne.

Pour les .a, il charge la table des symboles exportés et la liste des fichiers .o qu'il contient, utilisées pendant la résolution des symboles. Quand un de ces symboles est référencé, le .o le contenant est importé en RAM (entièrement).

Voilà pourquoi ce n'est pas faisable sur TI.

Kevin Kofler (./10) :
Il fait toujours du function at a time? Quel compilateur obsolète! Unit at a time rulez!

Tu es ridicule.
1) C'est impossible quand on dispose de 180 ko de RAM.
2) En pratique GTC s'avère meilleur que TIGCC sur pas mal de projets...

Va recoder ton linker et TIEmu au lieu de perdre du temps à critiquer le travail des autres

ce qui est ridicule c'est la guéguerre tigcc-gtc.

Oui.

Thibaut (./11) :
2) En pratique GTC s'avère meilleur que TIGCC sur pas mal de projets...

Seulement si on ne considère pas toutes les options de TIGCC qui permettent de gagner de la place, comme justement celles du linker.

<MODE_POLLUX>Et puis de toute façon quand j'aurai porté GCC 4.3, ça va tout éclater. </MODE_POLLUX>

Les options de ton éditeur de lien étaient toutes activées dans les tests dont on parle.

ca suffit, bordel!

Thibaut (./15) :
Les options de ton éditeur de lien étaient toutes activées dans les tests dont on parle.

Pas celles de TIGCCLIB qui sont offertes grâce à ld-tigcc, genre MLINK_FORMAT_RELOCS. Non, cette option n'est pas toujours une bonne idée, c'est pour ça que c'est une option.

Enfin bref, ici on parle de GTC. Si tu veux débattre il y a un sujet consacré à ça ici.

Kevin Kofler (./10) :

Thibaut (./8) :
La largeur de GTC est limitée à celle d'une fonction il me semble.

Il fait toujours du function at a time? Quel compilateur obsolète! Unit at a time rulez!

Ben je t'invite à mettre en place un compilo unit-at-time qui tourne sur TI.

On commencerait pas à devenir hors-sujet là ?

./1 > J'avais deja proposé un truc similaire a Pollux
Il m'avais répondu (de mémoire) que ca servais 'a rien' et que la solution était de reduire la taille des fonctions (quitte a découper autant de fois qu'il faudra) si on venait a manquer de place
C'est ce que je fais depuis et j'ai aucun probleme de place

Pollux m'avait dit ca aussi :
(Mais ca demande confirmation car je cite de mémoire)
L'ide n'impacte pas sur la mémoire dispo a la compilation puisqu'il se décharge a la compilation.
Et comme le compilo est une flashapp, il s'execute en flash directement sans consommer sa taille en ram.
Les fichiers sont lus en flash aussi, donc on dispose d'un max de ram pour compiler

Si ca peut aider certains...

Martial Demolins (./20) :
Oué euh Thibaut c'est toi qui a lancé le truc hein

le tien est loin d'être un modèle de subtilité dirait-on.

Qu'est ce qu'on en a à foutre que ça prenne une demi seconde de plus sur PC, quand on a la place et le proc, surtout pour un linker qui est orienté pour des tous petits projets? Autant gagner en lisibilité et en maintenance. Et au moins, il a le mérite d'être là et on en profite tous.

Martial, c'est pas ça le sujet. Kevin disait que GTC devrait avoir un vrai éditeur de liens. Sauf que sur calto la différence ne sera pas d'une demie seconde si l'éditeur de liens est codé n'importe comment. Ce sera des dizaines de secondes.

Tout ce que ça fait pour moi, c'est confirmer que la compilation on-calc est trop limitée, et avec la version PC de GTC, on souffre des limitations de la plateforme on-calc même quand on code sur une plateforme qui permettrait de faire beaucoup mieux.

a mon avis la compilation on calc ça peut être amusant pour des petits protos qu'on veut tester dans le train/métro, mais pour un truc complet, il vaut mieux compiler sur PC.

squalyl > ². Rien que pour l'écran quoi.. les résolutions d'écran sont de plus en plus énormes, c'est de moins en moins évident de se remettre à programmer on-calc.

[modeZephyr]de toute facon, je n'ai plus de temps à consacrer aux TI maintenant. Je ne programmerai plus pour ces petits trucs, trop limitées à mon gout.[/modeZephyr]

Kevin : bah non puisque sur PC il compile des projets de n'importe quelle taille. Il indique simplement "on-calc portability : impossible without splitting".

Je parle des limitations fondamentales de conception, genre pas de vrai linking, pas de unit at a time, ... et non pas des simples limites de taille fixées qui effectivement sont triviales à booster, voire qui se boostent tous seuls si on a plus de mémoire.

Et alors, à part t'autosatisfaire, ça sert à quoi de parler de ça ? Ca n'empêche pas GTC de produire des programmes équivalents à ceux produits par TIGCC et, pour certains, d'être plus petit et plus rapides. Lâche GTC un peu et va améliorer tes programmes on préférera.

idem pour toi. Va vaire des trucs au lieu de répondre à ses piques.