GTC : un TIGCC sur votre calculatrice ? - Page 20

Il veut juste éviter que vous soyez déçus en voyant la liste des fonctionnalités du langage que GTC ne comprend pas.

erf non je ne vous fais pas baver pour le plaisir

Kevin> lol occupe-toi plutôt du bug de TI-GCC dont je t'ai parlé...

disons le 23, comme Space Démentia 0.81

on verra j'espère, mais ce n'est pas tout à fait sûr

S'il te plait, ce serait vraiment bien
Il te reste quoi à faire ?

Pollux a écrit :
Kevin> lol occupe-toi plutôt du bug de TI-GCC dont je t'ai parlé...

J'ai déjà regardé plusieurs heures hier et je n'ai pas encore trouvé l'endroit exact qui cloche. Je vais encore chercher aujourd'hui.

D'ailleurs, il me semble qu'en tant que développeur de compilateur, tu devrais avoir les compétences nécessaires pour m'aider à déboguer ce problème.

jackiechan> encore quelques pbs de liaison compilo-IDE...

Kevin> On va dire que j'ai pas vraiment le temps (demande à ceux qui postent dans ce topic )
Et puis il faudrait que je me mette dedans, ça prendrait pas mal de temps avant que je puisse vous être utile en quoi que ce soit. En plus il faudrait que je downloade les sources de GCC (20 Mo), un compilo C genre mingw32... et je n'ai jamais utilisé GDB. Désolé, mais ça retarderait carrément la sortie de GTC

et de GT-Basic !!

GT-Basic, je le programme surtout on-calc, donc quand je suis en vacances il avance pas trop (par contre, il va pas mal avancer d'ici les grandes vacances )

Pollux
a écrit : et je n'ai jamais utilisé GDB.

De toute façon, GDB est pratiquement inutilisable pour déboguer GCC. GCC est trop gros. Je travaille d'habitude avec des warnings de débogage.

Pollux a écrit :
GT-Basic, je le programme surtout on-calc, donc quand je suis en vacances il avance pas trop (par contre, il va pas mal avancer d'ici les grandes vacances )

Et bonjour le gros plantage qui va tout détruire...

> Et bonjour le gros plantage qui va tout détruire...
Ca ne m'est jamais arrivé. Mais je sauvegarde quand même tout régulièrement

t'as de la chance
même en basic g des gros plantages qui détruisent tous

> même en basic g des gros plantages qui détruisent tous
Ca m'était arrivé trois fois en quelques jours avec le dernier kernel qui a été sur ma calculette, à savoir UniversalOS 1.14, ce qui ne date pas d'hier...

>> Et bonjour le gros plantage qui va tout détruire...
>Ca ne m'est jamais arrivé. Mais je sauvegarde quand même tout régulièrement
Heureusement que tu sauvegardes... Ca serait dommage de faire comme JM pour VTI. C'est bien dommage que les sources aient été perdus...
Pour ceux qui programment en C ou ASM, VTI est infiniment plus utile que GT-Basic qui risque peut-être d'apporter des incompatibilités...

Pollux a écrit :
Kevin> lol occupe-toi plutôt du bug de TI-GCC dont je t'ai parlé...

C'est fait:

--- gcc-3.3-20030210.tigcc1/gcc/final.c Fri Feb 14 01:09:44 2003
+++ gcc-3.3-20030210-src/gcc/final.c    Thu Feb 20 20:00:38 2003
@@ -2909,7 +2909,19 @@
   /* simplify_subreg does not remove subreg from volatile references.
      We are required to.  */
   if (GET_CODE (y) == MEM)
-    *xp = adjust_address (y, GET_MODE (x), SUBREG_BYTE (x));
+    {
+      /* (TIGCC 20030220) On big-endian machines, adjust offset of paradoxical
+                          subregs of memory to point to the correct place.
+                          I don't know for sure whether this is needed for the
+                          non-paradoxical case as well, but as far as I can
+                          tell, non-paradoxical memory subregs are simplified
+                          elsewhere than here. -- Kevin Kofler */
+      int x_size = GET_MODE_SIZE (GET_MODE (x));
+      int y_size = GET_MODE_SIZE (GET_MODE (y));
+      int offset = SUBREG_BYTE (x);
+      if (BYTES_BIG_ENDIAN && (x_size > y_size)) offset-=(x_size-y_size);
+      *xp = adjust_address (y, GET_MODE (x), offset);
+    }
   else
     {
       rtx new = simplify_subreg (GET_MODE (x), y, GET_MODE (y),

Je vais mettre en ligne un nouveau prerelease de GCC 3.3. (Le bogue est là depuis au moins GCC 3.1, mais les versions obsolètes ne sont plus mises à jour.)

topics/19064-prerelease-de-gcc-33-pour-tigcc/2#32
http://tigcc.ticalc.org/gcc33/

Bon, Pollux, si tu veux faire plaisir à la terre entière tu sais ce qu'il te reste à faire...

peu de chances que ça sorte ce w-e à mon avis ... faudra encore patienter un mois

> faudra encore patienter un mois
Non. Il faudra patienter bien plus que ça pour voir arriver des trucs (pourtant très utiles) que TIGCC a et que GTC n'a pas encore (ASM inline avec opérandes C, etc...)

Mais pourquoi tant de haine ?

c'est le TICT effect

Seuls eux le savent.
Je dirais une peur de perdre leur place de leaders dans le domaine de la programmation sur TI. Mentalité totalement pourrie.

Ils ne font aucun effort pour remonter dans notre estime, surtout Kevin. XDanger a quand même fini par reconnaître que GTC était un projet très intéressant

Je trouve le projet de GTC très interessant mais le top serait de réunir TIGCC et GTC pour faire un compilateur de tonnerre avec des fonctions avancés...

Premièrement c'est imposiible car la structure même des compilos est très différentes et de'xièmement je doute que les auteurs soient d'accord

C'est bien dommage mais GTC est un bon projet!

>Je dirais une peur de perdre leur place de leaders dans le domaine de la programmation sur TI.
Dans ce que tu dis, il y a au moins la reconnaissance d'un fait patent: les références et les standards du monde TI, peu de personnes sont capables de les faire utiliser... et la TIGCC Team en fait partie (Pollux et toi, entre autres, le savez très bien...).

> Mentalité totalement pourrie.
Je ne voudrais pas que nous recommencions à nous insulter, mais là je te dis que je trouve que tu exagères: question mentalité, tu n'es (n'étais) pas toujours irréprochable... Tu t'es certes excusé, mais je ne crois pas que tu faisais preuve d'une mentalité parfaitement bonne dans le topic où tu brûlais TIGCC tout entier (et la TIGCC Team) car _rowread était trop lente.

> XDanger a quand même fini par reconnaître que GTC était un projet très intéressant
Oui. Mais plus je découvre de manques à GTC, moins je le trouve intéressant...

> Je trouve le projet de GTC très interessant mais le top serait de réunir TIGCC et GTC pour faire un compilateur de tonnerre avec des fonctions avancés...
C'est en effet une idée très intelligente (non, je ne suis pas ironique). Les fonctions du tonnerre sont toutes du côté de TIGCC, mais il manque une version on-calc à TIGCC. C'est sûr que les deux projets sont complémentaires: TIGCC pour la puissance des fonctions on-pc, GTC pour la possibilité de programmer on-calc (il manque quelques trucs à GTC, et la taille de la mémoire est limitée on-calc...)

Le seul grand mérite de GTC, c'est d'avoir une version on-calc. Mais elle a ses limites: taille des headers et des libs statiques. Il faut aussi ajouter à cela que comme le code du compilateur proprement dit dans les versions PC et calc est le même, d'après ce qu'il avait dit, la version PC se trouve de fait en-dessous de TIGCC en termes de fonctions.
Sur GTC, la vitesse de compilation est peut-être plus élevée (on verra les benchs...) et la taille plus faible (Kevin a récemment diminué de façon très importante la taille de GCC en compilant sans les options de debug, ça risque aussi d'accélérer la compilation...), mais est-ce que ces arguments tiennent vraiment debout (à moins d'être sur des PC totalement dépassés depuis au moins 4 ans) ?

Je trouve dommage que les bagards qu'il y a entres certain membres. Les TI doivent évoluer et ainsi améliorer GTC et TIGCC. Et je trouve dommage qu'on se discute sur des broutilles, La réunification est la meilleurs choses pour produire des choses performantes et complète.

Geogeo>si on m'avait filer 1€ à chaque fois que ce post à été poster, je serait multi-triardaire