Encore une mise à jour de TIGCC - Page 1

Sebastian Reichelt vient de rendre disponible une nouvelle mise à jour de TIGCC à l'URL suivante: http://tigcc.ticalc.org/beta/tigcc.zip.

Cette mise à jour ne contient pas de nouvelles fonctionnalités, juste des corrections de bogues. En particulier, cette version devrait être complètement compatible avec Windows 2000 et XP. (La version précédente ne marchait pas très bien avec ces versions de Windows.)

sniff.. moi qui m'attendais a des trucs vraiment nouveaux!

ça va me pousser à iunstaller 2000 ou XP...

Moi ca me tente pas trop, déja que mon PC rame sous WIN98. Et puis tous ceux que je connais et qui l'on essayé on eu des problèmes.

je fait une news ? :d

Ca mérite pas :d

TIGCC me déçoit beaucoup.

move.b d0,x(an)

Pourquoi écrit-il  move.b  x(an),d0
  or.b    #2^n,d0
 

#n,x(an)au lieu de bset.b



Ils foutent quoi les auteurs ???
[edit]Edité par Thibaut le 01-12-2001 à 14:55:26[/edit]

bah, c plutot bon signe pour l'Azur

Nan c'est pas ça que je veux dire, mais exactement le contraire... Azur est programmé avec TIGCC...

Et puis à part moi, c'est mauvais signe pour tout l'avenir des TIs, puisque de plus en plus de progs sont écrits en C

>Azur est programmé avec TIGCC
c pas grave, il suffira de recompiler Azur en Azur
[edit]Edité par Pen^2 le 01-12-2001 à 15:39:04[/edit]

Bon :
1) c'est mauvais signe pour tout l'avenir des TIs, puisque de plus en plus de progs sont écrits en C
2) A terme la source devrait atteindre 5000 lignes, non-merci c'est pas moi convertirai ça en Azur (les langages sont très très proches... proches, pas identiques)
3) J'imagine le temps de compilation... Azur a beau être incroyablement rapide, 5000 lignes ça fera beaucoup...
4) L'ASM produit par Azur est moins performant qu'un compilé de TIGCC: on ne peut pas concillier vélocité de compilation et qualité de code (mais pour TIGCC qui est sur PC et déjà excessivement lent, ils pourraient se permettre de faire mieux)

[edit]Edité par Thibaut le 01-12-2001 à 16:21:50[/edit]

1
oui, oui, je disais tout ça pour te charier
2
c vrai que c long 5000 lignes à relire
3
c juste

Au fait, c'est pour quel °2, tu viens de me faire rendre compte que j'avais mit deux n°2

ça va presque pour les deux 2

>Thibaut:
>Pourquoi écrit-il
> move.b x(an),d0
> or.b #2^n,d0
> move.b d0,x(an)
>
>au lieu de
> bset.b #n,x(an)

Parce que bset n'existe pas sur toutes les architectures supportées par GCC.

>Ils foutent quoi les auteurs ???

Les auteurs de GCC maintiennent principalement 2 parties de code:
- instructions valables pour tout processeur
- instructions optimisées x86 (mais même là, ce n'est pas toujours de bonne qualité: selon JM, on voit parfois l'équivalent x86 de lea (a0),a0 par exemple)
Quant à nous, l'équipe de TIGCC, on n'a vraiment pas le temps de nous occuper de ce genre de choses. L'équipe de GCC est au moins 20 fois plus grande que la nôtre, sans compter les contributeurs externes à l'équipe.
Mais tu peux venir de discuter de cela sur notre partie (TIGCC Programming) du forum de la TICT, si tu veux.
Il y a 2 solutions possibles, en fait:
- améliorer le backend 68k de GCC
- écrire un optimiseur externe à faire passer sur les sources en .s sorties par GCC
Les 2 solutions ont chacune ses difficultés.
Et toute aide (de toi, par exemple, puisque c'est toi qui te plains, et puisque tu sembles avoir l'air de t'y connaître en compilation) serait bienvenue, évidemment. À condition que le résultat soit en GPL, bien entendu.
[edit]Edité par Kevin Kofler le 02-12-2001 à 00:49:34[/edit]

je sais pas si la le fait chez vous
mais j'ai installer la dernier version beta
et quand je sort du help ca fait planter TIGCC
je suis sous XP.

Ah, toi aussi. Chez moi, avec Win98, ça fait la même chose. Je pensais que c'était un problème de l'installation de Windows sur l'ordinateur sur lequel je travaille en ce moment, mais si ça le fait aussi chez toi, ce n'est pas ça.

J'ai envoyé un Bug Report à Sebastian.
[edit]Edité par Kevin Kofler le 02-12-2001 à 08:13:22[/edit]

oui moi aussie ya unhe superbe erreur super longue

Bon, Sebastian m'a répondu qu'il allait voir ce qui cloche. Chez lui, le problème apparaît également, mais étrangement pas à tous les coups. Selon lui, il doit y avoir aussi un bogue de MS quelque part, puisque ce n'est pas normal que tout plante même s'il y a une erreur. Mais il va voir ce qu'il peut faire.

Sebastian a sorti encore une mise à jour, qui devrait corriger ce problème. http://tigcc.ticalc.org/beta/tigcc.zip. Il a aussi mis à jour les sources: http://tigcc.ticalc.org/beta/tigccsrc.zip.

En effet, je viens de tester et l'erreur est corrigée.

Kevin : Je suis tout à fait volontaire, mais il y a un pb : je parle très très mal anglais.

A-t-on les sources de GCC ? Si oui, on ne peut pas corriger ce "bug" dedans (c'est apparu quand j'ai écrit Structure->Champ= TRUE, où champ est sur 1 bit) plutôt qu'après la compilation ?

>A-t-on les sources de GCC ?

Évidemment! C'est le but-même du projet GNU, dont GCC fait partie!

>je parle très très mal anglais.

À part if, else, while, for ..., l'anglais n'est pas vraiment indispensable.

>Si oui, on ne peut pas corriger ce "bug" dedans (c'est apparu quand j'ai écrit Structure->Champ= TRUE, où champ est sur 1 bit) plutôt qu'après la compilation ?

Bonne chance! Les sources de GCC sont très compliquées! Surtout que ça passe d'abord par un front-end qui compile le C en du code intermédiaire multi-plateforme, puis par un back-end qui traduit ce code intermédiaire en assembleur pour la plateforme choisie. Donc au moment où le code mal optimisé est généré à partir de ton instruction C, il ne ressemble pas du tout à ce qui sort en définitive - il y a encore une étape de traduction à faire. Et probablement ce code intermédiaire ne contient aucune représentation pour bset.

le truc pas merdique du tout, en gros...
si seulement quelqu'un avait le temps (et la motivation) nécessaire pr nous faire un truc adapté au TI68k.... et pas à d'autre... => plus spécifique => plus optimisé...

À part if, else, while, for ..., l'anglais n'est pas vraiment indispensable.
Comment m'exprimer sur votre forum avec ces 4 mots ?

>A-t-on les sources de GCC ?

Évidemment! C'est le but-même du projet GNU, dont GCC fait partie!
Je ne sais même pas ce qu'est le GNU.

Pour le problème d'optimisation je pense que le mieux c'est d'abandonner TIGCC, et de porter TIGCClib pour le SDK de TI
Enfin, faut voir s'il optimise mieux.

>Comment m'exprimer sur votre forum avec ces 4 mots ?

Tu écris en français et je traduis. Et puis il vaut mieux que tu codes plus que tu ne parles.

>Je ne sais même pas ce qu'est le GNU.

http://www.gnu.org

>Pour le problème d'optimisation je pense que le mieux c'est d'abandonner TIGCC, et de porter TIGCClib pour le SDK de TI

LOL le SDK de TI.

>Enfin, faut voir s'il optimise mieux.

As-tu déjà vu toutes les horreurs que l'on trouve dans AMS?? Le compilateur C de TI est une catastrophe en ce qui concerne les optimisations!
[edit]Edité par Kevin Kofler le 03-12-2001 à 20:12:06[/edit]

Oui les horreurs je me suis amusé à les relever plusieurs fois Y'a des trucs bien marrants.
Mais ce n'est pas sûr que AMS a été compilé avec ce SDK... Il s'agit d'une bêta, donc d'un prog qui ne pouvait probablement pas exister lors de la création d'AMS (?)

>>Et puis il vaut mieux que tu codes plus que tu ne parles.
Tu veux dire quoi par là ?

Juste que tui n'auras pas besoin de passer ta journée à discuter en anglais.

Et AMS n'a pas été compilé avec le SDK, mais le compilateur à la base est probablement le même.

Tu sais pas où on peut avoir la fameuse licence GNU en français ?