Le compilateur GTC est-il mauvais ? - Page 13

> IH68k a été codé en c?
A l'origine, oui
Mais on a fait des tableaux de chaîne optimisés pour gagner quelques centaines d'octets, et les tableaux optimisés utilisent un bout d'ASM inline avec opérandes C pour accéder aux chaînes de caractères. En tout cas, c'est comme ça que j'ai fait dans S1P6 et tthdex 2.8+-qui-ne-marche-pas-avec-TIGCC-0.95+.

Je parlais de vitesse et non pas de taille ce jour là
Lionel : Ca rend le truc dépendant de la plateforme. OK, ça fait gagner de la place, mais quel est le gain de place en pourcentage ?

Thibaut (./354) :
Si tu n'as pas accès à GTC, retourne toi vers Kevin, qui a décidé de priver tout le monde de GTC. Kevin pense toujours aux autres avant de penser à lui, c'est bien connu....

C'est Pollux qui n'est pas fichu respecter la licence de TIGCCLIB, ça prend pourtant 5 minutes de mettre les sources et textes de licence qu'il faut (j'ai même uploadé les sources de l'antique TIGCC 0.94 Beta 18 de laquelle il est parti pour lui).

Kevin Kofler (./364) :

Thibaut (./354) :
Si tu n'as pas accès à GTC, retourne toi vers Kevin, qui a décidé de priver tout le monde de GTC. Kevin pense toujours aux autres avant de penser à lui, c'est bien connu....

C'est Pollux qui n'est pas fichu respecter la licence de TIGCCLIB, ça prend pourtant 5 minutes de mettre les sources et textes de licence qu'il faut (j'ai même uploadé les sources de l'antique TIGCC 0.94 Beta 18 de laquelle il est parti pour lui).

Il n'en demeure pas moins que l'empêcher de distribuer GTC pour cette raison n'apporte strictement rien à la communauté, bien au contraire puisque cela la prive d'un bon compilateur...

Flanker (./365) :
Il n'en demeure pas moins que l'empêcher de distribuer GTC pour cette raison n'apporte strictement rien à la communauté, bien au contraire puisque cela la prive d'un bon compilateur...

Mais, ce n'est pas Kevin qui les prive, c'est la licence parce que Pollux ne l'a pas respectée.
Ceux qui ont participé à TIGCCLIB l'ont fait sous une licence qu'il faut respecter, si Pollux ne le fait pas, je suis d'accord avec Kevin pour le contraindre à le faire. Certains des programmeurs qui ont participé à ce projet ne sont pas là pour se défendre, et donc ce n'est pas une question de sévérité, mais d'application de la licence.

Quand j'ai participé à un projet et que je l'abandonne ou m'en éloigne, je serais content que quelqu'un soit là pour en faire respecter la licence.

Pollux ne faisait pas de diffusion officielle, ça restait restreint aux quelques personnes fréquentant le forum C de yAronet. Tout le monde sait ici que la bibliothèque livrée avec provient de TIGCC. Voilà pourquoi Pollux ne s'était pas embêté. Il y avait des solutions moins radicales et plus attentionnées vis à vis des membres du forum. Comme donner 1 semaine à Pollux pour rajouter la licence, par exemple, et imposer le retrait du téléchargement si le délai n'était pas respecté.

> Lionel : Ca rend le truc dépendant de la plateforme. OK, ça fait gagner de la place, mais quel est le gain de place en pourcentage ?
Cette optimisation-là gagne 3-4 octets par chaîne de caractères:
* référence de 2 octets au lieu de 4;
* absence de relocation (qui, pour un char *, est obligatoire même en mode pc-relative ou reg-relative);
* le bout d'ASM inline a à peu près la même taille que le code C classique équivalent.
Il y a des dizaines de telles chaînes de caractères, je ne sais plus combien exactement.
=> je dirais qu'on a gagné jusqu'à 1% de la taille du programme (400-500 octets sur 40-50K).
Ca faisait partie de la collection d'optimisations qui a diminué de plusieurs K la taille de Ice Hockey 68k. Comme sur Civ89 et nombre d'autres programmes, plusieurs autres K ont été obtenus en mettant des switches optimisés pour le compilo. Au total, sur Ice Hockey 68k, une bonne dizaine de KB (sans avoir enlevé la compatibilité on-calc), ce qui a permis de remettre les sprites, initialement mis dans un fichier externe pour rester loin de la limite des 64K, dans le programme principal, et gagner par là-même plusieurs KB:
* pas de code de recherche du fichier externe;
* références plus efficaces vers les sprites: d(pc) ou xxx.l direct, au lieu de d(pc) ou xxx.l indirect.


> Il y avait des solutions moins radicales et plus attentionnées vis à vis des membres du forum.
En effet...

D'accord

Faux
Si un fichier est compressé, la version décompressée est mise en RAM. D'où une perte de mémoire vive par rapport à la version non compressée qui peut être lue directement en ROM

Ben, si je comprends bien ce qu'écrit Martial, +1 Thibaut.

Ben je pense que tu dis qu'il vaut mieux mettre les données dans un fichier externe compressé (ce qui implique de le décompresser en RAM). Si c'est bien ça que tu dis, alors ça occupe plus de RAM que si on mettait les données dans un fichier non-compressé (celui-ci serait logé en ROM).

Le code n'a pas à être externe, ça crée des problèmes avec la protection anti-exécution. (Bien sûr, vous vous en foutez en kernel parce qu'il faut déjà contourner la protection pour pouvoir installer le kernel. )

Et ld-tigcc est bel et bien capable de séparer code et données:

-d [folder\]name
--data-var [folder\]name
Exclude all non-executable data (global variables) from the program and create an external variable for it. Note that you are absolutely required to make sure that no code is executed from the data section; otherwise it will crash depending on the calculator model: Newer calculators have a protection device that lets the operating system restrict the areas code can be executed from. name is the variable name to be assigned to the data variable. folder defines the folder of the variable; if it is not specified, the folder from the '--varname' option is used.

--data-var-copy=condition
Defines when to create a copy of the data variable in RAM. If condition is always, the program will always work on a copy in RAM, which means that you may rely on the data being the same on every start of the program. However, if the data variable is not archived, you may easily run out of available memory. archived causes a copy to be created only if the data variable is archived; this is the default. If the variable is not archived, the program will work on the actual contents of the variable, so the values of all global variables will be kept even after the program finishes. never tells the linker to work on the original variable unconditionally, but since you may not write to the archive memory, you have to make sure that you never modify the value of a global variable. If the '--data-var' option is not specified as well, this option has no effect.

C'est bien pour ça que je dis qu'il ne faut pas les utiliser sauf s'il n'y a vraiment pas d'autre solution!

Martial Demolins (./370) :
et en deux quand PpHd aura mis tout ça en f-line

Putain, va vraiment falloir que je mette ces ramcall en F-LIne moi.

Kevin, Lionel et Zephir sont pas assez grands pour venir ici d'eux-mêmes Je reprends :

Lionel Debroux (./25) :
> On en a rien à faire que tu trouves la bibliothèque de GTC "obsolète". Sur le fond, c'est un fait que la bibliothèque de GTC est celle d'une vieille version de TIGCC, et qu'il y a eu des améliorations depuis (notamment l'utilisation du linker plus moderne)...

Il y a quoi à part l'éditeur des liens ? Parceque là tu sais aussi bien que moi que ça ne change rien pour GTC.

> GTC compile tout Non, et tu le sais très bien. Essaie donc de compiler TI-Chess 4.17 avec GTC (dans le même style, en pire, il y a aussi tthdex-not-working, actuellement non releasé) sans l'avoir modifié au préalable...

Quelles sont les particularités de syntaxe utilisées dans ces versions et qui poseraient problème à GTC ?

> => il n'y a pas d'obsolescence visible.
Pour quelqu'un comme toi qui en étais resté à de vieux TIGCC, avant de revenir dernièrement, à la limite. Pour la majorité des autres, non, GTC est "obsolescent" (ou un terme équivalent si ça te fait plaisir) .

Eh bien tous les projets testés ont compilés.

Zephyr (./27) :

Lionel Debroux :
Je t'ai fait remarquer la trop faible taille de l'échantillon de tests, appelant aussi les autres lecteurs à indiquer des programmes intéressants.

Il y a un GTC disponible qqpart pour faire quelques tests et se faire son propre avis sur cette question qui semble ne mettre personne d'accord ? (la version PC d'ailleurs, pke je n'ai plus de Ti)

La version TI n'est pas celle qu'il faut prendre pour les comparatifs : elle n'optimise pas autant que la version PC, c'est juste pour la phase de développement

> Quelles sont les particularités de syntaxe utilisées dans ces versions et qui poseraient problème à GTC ?
J'en ai parlé pas plus loin que dans *cette* page (avec un affichage de 30 posts par page) de *ce* topic...

Je ne trouve pas

./361 ? (mais je n'ai pas l'impression qu'il s'agisse du même programme)

Ouai, en plus ça concerne très peu de programmes (2 % ?)

./385: si, je fais référence au même tthdex
Et dans ce topic, on faisait référence à Ice Hockey 68k et S1P6, que je n'ai pas mentionnés de l'autre côté. Il y en a quelques autres

./386: c'est exact, très peu de programmes utilisent de l'ASM inline avec opérandes C et/ou contraintes (ou en élargissant un peu, toute autre feature non portable de GCC parmi celles que GTC ne réimplémente pas).
Mais mon propos était d'indiquer que ton "GTC compile tout" ( topics/104633-apres-5-ans-nouvelle-version-deinstein#20 ) est faux. Je vois bien que tu étais énervé contre le comportement habituel de Kevin, mais il reste que tu as écrit quelque chose de faux, et que tu savais faux, puisque ./361 est antérieur
Si ce n'avait pas été moi, cela aurait probablement été Kevin qui t'aurait flingué sur ce point.

Et on peut passer à des choses plus constructives, hmm ?
J'ai déjà dit ce que je pensais qu'il fallait faire pour améliorer la comparaison, et je n'ai pas les moyens de le faire moi-même, parce que je n'ai pas GTC...

Je veux pas en rajouter, mais y'a juste un truc que je te vois souvent dire Thibaut, et j'aimerai en savoir un peu plus :
Tu dis que GTC oncalc n'est que pour la phase de développement. C'est Pollux lui-meme qui t'as dis ca ?
Ca m'étonne parce qu'à la base il me semble que GTC n'a pas pour but de concurrencer TIGCC.
(Il s'avère que c'est un -concurrent- finalement mais passons...)
Mais il me semble plutot que GTC faisait partie au debut de son projet GTools qui étaient des outils oncalc (ides+compilateurs) exclusivement.
Alors l'objectif de Pollux a peut-etre changé mais ce serait bien si tu pouvais expliquer tes propos
A moins qu'il soit plus simple de demander a Pollux lui-meme, mais vu sa frequentation actuelle du forum...je doute qu'il reponde

Dude (./388) :
Je veux pas en rajouter

Rajouter quoi ? On est là pour parler de ce genre de choses justement :

Dude (./388) :
Tu dis que GTC oncalc n'est que pour la phase de développement. C'est Pollux lui-meme qui t'as dis ca ?
Ca m'étonne parce qu'à la base il me semble que GTC n'a pas pour but de concurrencer TIGCC.
(Il s'avère que c'est un -concurrent- finalement mais passons...)
Mais il me semble plutot que GTC faisait partie au debut de son projet GTools qui étaient des outils oncalc (ides compilateurs) exclusivement.
Alors l'objectif de Pollux a peut-etre changé mais ce serait bien si tu pouvais expliquer tes propos

Entre le début d'un projet conséquent, tel que celui de Pollux, et la fin du projet, c'est à dire 2042, il s'écoule du temps et on s'aperçoit de certaines choses
Il se trouve que pour un souci de rapidité et de mémoire, Pollux désactive la compression et certaines optimisations dans la version embarquée du compilateur. La version PC tourne sur des processeurs plus de 1000 fois plus rapide, GTC peut donc s'atteler à des techniques d'optimisation longues.


Lionel : Tu as apparemment pas suivit la discussion que tu as lancée toit même Tu parlais du dernier TIChess. Tu disais que ça ne compilait pas avec GTC. D'où ma question : quelles sont les choses dans le code qui ne sont pas prises en charge par GTC ?

Thibaut (./389) :
La version PC tourne sur des processeurs plus de 1000 fois plus rapide

Je dis ça depuis tout le temps, enfin vous avez compris. Je ne comprends pas cette fascination pour la compilation on-calc. Mais du coup, autant utiliser TIGCC qui a un IDE convivial et un débogueur C (TiEmu+GDB).

D'où ma question : quelles sont les choses dans le code qui ne sont pas prises en charge par GTC ?

Assembleur inline.