de l'ASM dans du C .... - Page 2

voila, j'ai fait le test suivant :

en retirant la ligne du memset, puis en mettant la ligne du memset.

ben je passe de 500Fps a 350Fps.... snif

Je ne suis pas sur que tu puisse faire mieux en assembleur. C'est possible certes, cependant.

mon code est optimiser, mais le Memset + le copy d'ecran virtuel me fait passer de 500Fps a 185 Fps our mon cube.. c pour ca....

je suis sur k'il ets possible de trouver une routine plus rapide, meme si elle prend plus de memoire, je m'en fou, tout ce ke je veux c tres rapide....

Ok. Regarde les routines d'extgraph pour l'effacement d'ecran.

mais la est le pb.... je c pas comment marche l'ASM, je c pas comment adapter une routine ASM pour k'elle marche avec mon prgm (cf post 24)...

g deja regarder extgraph, et je suis completement perdu....

Prend la routine tel que.

ben justement !! c ca mon pb !! je c pa comment l'adapter, comme je l'ai demander au POST 24

Est-ce que TAILLE est fixe ?

justement, non...

soit il vaut la taille de la TI92+, soit la taille de la TI89

Si ca reste fixe
Deux tailles, deux routines puis voilou.

tu veux dire passer par une procedure ? justement, je ve pas !!!! ca fais perdre trop de temp!!!!!!!!!

c bien une boucle la remise a zero, non ?
moi je pensais ke ca fesait une boucle a partir de l'adr de depart, et ce de 16 et 16 bit en mettant un long egual a 0 ? c pa ca ?
du style :

for (pointeur=ECR_TEMP;pointeur<ECR_TEMP+TAILLE;pointeur+=16)
&poiteur=(long)(0);

c pa ca ?

Le mieux je pense est que tu ais un buffer de même taille (128*240/8) quelle que soit la plateforme

c sur, mais dans ce cas la, je perd de la meme pour rien sur 89 ....

On s'en fout. S'il a besoin de tant de MEM sur TI92+, alors qu'il ait autant besoin de MEM sur 89 ! Tout le monde fait ça. Et ça simplifie pas mal les choses... pas vrai ?

bon ok, va pour ca, on fixe la taille à 240*128, mais pour le reste ?????

He bien c'est là que j'interviens par rapport au problème, j'attendais que tu prennes cette sage résolution

Je vais te passer ce qui t'intéresses dans les sources de ma librairie graphique GraphX, qui fait partie du SDK Azur.

elle est rapide ta proc ? par rapport a memset et extgraph ?

J'en sais rien, je n'ai jamais vu les sources d'ExtGraph. Essaie, tu verras. Par rapport à memset, oui c'est plus rapide.

J'ai pris la peine de convertir le truc en ASM GNU. Normalement tu n'as plus qu'à insérer ce qui suit dans ta source, et à appeler les fonctions aux moments voulus

#define GX_PLANE unsigned char

extern void
 GX_clrscr    (GX_PLANE *Plane),
 GX_CopyBuffer(GX_PLANE *Dest, GX_PLANE *Src);

asm("
GX_clrscr:
; Code optimise par Julien Monville
 movem.l %d3-%d7/%a2-%a7,GXSvgReg
 move.l  4(%a7),%a7
 lea     3840(%a7),%a7
 moveq   #0,%d0
 moveq   #0,%d1
 moveq   #0,%d2
 moveq   #0,%d3
 moveq   #0,%d4
 moveq   #0,%d5
 moveq   #0,%d6
 move.w  %d0,%a0
 move.w  %d0,%a1
 move.w  %d0,%a2
 move.w  %d0,%a3
 move.w  %d0,%a4
 move.w  %d0,%a5
 move.w  %d0,%a6
 moveq   #10,%d7
GXCS_loop:
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 dbf     %d7,GXCS_loop
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0-%a6,-(%a7)
 movem.l %d0-%d6/%a0,-(%a7)
 movem.l GXSvgReg(%pc),%d3-%d7/%a2-%a7
 rts


GX_CopyBuffer:
 movem.l %d3-%d7/%a2-%a7,GXSvgReg
 move.l  4(%a7),%a6
 move.l  8(%a7),%a7
 moveq   #11,%d7
CB_loop:
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,(%a6)
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,52(%a6)
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,104(%a6)
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,156(%a6)
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,208(%a6)
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,260(%a6)
 lea     312(%a6),%a6
 dbf     %d7,CB_loop
 movem.l (%a7)+,%d0-%d6/%a0-%a5
 movem.l %d0-%d6/%a0-%a5,(%a6)
 movem.l (%a7),%d0-%d6/%a0-%a3
 movem.l %d0-%d6/%a0-%a3,52(%a6)
 movem.l GXSvgReg(%pc),%d3-%d7/%a2-%a7
 rts


GXSvgReg:
 ds.l    16
")

Il veut des macros

pff franchement le temps d'appel/dépilage est totalement négligeable devant le temps de copie. Il ne verra aucune différence s'il l'implémente en macro, j'en mets ma main au feu.

Ne touche pas à GX_CopyBuffer si l'écran source est dans un fichier externe archivé, ça plantera sur HW1 (parce que quand on lit en mémoire archive avec movem, la HW1 croit qu'on exécute du code à cause des plus de 2 lectures successives).

PphD a raison ! je veux pas appeler une fnc, car REELLEMENT, ca me fait perdre bcp de FPS, alors vu ke je n'utilise ces 2 fns qu'une fois, te (thibaut) serait-il possible de les modifier pour directement inclure ECR_TEMP et ECR_SRC dans ton code? en tout cas, merci pour ton aide...

Ca te fait réellement perde du temps... Je n'y crois pas du tout. Tu peux me donner les preuves ?
Sinon, attention à ce que dit Kevin, il a raison. Cette routine est très efficace, mais il y a un bémol : sur les HW1 elle fera planter la calto si Src est en FlashROM.

le bemol : c pa grave, je n'utilise ke des ecran temporaire du prgm -> ils sont pas archivé.

parcontre, je te jure, g fais le test avec une procedure tout conne

1°test : le code directement sans procedure
2°test : en passant par une procedure

ben le 1 est plus rapide ke le 2

et encore un autre test :

ds n'importe kel prgm

1°test : le prgm tel kel
2°test : le prgm avec un plein milieu un appel de procedure avec des paramettres, mais cette procedure ne fair rien, il y a juste { }

ben 1 est plus rapide ke 2, et plus on passe d'argument dans la procedure, plus ca ralenti.... je te jure, c vrai... d'ou le fait que je ne veuille pas utiliser de procedures....

Ok c'est ce que je pensais. Tu as testé avec des fonctions (on dit pas "procédure" en C (m'énerve ce clin d'oeil il est moche)) vides.

Comme dit mon pote Einstein, "tout est relatif".
Car si maintenant tu testes avec des fonctions qui font quelque chose, et qui mettent pas mal de temps à le faire (comme GX_CopyBuffer), alors le temps de [passage des paramètres+appel+retour+dépilage] devient vraiment minuscule devant le temps d'exécution de la routine.

vi, mais ce temps "minuscule" comme tu dis, c juste a ca ke je fais la guerre depuis 2 moins ds mon prgm pour essayé de gratter des FPS... d'ou mon choix d'utiliser le moins possible de procedures, meme si le prog en devient plus dur a lire....

Ca ne te fera gagner aucun FPS à mon avis ! Bien, il va te falloir attendre le retour de Kevin, moi je ne sais pas comment "macroïser" du code ASM.