routine 240x128->160x100 - Page 2

Pourquoi les opérations, vous les faites en .W ? C'ets débile???

Primo, c'est un move.l d1,a0
Ensuite, c'est plus rapide de les charger a la main comme ca que de faire un movem.l zeroes(pc),d0...
Secundo, si une interruption survient, elle est en mode superviseur !
Donc, c'est clean.

Enfin il parait que movem.l bug qur HW1 ....

PpHd>arf ué, dsl, c vrai ke c + rapid qu'un movem.l zeroes(pc),d0-a7 ??

RV>houla...
et pour effecer l'écran tu fé comment?
[edit]Edité par sBibi le 24-01-2002 à 10:40:48[/edit]

double post
[edit]Edité par sBibi le 24-01-2002 à 10:41:07[/edit]

TiMad>mais c juste si c un movem vers la mémoire archive!

tienc vvrai ça, j'av pas fé gaffe ke tu faisais des move.w timad...
g fé un copier/coller... c move.l

Ouai.. enfin le move.w marche dans toutes les conditions... (Tigcc) bisard surtout que j'efface pas la parite haute... enfin bon. pas grave, cette routine est vielle et je ne l'utilise plus...

Si, si c'est normal. move.w d0,a0 : d0.w -> Temp = ext.l d0 -> a0 = temp.

bah tant qu'à faire, autant mettre move.l ... ça apporte rien là move.w

>PpHd: ba je peux te dire qu'entre la version à la com avec les move.l (a0)+,(a1)+ et celles avec les movem,

Tu as oublié la mienne:

 movem.l d0-d2/a0-a1,-(a7)
 pea.l ($3840).w ;taille
 pea.l (a0) ;source
 pea.l (a1) ;destination
 move.l $c8,a0
 move.l memcpy*4(a0)
 jsr (a0)
 lea.l 12(a7),a7
 movem.l (a7)+,d0-d1/a0-a1

ué, bon... la tienne se rapproche + de a version à la con...

C'est clair
Kevin est prêt à se ridiculiser pour promouvoir l'utilisation des ROM_CALLs, il est vraiment fanatique

Il y a une différence.
La version "à la con" serait:

 movem.l d0/a0-a1,-(a7)
 move.w #3839,d0
next: move.b (a0)+,(a1)+
 dbra.w next
 movem.l (a7)+,d0/a0-a1

memcpy utilise du déroulement de boucle (loop unrolling) intensif, et des move.l quand il y a des groupes de 4 octets. On ne peut pas aller plus vite à moins de dérouler entièrement la boucle, vu que movem est à proscrire si la source pourrait être en mémoire archive. Et puis les ROM_CALLs sont faits pour être utilisés. Et ça évite de réfléchir sur l'implémentation.
[edit]Edité par Kevin Kofler le 24-01-2002 à 16:23:15[/edit]

Pphd: ok merci

Kevin>si tu veux la routine la plus rapide possible, fais tout toi même, ne fais pas confiance à d'autre programmeurs si tu ne les connais pas, et surtt si c les programmeurs de chez ti... ki ont écrit ams en c, et qui ont l'air de tellement bien connaître l'asm... de tte façon, pour effacer un écran, c'est TOUJOURS de move.l que tu utilises, donc les tests que fait ce rom_call pour savoir si il peut ou non faire move.w ou move.l sont INUTILES pour effacer l'écran!!
utiliser les rom calls, ça va pour utiliser dans un prog ou un morceau à temps d'exécution non critique, comme par exemple le menu d'un jeu... là d'accord, tu peux utiliser des rom_calls, mais si tu es dans une boucle critique, comme par exemple, dans la boucle principale d'un jeu, utiliser les rom calls ne peut que ralentir considérablement et pourrir ton prog...

Erf il y a un truc qui est pas mal... c'est de lancer une instruction du genre:
IniClrScr(); qui cree ta fonction en ram et ensuite de l'executer avec un jmp ou autre...
... ca prend pas beaucoup de place et c'est plutot efficace... d'ailleur ca s'adapte parfaitement au lib nostub on calc...

M'enfin, tout ca reste a des annees lumieres de :
gl_set_dscreen_int(dscr1);
gl_set_dscreen_function(dscr2);

Mais non mais non

Il y a plus facile: tu mets tout simplement 960 fois clr.l (a0)+ (ou encore mieux: 959 fois clr.l (a0)+ et une fois clr.l (a0)). ExePack compressera ça très bien.
[edit]Edité par Kevin Kofler le 25-01-2002 à 12:14:03[/edit]

il va compresser ca en combien d'octet?

Puis moi d'habord, il m'en faudrait 1920 pour ne pas faire de boucle et voir plus

Programme vide compressé: 120 octets avec headers PC.
Programme contenant 960 fois clr.l (a0)+ compressé: 146 octets avec headers PC.
--> Taille nette: 26 octets.
Programme contenant 959 fois clr.l (a0)+ et une fois clr.l (a0) compressé: 147 octets avec headers PC.
--> Taille nette: 27 octets.

cela devient en effet tres interessant.. le probleme, c'est la ram que cela va prendre apres .....
[edit]Edité par TiMad le 25-01-2002 à 20:11:23[/edit]

Et une fois moveq #0,d0
Puis 960 fois :
move.l d0,(a0)+

Ca ne sert a rien d'enlever le (a0)+ final.

Tu as raison dans les 2 cas. (Je suis relativement bon, mais pas parfait, en optimisation en taille, mais je suis absolument nul en optimisation en vitesse - je n'ai pas encore trouvé comment remplacer -Os par -O3 dans mon cerveau .)
[edit]Edité par Kevin Kofler le 25-01-2002 à 18:27:56[/edit]

On peut se poser des questions:
Avec la compression, le devellopement de boucle prend moins de place (3* moins)

Faut il favoriser la place de la memoire avant execution, ou alors la memoire necessaire avec execution... car ma lib demande pres de 10 ko de ram pour l'execution....