TIGCC 0.95 Beta 5 - Page 1

... est sortie.
Cf. http://pub26.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=2454.topic pour plus d'informations.

Pour ceux qui ont la flemme de cliquer :

Sebastian uploaded a new Windows release of TIGCC a few hours ago. Get it at tigcc.ticalc.org as usual. I hope to have the *nix version ready this weekend.

What's new:
* GCC should no longer ask for drive E:.
* Fixed a loop unrolling bug in GCC: when optimizing for size (-Os), the loop execution count was off-by-one: loops executed 0 times were mistaken for loops executed once (and unrolled as such instead of being removed as they should), loops executed 1 times were not recognized as such (and not unrolled). Note that loops are unrolled under -Os if and only if they are known to be executed 0 or 1 times.
* The latest A68k update is now included.
* tigcc -g and tigcc -c should work now.
* ENABLE_ERROR_RETURN should now work with MIN_AMS>=200 (the same bug we already fixed in TIGCC 0.94 SP4, but reintroduced while converting the startup code to the new format).

And now the usual reminders for those who have not read the previous announcements:
* This is a beta of the upcoming TIGCC 0.95. It has most of the planned features. In particular, there is a new linker which replaces the obsolete multi-stage linking system from TIGCC 0.94 and brings many new features compared to TIGCC 0.94. See the announcements of the previous betas (in particular Beta 1) for more information. * For those interested in programming for Fargo (TI-92), the needed static library is at members.chello.at/gerhard.kofler/kevin/ti89prog/libfargo.zip. Just unzip fargo.a into your Lib folder.

lol c gentil ça merci!

C'est normal que le code produit soit plus gros ? Pour un programme de 14 ko, il prend 300 octets en plus par rapport aux première beta de la v 0.95.
Il n'y aurait pas des options pour faire diminuer la taille ?

Raphaël
: C'est normal que le code produit soit plus gros ? Pour un programme de 14 ko, il prend 300 octets en plus par rapport aux première beta de la v 0.95.

C'est probablement la mise automatique du bit in-use quand c'est nécessaire (introduite dans la bêta 4).

Il n'y aurait pas des options pour faire diminuer la taille ?

#undef __need_in_use_bit
#define __need_in_use_bit ((void)0)
Mais c'est généralement une très mauvaise idée, vu que si TIGCC met le bit in-use, c'est (normalement) qu'il est nécessaire.

Et une nouveauté que j'ai oubliée dans la liste citée par Sasume: On peut maintenant créer des headers assembleur (GNU et A68k) depuis le menu de l'IDE.

C'est pas mal ça. Je vais essayer tiens!

ah le retour des headers asm, j'avais failli demander pourquoi ils étaient partis, et soit je me suis dit que c'était une feature, soit j'ai oublié, je ne sais plus

Ah, ça c'est cool. Merci.

Est-ce que ça serait possible d'avoir des améliorations sur l'IDE, par exemple de l'autocompletion pour les structures :

struct machin {
unsigned char truc, chose;
};

struct machin bidule;

et en tapant "bidule.", un popup apparait en proposant "truc" ou "chose" ? Parcequ'en fait en repassant de l'IDE de Delphi à TIGCC, ça fait quand même un gros vide. Sachant que l'IDE elle-même est développée en Delphi, c'est d'ailleurs curieux que l'auteur ait pas pensé à ça

L'autocomplétion est en cours. Mais je ne sais pas si c'est implémenté pour les structures dans les sources actuelles. Il faut demander à MOAAA, qui travaille là-dessus.

C'est implémenté pour quoi alors ?

./12> pourles prototypes de fonctions, je suppose ?



Cela dit, clair que l'aide à la complétion (fonctions, et strctures) serait bienvenue sous TIGCC !
Parce que au bout de quelques temps sous MSVC, surtout quand on ne code pour TI qu'une fois de temps, en reprennant le même projet dont on a pu oublier une partie, notament les noms de champs dans les structures, c la galère sous TIGCC : on passe son temps à se promener dans les .H pour retrouver les prototypes, les noms de champs, ...

moui... Enfin perso c'est pour les structures que je trouve ça plus pratique. Pour les fonctions, y'a autre chose : tu tape le nom de la fonction, ça t'affiche la liste des parametres attendus, et leurs types.

Pour les fonctions, y'a autre chose : tu tape le nom de la fonction, ça t'affiche la liste des parametres attendus, et leurs types.

bah, c de ça dont je parle
(comme sous msvc, quoi)

Enfin perso c'est pour les structures que je trouve ça plus pratique

surtout, oui...
surtout qu'il n'y a pas de surcharge des fonctions, en C...
mais bon, pr les fonctions, ça aide qd même...

squale92 :
bah, c de ça dont je parle (comme sous msvc, quoi)

Ok.

surtout, oui...
surtout qu'il n'y a pas de surcharge des fonctions, en C... mais bon, pr les fonctions, ça aide qd même...

Mwé... Cela dit en C on fait pas des centaines de structures non plus. Mais c'est pratique.

Cela dit en C on fait pas des centaines de structures non plus. Mais c'est pratique

Dans KII, quasiment toutes mes variables sont encapsulées dans une structure
(j'ai deux grosses structures qui permettent de regrouper les variables ; une qui correspond aux variable spécifiques au jeu, et l'autre aux variables plus générales)
Cela présente pas mal d'avantages... et le popup pour les champs de structure me serait TRES utile, puisqu'il m'aiderai à compléter quasiment tous mes noms de variables... (je n'ai qu'une quelques variables qui ne sont pas encapsulées dans ces structures, et elle n'ont généralement un usage que très local)

ce qui serait bien aussi c la recherche de regexp
y'a une lib delphi qui fait ca tres bien, mm pas la peine de le programmé ... TRegExp @ http://www.regexpstudio.com

2. You may not have any income from distributing this source
to other developers. When you use this product in a comercial package, the source may not be charged seperatly.

Il me semble fort que cette licence ne soit pas compatible avec la GPL (je dirais même que ce n'est pas une licence libre), donc non, on ne peut pas utiliser cette librairie.

Bonjour tout le monde, c'est moi qui ai développé un outil de completion du code.
Il comporte pas mal de bug, le parser c'est vraiment du bricolage ...
Je vais essayer d'améliorer ca. Quand j'aurais le temps...

Vous trouveriez donc utile le support des structures ?
La liste des paramètres d'une fonction, il y a un début d'implémenté, pour les fonctions de TIGCCLIB pour l'instant.
Dans un cas général, pour que le parser soit performant, il faudrait un preprocesseur.
J'en prévois un "simple", qui devrait se débrouiller dans la plupart des cas (il scan rapidement les #define pour voir ce qu'il faut inclure ou non).
Ensuite, pour être suffisament rapide, il faudrait que le parser n'est pas à rescanner tout à chaque fois. Il y aura donc un format de fichier contenant des informations préparsées.
Mon idée, c'est qu'il soit généré sous forme de fichier temporaire (fichieroriginal.c.~tmp par exemple), et qu'à moins que le fichier source n'ai été modifié entre deux complétions (il compare la date du fichier source et celle du fichier temporaire), le parser prennent directement le fichier temporaire.
Ensuite pour les libs par exemple, il sera possible de distribué des fichiers préparsés et modifiés à la main par exemple (pour inclure la doc, ou déclarer certaines macros comme étant des fonctions).

Vous trouveriez donc utile le support des structures ?

Oui ! l'autocomplétion dans TIGCC !
Au fait, je pourrais savoir ce que veulent dire précisément toutes
les options de projet de l'IDE ? C'est que dans la doc ça a pas vraiment l'air
d'y être. Les options pour les ROM Calls par exemple avec les formats
divers genre compact, ...

Et pis y'a un énorme problème: TIGCC 0.93 marchait sans problème sur tout Windows
que j'avais. TIGCC 0.94 n'a jamais marché avec mon PC sur un Windows autre que WinXP.
Ca pouvait encore aller, mais il me fallait deux systèmes, car XP Pro reconnaît pô mes
lecteurs de CD.

Et cette fois-ci, bien pire: TIGCC plante systématiquement sur tout système que j'ai,
même XP Pro. Le plantage se fait lors du lancement du prog d'install (devriez p-ê...
changer d'installeur?).

Qu'est-ce que vous me conseillez ? Je pourrais p-ê installer tigcc-0.94 tout en ayant
les fichiers du 0.95, et écraser les fichiers du 0.94 avec ?


J'ai cherché, pour une fois

moi g le .94 et win98, je n'ai pas installé tigcc, je l'ai copié à partir de l'install de mon frangin, et ça marche très bien

J'avais essayé ça avec le .94: faire l'install sous WinXP, et piquer les fichiers pour les
mettre sous Millenium. Ca a planté.

BlueSilk :
Au fait, je pourrais savoir ce que veulent dire précisément toutes
les options de projet de l'IDE ? C'est que dans la doc ça a pas vraiment l'air
d'y être. Les options pour les ROM Calls par exemple avec les formats divers genre compact, ...

http://tigcc.ticalc.org/doc/httigcc.html#advanced

Et pis y'a un énorme problème: TIGCC 0.93 marchait sans problème sur tout Windows
que j'avais. TIGCC 0.94 n'a jamais marché avec mon PC sur un Windows autre que WinXP.
Ca pouvait encore aller, mais il me fallait deux systèmes, car XP Pro reconnaît pô mes
lecteurs de CD.

Et cette fois-ci, bien pire: TIGCC plante systématiquement sur tout système que j'ai,
même XP Pro. Le plantage se fait lors du lancement du prog d'install (devriez p-ê... changer d'installeur?).

Peut-être parce qu'il est compressé avec UPX et que ton anti-virus met une "éternité" à scanner les exécutables compressés? Essaye de désactiver ton antivirus si tu en as un en tâche de fond. Mais sache que l'IDE est aussi compressée avec UPX.

Qu'est-ce que vous me conseillez ? Je pourrais p-ê installer tigcc-0.94 tout en ayant les fichiers du 0.95, et écraser les fichiers du 0.94 avec ?

Normalement, ça devrait marcher.

BlueSilk :
J'avais essayé ça avec le .94: faire l'install sous WinXP, et piquer les fichiers pour les
mettre sous Millenium. Ca a planté.

Peut-être parce que l'IDE est aussi compressée avec UPX.

Ce que tu peux aussi essayer, c'est de décompresser les exécutables avant usage avec upx -d: http://upx.sourceforge.net/.

Si je puis me permettre, je n'approuve pas la compression des exe ^^.
C'est très bien expliqué sur le site d'inno setup. En gros la compression des exe empêche le gestionnaire de mémoire de windows (qui distingue code et donnée) de faire son travail "correctement". Cela se traduit par une consommation beaucoup plus importante, tout dépend du logiciel en question biensur, qu'un exe normal, pas l'idéal pour des pc un peu ancien.

La compression coupe la taille de l'IDE sur le disque dur presque en 10, donc elle doit rester. Tu (comme tout autre utilisateur) peux toujours la décompresser avec upx -d. Personnellement, je suis plutôt pour compresser tous les exécutables de TIGCC avec UPX, notamment cc1.exe qui est très gros.

edit:: j'ai dit une connerie

Quant au problème du gestionnaire de mémoire, c'est surtout que charger le même exécutable ou la même DLL plusieurs fois en même temps crée plusieurs copies. Ceci ne concerne pas du tout TIGCC parce que:
* on n'a généralement qu'une fenêtre de l'IDE ouverte en même temps,
* les programmes en ligne de commande sont encore plus un-à-la-fois,
* link.dll n'est utilisé que par TIGCC, donc le problème de partage en RAM ne se pose pas non plus.