Le _rowread de TIGCClib - Page 2

Qu'est-ce qui est corrigé???

La faute de français.

J'y connais que dalle en ASM (je commence avec le tutorial que tu as déconseillé), mais est-ce vraie que le _rowread pourrais être plus rapide???
Si oui qu'est-ce qu'il faut modifier???

Kevin: Je m'en suis rendu compte hier soir en jouant a Yoshi. Zut pas eu le temps de corriger.

200 cycles, c'est rien.... fau arreter de critiquer, car si vos prog sont lents c'est parcequ'ils sont mal programmé.. certainement pas a cause du rowread..

bah le bon moyen de savoir si ça vient de la ou pas c de mettre l'appel a la fct en commentaire, et de regarder a kell vitesse le prog tourne... je fais ça pour toutes mes fct, pr déterminer lesquelles il faut optimiser en priorité...

TiMad : Tout à fait d'accord, c'est pas grand chose, mais c'est quand même trop !!
Ca dépend de la façon dont la fonction est utilisée dans la boucle, et de ce qui est exécuté dans la boucle... Dans le cas d'Einstein, il y a bien une différence de fluiditée, peu sensible certes.


Pour ceux qui veulent un _rowread hyper-optimisé en taille et vitesse (je suis sûr que notre PpHd national trouverait moyen d'optimier encore ), voici le mien. Si Kevin veut le reprendre comme il le voulait pour mes autres fonctions, il le peut sans conditions (pour m'excuser de l'avoir provoqué au post #11 Au fait, vous n'avez toujours pas intégré les fonctions d'ouverture/fermeture/suppression de fichiers d'Azur dans TIGCC )

il s'utilise exactement comme _rowread???

Tout à fait

J'ai essayer de faire un simple copier/coller dans kbd.h, mais j'ai une erreur, comment faire pour intégrer ce code à kbd.h???

Thibaut>> Très drole le lien dans ta signature, mais c'est quand la premeire version officiele???

erf merci dans 2 semaines on va dire.


Pour l'intégrer à ta source, copie plutôt ceci dans TA source : ---

C que je prefererais vraiement l'integrer à kbd.h pour pouvoir l'utiliser avec tout mes prjet
C'est ce que j'ai fait pour mettre du son dans mes programmes...
De tout façon chez moi tigcclib.h, ainsi que certaine autre librairies sont modifiée, j'ai ajouté une librairi son.h

Tu ne devrais pas modifier les headers de TIGCC

Sinon, tu as tout a fait le droit de te créer tes propres libs, comme son.h !

Thibaut a écrit :
Tu ne devrais pas modifier les headers de TIGCC

Sinon, tu as tout a fait le droit de te créer tes propres libs, comme son.h !

Pourquoi???

La plus forte raison, tu la comprendras la prochaine fois que tu installeras une nouvelle version de TIGCC...

Je fais une sauvegarde des fichiers modifié, de sorte que je recommence mes modifications quand j'installe une nouvelle version de TIGCC

autant te faire tes propres headers

Oui mais l'avantage c'est que j'utilise toujours le son dans mes progs, donc je trfique tigcclib.h en ajoutant la ligne #include <son.h>
et je sais que je peux utiliser mes fonction dans tou mes projets

Mais si je comprend tu ne me diras pas comment l'integrer à kbd.h???

C vrai que c pas con TInouveau

Je n'ai pas de loi à imposer selon mon bon plaisir, donc si tu y tiens : tu copies tout simplement le code du quarantième post dans kbd.h.

Y'a une sacrée difference en taille: sur mon projet j'ai gagné 1000 octets en 78 appels à la fonction et le clavier est plus réactif
Merci Thibaut
Et faite que dans les prochains TIGCC on utilise cette fonction à la plac ede leur _rowread

hé ouai

Attention cependant au sujet des 1000 octets, tu dois avoir une version de TIGCC assez ancienne, car dans la version que j'ai -la dernière- _rowread est une fonction, cela signifie que le gain de 1000 octets n'aurait pas été vérifié si tu avais eu cette version.

> Pourquoi attend-il 250 cycles d'horloge (pire que la plus lente des instructions : divs) alors que 48 sont suffisants, l'AMS lui-même attend 48 cycles !!!????
Réponds à ma question, nom d'un chien: où AMS attend-t-il 48 cycles ?
Avant de critiquer TIGCC, tu ferais bien de vérifier tes propres informations !
Ce que tu dis sur TIGCC est inacceptable (posts 2, 8,11...)
Ca m'aurait beaucoup étonné que PpHd t'ait dit qu'AMS attendait 48 cycles (il est bien plus compétent que cela)...
Je veux une réponse claire, nette et précise, de ta part, et pas l'argument d'autorité que tu m'as balancé et qui ne répond absolument pas à la question:

> C'est simplement la première fois que je vois ça !! Tous les tutos recommandent 48 cycles, et tous les programmes ASM open source que j'ai vu attendent tous 48 cycles !!! si ça ne suffit pas comme argument ?
NON, ça ne suffit pas. Je sais très bien que tous les programmes attendent 48 cycles, je ne suis pas un newbie, quand même. Ce que je te reproche, c'est de dire qu'AMS attend 48 cycles (ce qui, à ma connaissance, est archi-faux), sans donner de preuves, et de critiquer TIGCC car il attend 250 cycles (ce qui est trop, mais c'est moins de la moitié de ce qu'AMS attend).

Comme le disent squale92 et PpHd, ce n'est pas le fait d'accélérer de 200 cycles qui changera beaucoup la vitesse du programme:
"quoique, 200 cycles de différence, ça va pas changer gd chose... "
"De toute facon, c'est pas pertinent"
Je te le redis: fais un mail à Sebastian ou à Kevin pour qu'ils changent cela... Ils ne vont pas te manger... Tu peux même mettre not.b %d0 et essayer de t'attribuer cette optimisation (mais ça va être dur).

Thibault: même si tu n'aurais certainement pas fait un cirque pareil sur le forum officiel de TIGCC, je te signale que ce genre de comportement est une bonne cause de bannissement. En effet, critiquer les programmeurs qui ont passé des années, qui sont plus compétents que toi (je ne me mets pas dans ceux-ci, puisque je n'ai (presque) pas participé au code de TIGCC, et ça fait 9 mois que j'ai commencé sérieusement la programmation en assembleur) et braver les admins, ceci est une des façons d'être banni...

Bien entendu le ton dur que j'ai employé n'est destiné ni à Kevin, ni à PpHd, ni à squale92 (tiens, il reste qui ? ).

Une fois de plus, j'ai édulcoré le post avant de l'envoyer (sinon c'est moi qui risque d'être banni , même si je ne pense pas être celui qui attaque le plus le travail des autres et leurs propres personnes).

Ha làlà j'ai été provocateur mais je n'ai jamais été sincère en traitant votre code de "merde". Comme tu peux être fier pour t'énerver comme ça

D'ailleurs quand tu t'énerves tu as du mal à penser (autant que moi ), sinon tu n'aurais pas reposé la question à savoir où j'ai obtenu l'information comme quoi l'AMS attend 48 cycles.

Je n'ai jamais rien fait pour TIGCC mais c'est pas pour autant que je ne programme pas... bien qu'on puisse dire que j'ai fait quelque chose pour votre compilateur : Kevin m'avait FAIT CHIER pour que je vous offre des routines optimisées de la bibliothèque Azur (d'où est tirée la fonction des posts #36 et #40), et je vois qu'elles n'ont toujours pas été intégrées à TIGCC.

En bref, des fonctions optimisées j'en ai fait, et plein, c'est pour ça que je me permet de vous signaler les défauts des vôtres lorsque j'en aperçois.

Je reconnais que je n'aurais pas dû parler de "merde" hier, même si c'était ironique, parceque je vois que ça vous a énervés. Pardon, donc

Thibaut fait des excuses ! C'est bien.

C'est pas la première fois, je sais faire des excuses quand j'estime être en tort

Je me suis déjà à moitié excusé dans le post #36 en plus

OK. C'est vrai que tu t'es excusé au post 36.

Je veux mettre les choses au clair: ce qui ne m'a pas plu (entre autres), c'est que tu aies dit qu'AMS attendait 48 cycles (alors qu'il attend environ 900 cycles, d'après ce que je vois dans OSKeyScan). J'ai pris ce topic pour une nouvelle critique de TIGCC, c'est tout.
Par contre, ce que j'attends depuis le post 20, c'est une réponse claire de ta part, me disant où dans AMS, il y a une boucle qui attend seulement 48 cycles. C'est juste ça que je te demande, Thibault...

Désolé de m'imisser dans votre conversation, mais je pense que ceux qui attaquent TIGCC sont un peu fou, sans ce compilateur la programmation sur TI ne serais pas ce qu'elle est aujourd'hui

Cependant ça n'empêche que pour faire avancer le projet emmettre quelques critiques fait du bien

(Y'a pas de l à mon prénom )

je n'ai vu ça nulle part ! on dirait que tu ne lis pas tous les posts du topic
Va voir la première ligne du post #17 et la première ligne du post #25.

slubman> exact, sans TIGCC, la prog sur TI ne serait pas ce que c'est
il y aurait bcp moins de newbies passé pr coder un jeu raté et partir ensuite, vu que seuls les gars motivés à mort auraient appris l'ASM
(alors que plein de gars pas motivé (ou peu) commencent le C et laissent vite tomber, après avoir vu qu'ils ne pouvaient pas égaler les Grands Jeux en une semaine)

je sais de quoi je parle pr les newbies en C qui laissent tomber vite fait.