Question :: nvg - Page 2

Empiler ou passer en paramètre prend du temps supplémentaire aussi.
un lea x(an),am prend 8 cycles.
un move.l d(pc),an en prend 16...
un pea d(pc) 16

TiMad
a écrit : mais c'est uand meme lent!

Pas plus lent que ce que tu fais actuellement (au contraire).

sans parler de les dépiler après bien sûr si on passe pas par registre

Ximoon a écrit :
Empiler ou passer en paramètre prend du temps supplémentaire aussi.
un lea x(an),am prend 8 cycles.
un move.l d(pc),an en prend 16... un pea d(pc) 16

GCC gardera les variables fréquemment utilisées dans des registres, donc en utilisant le passage par registres correctement, on a le tout en 0 cycles. En l'utilisant mal, on l'a quand-même en 4 cycles (move entre 2 registres).

tu veux dire que GCC gardera 2 registres bloqués comme ça?
Et de toutes façon, tu es d'accord qu'une fois l'offset calculé pour aligner le sprite il faudra l'ajouter aux deux adresses?
pour le second registre il faut donc rajouter 8 cycles d'un adda.l dn,an

donc il faut non seulement cette addition en plus du passage des paramètres en face du seul lea qui lui en fait 8

Ximoon
a écrit : tu veux dire que GCC gardera 2 registres bloqués comme ça?

Si c'est la solution qui donne le code meilleur, oui.

Et de toutes façon, tu es d'accord qu'une fois l'offset calculé pour aligner le sprite il faudra l'ajouter aux deux adresses?
pour le second registre il faut donc rajouter 8 cycles d'un adda.l dn,an

donc il faut non seulement cette addition en plus du passage des paramètres en face du seul lea qui lui en fait 8

Soit...
Mais en tout cas, ce n'est certainement pas une différence qui compte vraiment (dans un sens ou dans l'autre). Et carrément pas une qui vaut 3840 octets de RAM.

J'ai calculé, Kevin, et il me semble que c'est un poil plus rapide et plus court de n'avoir qu'un gros buffe qui contient deux plans de 3840 octets chacun :
Si on passe l'adresse de chaque plan à la fonction : on a 3 registres d'adresses utilisés (adresse du sprite + adresse de chaque plan), donc on aura au moins un regsitre à "clobberer" (je ne connais pas le terme français), ce qui prend 24 cycles d'horloge. Ensuite, quand on calculera l'offset, on aura deux registres à incrémenter au lieu d'un (donc ça rajoute 8 cycles).
Après pour ce qui est de la boucle d'affichage, on gagne quelques petits cycles (4) parce qu'on fait un or.l dn,(a1) au lieu d'un or.l dn,3840(a0), mais on les perd tout de suite après quand il s'agit de pointer sur la ligne suivante de l'écran : un seul lea.l 30(a0),a0 suffit dans le cas de figure où on utilise un seul buffer, tandis qu'il en faut 2 (un pour chaque plan) dans l'autre cas. Cette instruction prend 8 cycles.
Donc au total, on perd 32 cycles en dehors de la boucle + 4 cycles par ligne de sprite (sauf si on déroule un peu la boucle : dans ce cas, on perd moins), donc pour un sprite 16x16 (la taille la plus fréquente) : 32+4*16 = 96 cycles.
Ce n'est pas très important, mais ça fait une petite différence quand même.

si Kevin, quand tu dois dessiner massivement dans les buffers, et que quasiment tout ce qu'il y a dans les boucles critiques sert a modifier les pointeurs sur les plans, tu peut gagner beaucoup en ayant les deux plans colles l'un a l'autre en mem.

non mais c'est vrai que 30 octet de plus c'est trop
c'es d'un ridicul.. tanpis, je vais modifier la routine et la rajouter a Xlib, mais apres faut pas s'etonner qu'on modifie vos routines comme ca, elle sont pas du tout souple, et vous etes inflexible!

Et puis les fonctions d'affichage de sprite pourront être plus petites, donc ça compensera légèrement les 30 octets de plus.

beinsur!
apres pour compenser, je peux faire un dbf par 2 au lieu de 4 (il me semble...)
donc le gain c'est 1 Ko en moins minimum!

Trust
a écrit : tanpis, je vais modifier la routine et la rajouter a Xlib

Très intelligent...
Comme ça, vu la fréquence à laquelle tu mets à jour Xlib, si on corrige un bogue, les utilisateurs de Xlib devront attendre au moins un an que le bogue soit corrigé pour eux...

Adapte les routines de sprites aux routines de gris, pas l'inverse!

La raison principale pour laquelle je refuse de modifier les routines de gris n'est pas la taille de la routine elle-même, mais le fait que ta "solution" gaspille 3840 octets de RAM sur HW1 pour un gain de vitesse soit inexistant, soit totalement négligeable!


Et jackiechan, pour éviter de détruire un registre d'adresses an|n>1, tu peux mettre la différence entre les 2 adresses des plans dans un registre de données et adresser le deuxième plan en x(an,dn). Mais je ne peux pas te dire à priori si c'est une optimisation ou une pessimisation.

Et d'ailleurs, si tu traffiques nos routines de gris, il ne faut pas t'étonner que tes routines soient rejetées pour l'intégration à TIGCCLIB (et qu'ExtGraph est choisie à la place, comme prévu depuis le départ de toute façon).

Non! il est tout a fait possible de recuperer les 3840 pour HW1!
je ne voit pas ce qui pose probleme...

Et pour XLib oui je le reconnais, mais theoriquement dans 4 semaines se devrait etre mieux (si ce n'est pas reporter pour 1 ans..)

Il est peut-être possible de les récupèrer dans certains cas, mais ça fait du travail supplémentaire au programmeur, et donc il ne le fera probablement pas. Il est beaucoup plus pratique de les utiliser dans la routine de niveaux de gris.

bof.. je proposerait un sauvescreen personalisé en fonction du hard comme ca plus de probleme

Tu n'as pas encore plus compliqué? Le code de démarrage est censé être le plus simple et compact possible. Il n'est pas censé dépendre de l'utilisation ou non des niveaux de gris, de la version matérielle, ... Et puis, la solution que tu proposes va foirer à coup sûr si un programme utilise en partie des niveaux de gris, et en partie du blanc&noir (comme par exemple Backgammon). Donc c'est non.

ce sera oui... et puis je vois pas pourquoi revenir en mode b&W.. il suffit de l'emuler avec XLib...

Trust
a écrit : ce sera oui...

Non, ce sera non. Ce sommes nous qui contrôlons la routine SAVE_SCREEN. Et ne perds pas ton temps à la traffiquer, tu devras tout refaire quand TIGCC 0.95 sortira. Le code de démarrage a été complètement repensé. (Et: non, je ne t'enverrai pas de preview.)

et puis je vois pas pourquoi revenir en mode b&W.. il suffit de l'emuler avec XLib...

Tout le monde n'utilise pas XLib!

bien oui, mais vu que l'equipe tigcc ne veux pas s'adapter aux routines graphique, je vais faire mes modification pour XLib... et ceci parce que vous ne voulez pas change 2/3 lignes de code.
Je respecte votre decision, mais je doti modifier mon code!

Oui, tu dois modifier ton code, pas le nôtre!

Avec le preprocesseur je vais juste faire qqc dans le genre:
#ifdef SAVE_SCREEN
#error [XLib __Xversion__ ] :: Remove #define SAVE_SCREEN.

tout simplement, est-ce que mettre un
#undef SAVE_SCREEN
ne fonctionnerait pas ?

ouai mais faut prevenir quand meme non?
je trouve que c'est plus sympat de prevenir le gas qu'il utilise pas la routine TIGCC et que par consequent si il y a un bug, c'est pas TIGCC qui est responsable, mais la XTeam

certes

raisonnement acceptable

Si c'est pour prévenir, un utilise un #warning, pas un #error!

non parce que sinonil sauvegradera 2 fois le lcd ce qui est vraiment pas utile...
donc un error s'impose..

Si tu ne veux pas que ça soit possible d'utiliser SAVE_SCREEN et en même temps prévenir, il y a 2 choix:

#ifdef SAVE_SCREEN
#undef SAVE_SCREEN
#warning "blabla"
#endif

#ifdef SAVE_SCREEN
#error "blabla"
#endif

Le premier désactivera SAVE_SCREEN en prévenant, le 2è demandera à l'utilisateur de le désactiver lui-même...

Il y a aussi_
#ifdef SAVE_SCREEN
#warning "blabla"
#endif
qui est ce qu'il faut faire. Oui, XLib sauvegarde aussi l'écran, mais seulement à l'intérieur de XLib! Rien ne te dit que l'utilisateur n'utilise pas en partie XLib et en partie du blanc&noir standard, ou des niveaux de gris de TIGCCLIB (8 niveaux de gris par exemple)!