Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmes et tests... » Beta-tests de programmes de TICT... (117 réponse(s))

./REPRISE DU POST PRECEDENT (post n°95) Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 7 juillet 2005 à 21:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

À ma connaissance, PpHd n'a jamais demandé les buffers consécutifs dans TIGCCLIB. #roll#

Il a décidé d'écrire sa propre routine de gris pour sa librairie graphique et a codé sa librairie pour sa routine de gris. C'est différent comme situation par rapport à ce qu'on a ici, où des gens codent des librairies graphiques soi-disant pour TIGCCLIB, mais ne lisent pas la doc et présupposent donc des propriétés qui ne sont pas satisfaites par TIGCCLIB, et ensuite viennent râler pour qu'on adapte TIGCCLIB à leurs routines boguées au lieu de corriger leur erreur.

Et c'est d'autant plus stupide ici parce qu'un patch pour corriger le bogue du Tilemap Engine existe déjà! http://www.tigen.org/kevin.kofler/ti89prog/tilemap.zip.
-Edité le Jeudi 7 juillet 2005 à 21:59 par Kevin Kofler-

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°96 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 8 juillet 2005 à 09:16

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Mais si le seul argument c'est que sur HW1 ca prend LCD_SIZE octets de ram de plus que ca ne pourrait, je vois pas le probleme.
Ben oui, c'est ça le seul argument.
> On s'en fout de savoir si la ram est utilisée plus ou moins car le prog va pas utiliser cet espace de memoire sur HW1 et s'en priver sur HW2 tout ca parce qu'il est dispo sur HW1.
Exactement. C'est bien ce qu'on répète à Kevin, et ça ne rentre pas plus chez lui que ce que son argument ne rentre chez nous...

Lionel Debroux - membre de TICT.

./Post n°97 Marquer comme non lu.

Folco

Ecrit le: Vendredi 8 juillet 2005 à 09:25

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Lionel Debroux :
> Mais si le seul argument c'est que sur HW1 ca prend LCD_SIZE octets de ram de plus que ca ne pourrait, je vois pas le probleme.
Ben oui, c'est ça le seul argument.

Comprends pas....
Sur HW1, si tu travailleq avec LCD_MEM pour les gris, c'est bien que t'as une sauvegarde de l'écran initial quelquepart non? Sur HW2, tu travailles ailleurs en RAM, t'as pas besoin de sauvegarder ça...
Donc allouer deux buffers consécutifs en RAM permet de ne jamais sauvegarder LCD_MEM sur aucun des HW, donc je ne vois même pas ou est l'argument, dans tous les cas tu gagnes un buffer de 3840 octets de sauvegarde plus le code d'allocation/vérification/restauration.

bon ok, à moins que j'ai vraiment zappé quelquechose, mais là sur GFA-Editor je viens de supprimer la sauvegarde de LCD_MEM, ça sert.... à rien.

-Edité le Vendredi 8 juillet 2005 à 09:27 par Martial Demolins-

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°98 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 8 juillet 2005 à 10:34

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Euh, pas vraiment... Rien à voir, en fait. Et l'écran est sauvé dans la pile, pas dans le tas.

> Sur HW2, tu travailles ailleurs en RAM, t'as pas besoin de sauvegarder ça...
Si, parce qu'il faut toujours recopier les planes vers LCD_MEM. Les autres réglages de la snoop range (voir j89hw.txt) ne sont pas utilisables car chez TI, ils ont mis les variables internes d'AMS à cet endroit-là.
A moins d'utiliser Home Screen Restore, un bout de code d'une centaine d'octets utilisé dans TI-Chess notamment, qui dispense de SAVE_SCREEN, qui fait quelques dizaines d'octets.

Je te suggère d'aller regarder le tutorial de TICT sur les systèmes d'affichage comparés des HW1 et HW2 (ce doit être S1P5). Et tu risques de te faire exploser par Kevin par exemple pour participer à une discussion sur un sujet sur lequel tu n'es pas tout à fait au point...

Lionel Debroux - membre de TICT.

./Post n°99 Marquer comme non lu.

Folco

Ecrit le: Vendredi 8 juillet 2005 à 10:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Ah en effet, mais merci pour les documentations, je vais aller jeter un oeil.

>>Et tu risques de te faire exploser par Kevin par exemple pour participer à une discussion sur un sujet sur lequel tu n'es pas tout à fait au point...

Et bien, on croirait qu'il y a mort d'homme là. Il ne s'agit que d'un petit écran de calculatrice qu'une 50aine de personnes dans le monde doivent utiliser comme on le fait hein

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°100 Marquer comme non lu.

Dari

Ecrit le: Vendredi 8 juillet 2005 à 13:06

Membre privilégié

Messages: 968

Membre n°203

Inscrit le 18 avril 2004

Je pense que pour un programme (je programme en TI-Basic et en GFA, mais c'est pareil) ce qui importe (dans l'ordre), c'est :
La vitesse
La place
Les graphismes (si il y en a besoin).

Il me semble que la vitesse d'exécution est la chose la plus importante. Il m'est déjà arrivé dans mes programmes de "perdre" (ce n'est pas vraiment le mot) de la place pour gagner en rapidité.
Il me semble, Kevin, que tu essayes de faire le contraire.

"iPod, therefore, I am."

http://media.laquadrature.net/Quadrature_black-out_HADOPI_468x60px.gif

./Post n°101 Marquer comme non lu.

geogeo

Ecrit le: Vendredi 8 juillet 2005 à 13:14

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Il me semble, Kevin, que tu essayes de faire le contraire.

Faut retirer "Il me semble"

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°102 Marquer comme non lu.

Folco

Ecrit le: Vendredi 8 juillet 2005 à 13:27

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Lionel-> han xD Je n'ai testé que sur TI le fait de ne pas enregistrer l'écran... Je suppose que c'est pour ça que je le voyais correctement restauré.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°103 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 8 juillet 2005 à 13:29

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Plus exactement, il essaie d'obliger tout le monde à diminuer la taille, mais il ne le fait pas lui-même.
Voir le passage du réglage par défaut de -O2 en -Os (ça fait longtemps; Sebastian était il me semble d'accord; utiliser plus que -Os est il est vrai stupide pour beaucoup de programmes, surtout depuis GCC 4.0...), ou plus récemment le mal que Sebastian et moi avons eu à obtenir un -O3 moins extrémiste vitesse que le -O3 FSF (-O4 dans TIGCC) sur GCC 4.0.

Lionel Debroux - membre de TICT.

./Post n°104 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 8 juillet 2005 à 13:57

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
> On s'en fout de savoir si la ram est utilisée plus ou moins car le prog va pas utiliser cet espace de memoire sur HW1 et s'en priver sur HW2 tout ca parce qu'il est dispo sur HW1.
Exactement. C'est bien ce qu'on répète à Kevin, et ça ne rentre pas plus chez lui que ce que son argument ne rentre chez nous...

Une fois de plus, on ne s'en fout pas parce que il n'y a pas que ton programme qui utilise cette RAM, c'est si dur que ça à comprendre?
Ton argument ne fonctionne que sous la (fausse) supposition que la RAM sert seulement à ton programme.
-Edité le Vendredi 8 juillet 2005 à 13:58 par Kevin Kofler-

./Post n°105 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 8 juillet 2005 à 14:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Dari :
Il me semble que la vitesse d'exécution est la chose la plus importante.

La vitesse n'est pas en jeu ici, c'est une histoire de consommation mémoire seulement. La solution qui gaspille de la mémoire n'apporte aucun avantage de vitesse, son seul intérêt est de faire marcher des librairies graphiques boguées.

Lionel Debroux :
Plus exactement, il essaie d'obliger tout le monde à diminuer la taille, mais il ne le fait pas lui-même.

Si, par exemple tous mes programmes C sont compilés avec -Os. Contrairement à toi, je n'ai pas envie de passer des mois à optimiser des logiciels à la main. Je préfère travailler sur les optimisations de GCC qui optimisent une centaine de logiciels en même temps. Mes logiciels ASM sont raisonnablement optimisés, mais je n'ai jamais prétendu que c'était parfait.

Voir le passage du réglage par défaut de -O2 en -Os (ça fait longtemps; Sebastian était il me semble d'accord; utiliser plus que -Os est il est vrai stupide pour beaucoup de programmes, surtout depuis GCC 4.0...),

C'était Sebastian qui a changé et moi qui étais d'accord.

ou plus récemment le mal que Sebastian et moi avons eu à obtenir un -O3 moins extrémiste vitesse que le -O3 FSF (-O4 dans TIGCC) sur GCC 4.0.

-O3 a toujours été fait pour être extrémiste, et utiliser -O3 avec TIGCC est et a toujours été une très mauvaise idée, le fait de l'utiliser est déjà une erreur!
-Edité le Vendredi 8 juillet 2005 à 14:04 par Kevin Kofler-

./Post n°106 Marquer comme non lu.

Lionel Debroux

Ecrit le: Samedi 9 juillet 2005 à 13:15

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Contrairement à toi, je n'ai pas envie de passer des mois à optimiser des logiciels à la main.
J'y passe des mois parce que je n'ai pas beaucoup de temps. A plein temps, ça irait beaucoup plus vite. Mais les résulats sont là: sur plusieurs softs de TICT (TI-Chess, TICT-Explorer, probablement TI-Miner), et sur les softs d'autres programmeurs (Ice Hockey 68k: ~15 KB, Civ89: ~10 KB), avec TIGCC 0.95 et de vraies options de compilation, j'ai gagné bien plus que les LCD_SIZE octets avec lesquels tu nous fais *****. Travis a fait une partie du boulot sur Ice Hockey 68k, sous ma direction.
Les softs que tu maintiens étant de taille modeste à moyenne, sans changer radicalement (incompatibilité on-calc, compression), tu ne gagnerais pas énormément en optimisant à la main. Sauf exception:
"Mes logiciels ASM sont raisonnablement optimisés": effectivement, unin2tsr est au moins une centaine d'octets plus gros sur 700 que ce qu'il devrait. Bon, OK, il est complètement inutile, surtout que HW2/3Patch est plus puissant. Il reste que le programme est codé n'importe comment.

> Je préfère travailler sur les optimisations de GCC qui optimisent une centaine de logiciels en même temps.
Tu es parmi les seuls à connaître GCC suffisamment pour le faire, mais en général, quand je te parle d'un problème d'optimisation particulier, il est trop complexe à corriger... Il a fallu t'embêter longtemps pour avoir _un_ peephole, et il était faux.

Lionel Debroux - membre de TICT.

./Post n°107 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 9 juillet 2005 à 23:18

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

J'ai rajouté au moins une douzaine de peepholes dans mon GCC 4. #roll#

Et à ta place, je ne parlerais pas du TICT Explorer, vu que tu as passé des mois dessus, mais tu n'as pas atteint l'objectif le plus important, le faire marcher (sur Titanium). Perso, je n'ai pas du tout eu le temps de me plonger sur TICTEX. Si je passais mon temps à faire des micro-optimisations comme toi, j'aurais encore moins de temps pour les choses qui importent vraiment.

./Post n°108 Marquer comme non lu.

Lionel Debroux

Ecrit le: Dimanche 10 juillet 2005 à 09:40

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Perso, je n'ai pas du tout eu le temps de me plonger sur TICTEX.
Grossièrement faux. Ce n'est pas que tu n'as pas eu le temps: tu en as beaucoup plus que moi. C'est que tes priorités sont autres, ce que je comprends et que j'approuve parfaitement.
> Si je passais mon temps à faire des micro-optimisations comme toi, j'aurais encore moins de temps pour les choses qui importent vraiment.
La plupart des "micro-optimisations" (des KB, mais ce n'est pas grave...) ont été faites bien avant qu'on sache que la Titanium allait tout casser. Je n'ai pas fait de version qui fonctionne l'été dernier, je n'en ai donc pas fait pendant l'année scolaire.
TICT-Explorer n'est pas ma priorité. Presque personne ne fait des beta-tests en temps et en heure (voir le temps qu'il a fallu pour qu'un bug majeur de TI-Chess me soit reporté).

Si #106 te vexe, c'est fait exprès. Tu n'as qu'à pas parler de "pourriture" pour mon programme juste parce qu'il ne compile pas sur la daube MSYS, que tu le sais (même si tu l'as oublié, ce qui est admissible), que c'est marqué dans le header, et d'autant plus que c'est dans une partie du programme que tu n'avais aucun besoin de regarder, ni de recompiler et encore moins de lancer...
Là, tu fais ton caprice.
-Edité le Dimanche 10 juillet 2005 à 09:59 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°109 Marquer comme non lu.

Kevin Kofler

Ecrit le: Dimanche 10 juillet 2005 à 09:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Mes contributions à ld-tigcc ont gagné des KO sur CC.

./Post n°110 Marquer comme non lu.

Lionel Debroux

Ecrit le: Dimanche 10 juillet 2005 à 10:01

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Bah, évidemment, edit cross. Je suis parti de devant mon PC un moment, et m'étant rendu compte que j'avais écrit une connerie, j'ai édité le post sans avoir rechargé la page...

Lionel Debroux - membre de TICT.

./Post n°111 Marquer comme non lu.

Lionel Debroux

Ecrit le: Dimanche 10 juillet 2005 à 10:07

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Et bien que CC ait été amélioré, c'est un mauvais exemple, car il est écrit avec les pieds. C'est un des très rares programmes à utiliser une quantité aussi gigantesque de BSS.
Ecrit correctement (style TI-Chess, Ice Hockey 68k, AMS native bien écrit - gros buffers alloués, au lieu de se reposer sur le système de BSS), il n'y aurait pas besoin de ce gros caca de BSS et de toutes les relocations correspondantes: plus petit, plus efficace.

Lionel Debroux - membre de TICT.

./Post n°112 Marquer comme non lu.

Lionel Debroux

Ecrit le: Dimanche 31 juillet 2005 à 19:22

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

J'ai essayé de faire des versions TIGCCLIB des demos de Grib, mais demo2 n'est pas faite comme il faut: le résultat est horrible.
Voir ici.
SVP, que personne ne râle à propos de Grib, du fait que certain ne puisse pas poster là-bas, etc.
-Edité le Dimanche 31 juillet 2005 à 19:24 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°113 Marquer comme non lu.

Kevin Kofler

Ecrit le: Dimanche 31 juillet 2005 à 21:59

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Utilise GrayDBufToggleSync, pas GrayDBufToggle.

./Post n°114 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 1er août 2005 à 08:47

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Merci, je vais essayer.
Je pensais que GrayWaitNSwitches(2); suffirait, mais ça ne doit pas être le cas. Ca fait longtemps que je n'avais pas utilisé le doublebuffering...

Lionel Debroux - membre de TICT.