Le _rowread de TIGCClib - Page 1

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 !!!????

-

bah il suffit de mater la source en connaissant un minimum l'ASM 68k

Bon alors le programmeur de cette fonction a eu envie de ralentir les programmes des utilisateurs de TIGCC déjà bien lents, ou quoi

houla...
va falloir que je regarde ça
quoique, 200 cycles de différence, ça va pas changer gd chose...

Genlib rulezzzzz

squale : C'est un ralentissement inutile

Uther Lightbringer: 100% d'accord.

Thibaut> certes

PpHd : t'es pas d'accord que certains programmeurs de l'équipe TIGCC sont mals renseignés et responsables de la lenteur et de la grosseur des programmes générés avec TIGCC ?

M'en fous. J'utilise jamais rowread

vu le taf de fois que je l'utiliser dans KII...
en supprimant 200 cyle à chaque _rowread, je devrai gagner queleuqe chose comme un bon millier de cycle par boucle (voire même 2 milliers)

Possible, personnellement j'ai gagné en fluidité dans Einstein en remplaçant la merde de TIGCC par celle de la bibliothèque Azur (au fait la doc, elle avance squale ? )


Boycottons TIGCClib

Thibaut> pr la doc, j'ai dit que ce serait la seconde chose que je ferai pdt les vacances
=> je m'y met qd le tuto C sera entièrement relu et corrigé. et mis en page nikel.

Je sais Je te charriais

erf

Voici le source de _rowread (TIGCC 0.94 Beta 15) sans les commentaires:
.data
.xdef _rowread
_rowread:
move.w (%sp,4),0x600018
move.w #24,%d0
0:
dbra %d0,0b
move.b 0x60001B,%d0
not.b %d0
and.w #0xFF,%d0
rts

Est-tu sûr que la routine de _rowread d'AMS n'attend que 48 cycles ?
La seule routine que je connaisse (mais je n'ai pas la prétention de tout connaître) dans AMS, qui ressemble à un _rowread, est située à $220000/$420000 sur AMS 2.03. Mais elle attend bien plus que cela (59 dbra et pas 25)...

J'espère seulement que ce sujet n'est pas une nouvelle critique gratuite de TIGCC...

Arg mauvais code !
.data
.xdef _rowread
_rowread:
move.w (%sp,4),0x600018
moveq #24,%d0
0:
dbra %d0,0b
moveq #0,%d0
move.b 0x60001B,%d0
eor.w #0xFF,%d0
rts

C'est PpHd je crois qui m'avait dit une fois que c'était 48.

Et tous les tutos d'ASM recommandent environ 12 nop d'attente, soit 48 cycles !

Et si ces deux arguments ne suffisent pas, alors passons à la pratique : chez moi (HW2) tout a toujours très bien fonctionné avec 48 cycles et même un peu moins.

> "t'es pas d'accord que certains programmeurs de l'équipe TIGCC sont mals renseignés et responsables de la lenteur et de la grosseur des programmes générés avec TIGCC"
Ben voyons...
Je sens qu'il y en a qui ne vont pas apprécier...
C'est bien ce que je disais (car je m'étais déconnecté 1/2 heure avant de poster, je n'avais pas vu les posts ultérieurs au post n°3): c'est la critique gratuite de TIGCC (et même de l'attaque personnelle, comme d'habitude, pour tous ceux qui ont contribué à TIGCC).
Est-ce que par hasard, tu rechercherais des vêtements pour l'hiver ?

Zut, je n'avais pas vu les derniers posts...
Si la lenteur ne te plaît pas, écris à Kevin ou à Sebastian, ils se feront un plaisir de changer (une critique constructive, c'est bien).

Hé, cher Lionel, faut savoir accepter les critiques. Quand y'a un défaut dans TIGCC faut pas le laisser, faut en parler.

Sinon, je suis désolé, mais sur ce point (nb de cycles) vous étiez mal renseignés. Faut pas le prendre mal, ça peut arriver même aux plus grands.

> Hé, cher Lionel, faut savoir accepter les critiques.
Seulement si elles sont fondées...

> Quand y'a un défaut dans TIGCC faut pas le laisser, faut en parler.
Parfaitement d'accord. Les critiques constructives sont les bienvenues.

> Sinon, je suis désolé, mais sur ce point (nb de cycles) vous étiez mal renseignés. Faut pas le prendre mal, ça peut arriver même aux plus grands.
A propos de cela:
Thibault et PpHd, montrez-moi où AMS attend 48 cycles... Je veux savoir pourquoi j'ai faux. Et je ne me considère pas forcément comme un des plus grands (Kevin, Zeljko, Thomas, Sebastian... sont bien plus grands que moi).
J'ai scanné les nops dans AMS 2.03: il n'y a aucune suite de nops qui puissent faire 48 cycles, aucune combinaison de nops ou de dbf qui puissent le faire.
Par contre: OSKeyScan (qui est la routine où AMS attend) fait:
move.w #$58,d0 // Notez le $
dbf d0,-$0
Pour moi, cela fait bien plus de cycles que 48...

-

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 ch !!!
si ça ne suffit pas comme argument

Ben moi je sais pas ou j'ai dit que 48 cycles suffisait, alors.

Je ne sais plus qui me l'avait dit, PpHd !

Toujours est-il que tu utilises beaucoup moins que 250 ch dans tes progs, non ?

Ben dans preos, je fais comme AMS, $58 pour tester ESC. De toute facon, c'est pas pertinent. Et dans mes jeux, ben ca fait longtemps que je sais plus.

PpHd a écrit :
Arg mauvais code !
[...]
eor.w #0xFF,%d0 rts

Ben, si on utilise un eor.w #0xFF, on arrête de critiquer le code des autres! Bravo pour le gaspillage de place en tout cas! Un not.b %d0 prend 2 octets de moins!

Et le moveq #0,%d0 n'est pas vraiment nécessaire. Vu qu'on retourne un short, clr.w %d0 suffit. Mais bon, c'est la même taille et la même vitesse, donc on s'en fiche.

Thibaut
a écrit : Hé, cher Lionel, faut savoir accepter les critiques. Quand y'a un défaut dans TIGCC faut pas le laisser, faut en parler.

Oui, mais à nous, pas à toute la communauté!
Mais bon, ça dépend surtout du ton. Le ton du message de départ va très bien. Celui du message #2 est vraiment limite! Celui du message #11 est totalement inacceptable! Je ne supporte pas qu'on traîte notre travail de plusieurs années de "merde"!

XDanger a écrit :
> Sinon, je suis désolé, mais sur ce point (nb de cycles) vous étiez mal renseignés. Faut pas le prendre mal, ça peut arriver même aux plus grands.
A propos de cela:
Thibault et PpHd, montrez-moi où AMS attend 48 cycles... Je veux savoir pourquoi j'ai faux. Et je ne me considère pas forcément comme un des plus grands (Kevin, Zeljko, Thomas, Sebastian... sont bien plus grands que moi).
J'ai scanné les nops dans AMS 2.03: il n'y a aucune suite de nops qui puissent faire 48 cycles, aucune combinaison de nops ou de dbf qui puissent le faire.
Par contre: OSKeyScan (qui est la routine où AMS attend) fait:
move.w #$58,d0 // Notez le $
dbf d0,-$0 Pour moi, cela fait bien plus de cycles que 48...

J'ai toujours dit que AMS attend trop longtemps et que 12 nops ou l'équivalent en dbra suffisent! (Cherche sur notre forum, il y avait une discussion sur ce sujet.) Toutes les docs du matériel le disent (sauf la "doc du matériel" très incomplète du SDK de TI), et les auteurs des docs du matériel savent bien ce qu'ils disent. (Ils ont tout essayé en général.)

Et toc le Kevin a parlé



Heu Kevin on dit :
notre travail de plusieurs ANNEES...

C'est corrigé.