Pour les \n, j'ai oublié de mentionner la syntaxe #macro/#endm qui permet d'éviter les \ (et qui permettra quelques autres fonctions plutôt puissantes, mais je vous laisse la surprise
)
)
De toute facon, je doute que GTC puisse servire à développer un projet complet
sans l'aide de TIGCC. Ben ouais, programmer on calc c'est bien, mais sur PC c'est
quand meme plus comfortable ! IMHO, je pense que la plupart de ceux qui utiliseront GTC le feront en coopération avec TIGCC. Sinon, bravo, c'est vraiment du bon boulot
nonn SVP !!!!!
Je ne sais pas quelles sont les options, mais ça doit certainement être les options les plus courantes. Il est dit que c'est la version 0.94/b21.
XDanger
a écrit : Il faudrait faire un bench avec TIGCC 0.94 Final, et un bench avec TIGCC 0.94 Final + la prerelease de GCC 3.3... GCC 3.3 semble optimiser mieux (au moins en taille, TRgenius a descendu très légèrement la taille de son programme avec une recompilation sous GCC 3.3).
Thibaut a écrit :
Ouai bon c'est pas joyeux, j'ai tenté de compiler tiltmaze, mais GTC est trop bogué, j'en ai marre de modifier la source pour contourner les bugs. A chaque fois des nouveaux arrivent
Pollux a écrit :
> La vitesse sur un PC moderne (même un P-133), n'est pas un argument. 30 secondes reste parfaitement acceptable pour compiler un projet ! Tant pis pour ceux qui sont impatients... Je ne sais pas si tu programmes bcp, mais même moi sur une calc qui n'a pourtant qu'un 68000 à 10 MHz je trouve ça ennuyeux de devoir attendre 5-10 secondes à chaque compilation (pdt la phase de développement, pas pour le release bien entendu)
<< -fomit-frame-pointer, parce qu'il me semble bien que GTC fait ça par défaut. Et s'il ne sait pas faire (ce n'est certainement pas une option parce que Pollux dit qu'il n'y a pas de switches d'optimisation), c'est un défaut de GTC, donc on ne va pas limiter GCC pour avoir les mêmes défauts, juste parce que tu n'as pas lu la documentation (où toutes les options sont expliquées). >>
Oui, GTC fait ça par défaut.
Je suis d'accord avec Kevin sur ce point, sauf si la qualité s'en trouve sévèrement affectée (exemple : F-Line...)
Pollux a écrit :
Le bug est corrigé... Ca venait de la ligne :
char* s2 = "http://tict/ticalc.org";
GTC croyait que le // était le début d'un commentaire
ExtendeD>
la syntaxe est bien mieux que celle de TI-GCC :
asm { myfunc: pea "Hello world!"(pc) move.l 0xC8,a0 move.l ST_showHelp*4(a0),a0 jsr (a0) addq.l #4,a7 rts }
(ce sera même possible de faire :asm { myfunc: pea "Hello world!"(pc) move.l 0xC8,a0 ST_showHelp(a0) addq.l #4,a7 rts })
(et qui permettra quelques autres fonctions plutôt puissantes, mais je vous laisse a surprise)
Kevin Kofler a écrit :
Et moi, j'ai descendu nettement la taille du mien (Backgammon).
Thibaut a écrit :
Ouai bon c'est pas joyeux, j'ai tenté de compiler tiltmaze, mais GTC est trop bogué, j'en ai marre de modifier la source pour contourner les bugs. A chaque fois des nouveaux arrivent
LOL. À ce rythme, GTC sera peut-être utilisable en 2010 avec un peu de chance.
> > La vitesse sur un PC moderne (même un P-133), n'est pas un argument. 30 secondes reste parfaitement acceptable pour compiler un projet ! Tant pis pour ceux qui sont impatients...
> Je ne sais pas si tu programmes bcp, mais même moi sur une calc qui n'a pourtant qu'un 68000 à 10 MHz je trouve ça ennuyeux de devoir attendre 5-10 secondes à chaque compilation (pdt la phase de développement, pas pour le release bien entendu)Moi, ça ne me gène pas du tout. Je suis habitué la compilation de programmes comme GCC, qui dure une demi-heure. À côté de cela, les quelques secondes qu'il faut attendre pour la compilation d'un programme pour calculatrice sont vraiment négligeables.
Je n'ai pas
utilisé les appels de ROM_CALLs par ligne F dans la comparaison GCC 3.3 vs. GTC, même si je retiens que leur non-support est un gros défaut de GTC.
> asm { }
Et du coup, ça sera incompatible, et on n'a pratiquement rien obtenu (sauf si on est un habitué de M$VC, ce qui n'est pas mon cas: vive MinGW).
Pour les % devant les registres, il suffit de passer --register-prefix-optional à GNU as pour pouvoir les omettre avec TIGCC. Mais c'est déconseillé, parce que ça crée des problèmes si on a des variables qui s'appellent par exemple a0 ou pc.
Ce qui est totalement non-standard et n'apporte strictement rien.
Tu aimes les surprises...
Pollux a écrit :
Mais toujours est-il que cette fameuse "série de bugs" n'est en réalité qu'un seul bug : "http://tict.ticalc.org" où le // était interprété comme un commentaire.
Honnêtement, quelle proportion des progs de plus de 5 ko utilise la F-Line?
"On n'a pratiquement rien obtenu" : tu n'as jamais mélangé assembleur et C toi... L'utilisation des #defines fait en C est immédiate,
et on peut utiliser de manière très simple les structures C en assembleur, ce qui est un véritable cauchemar avec TI-GCC.
* Output substitutions
Sometimes you want to include a value in an asm statement in an unusual way.
[...]
There are a few others mentioned in the GCC manual as generic:
%c0 substitutes the immediate value %0, but without the immediate syntax.
%n0 substitutes like %c0, but the negated value.
%l0 substitutes like %c0, but with the syntax expected of a jump target. (This is usually the same as %c0.)
Pollux a écrit :
ah oui, c'est vraiment très lisible quand tu commences à devoir accéder à 10 éléments d'une structure
Avoue que c'est quand même plutôt contraignant...
Comment penses-tu que j'ai fait pour mes sprites en 0b? Je n'ai pas utilisé de logiciel d'édition d'images, juste des lignes tapées à la main et du copier-coller. 
