Boucle For transformé en asm - Page 1

Bonjour,

J'ai demandé aux plus doués des programmeurs de m'aider, ici:
http://www.purebasic.fr/french/viewtopic.php?f=12&t=12926

Car j'ai mis au point un double scrolling (différentiel ?), et en rajoutant une nouvelle boucle, bien sûr ça rame. Mais sans cette boucle, c'est bien mieux.

80 sprites en tout + 5 autre sprites (personnage et chiffres)
1er plan: 24 sprites d'une taille de 48x24
2eme plan: 56 sprites d'une taille de 24x24

Optimiser en assembleur les boucles pour le 2ème plan sera une grande avancée en terme de fluidité.

Bien à vous

Et ? Tu veux qu'on fasse le code à ta place ?

Commence par optimiser tes algorithmes avant de penser à l'assembleur.

move.w #40,d0 loop: [...] dbra d0, loop

Zerosquare (./2) :
Et ? Tu veux qu'on fasse le code à ta place ?

Commence par optimiser tes algorithmes avant de penser à l'assembleur.

Heu, non, vous n'avez pas à vous pencher sur le problème, j'ai demandé de l'aide sur un autre forum en fait, ils sont très doué en langage d'assemblage.

oui, j'ai oublié de préciser que je bosse sur une adaptation d'un jeu d'arcade, afin de tester en condition réelle, pour voir jusqu'où je peux aller en fait.

beauregard (./5) :

Zerosquare (./2) :
Et ? Tu veux qu'on fasse le code à ta place ?

Commence par optimiser tes algorithmes avant de penser à l'assembleur.

Heu, non, vous n'avez pas à vous pencher sur le problème, j'ai demandé de l'aide sur un autre forum en fait, ils sont très doué en langage d'assemblage.

Il y en a un paquet doué en ASM ici, c'est pas le soucis, mais Godzil a balancé le mauvais asm. (Il donne du 68000 et la encore il c'est planté, pour le 2 plan c'est 56 sprites pas 40 a prendre au second degré).

Ce que Zero voulait faire passé comme message, c'est que parfois rien que le fait de rearrangé / repensé son code permet de gagné de précieux cycles.

Par exemple sortir certains calculs de la boucle, partie qui n'a pas besoin d'etre calculé a chaque boucle, etc.... Codé en asm permet effectivement de gagné de la vitesse, mais un algo 'pourri' en asm sera plus lent qu'un rapide en C.


GT Pour l'optimisation \o/

beauregard (./5) :
j'ai demandé de l'aide sur un autre forum en fait, ils sont très doué en langage d'assemblage.

Oui, je suis sûr que sur un forum qui est dédié à un BASIC pour Windows, ils sont très doués en assembleur 6502... En plus, vu comment est formulé ton post, ils vont sûrement avoir envie de t'aider

ce sont tes multiplications qui foutent la merde...


en plus, X*8, c'est mieux de le faire en X lshift 3 (qui s'écrit généralement X<<3 )

for(lecx=(grpx*8) ; lecx<(grpx*8)+8; lecx++)
ça serait plus rapide avec un
truc=grpx*8;for(lecx=truc ; lecx<truc+8; lecx++)

sinon à la première boucle il doit calculer grpx*8 et il le refait à chaque boucle dans le test...

Oui, j'avais compris que c'était de l'humour, d0 pour le 68000, Accumulateur pour le 6502, j'ai parcouru quelques bouquins d'assembleur pour l'Atari 800. Pour le score, je fais le test 1 fois sur 5, j'en avais parlé ici, j'ai laissé des codes. Mais je ne peux faire plus pour optimiser, je n'ai pas fait de longues études d'ingénieurs donc j'aurai toujours des lacunes. Je suis condamné au système D

chose à savoir sur les boucles : à chaque test, il ne faut pas avoir à refaire un calcul

beauregard (./10) :
Mais je ne peux faire plus pour optimiser, je n'ai pas fait de longues études d'ingénieurs donc j'aurai toujours des lacunes.

Mauvaise excuse : GT est pas ingénieur, il est garagiste

je suis pas ingénieur non plus

et même si c'est ce qu'ils marquent sur les feuilles de paie, de statut toussa... j'ai jamais passé le diplome...

vince (./9) :
ce sont tes multiplications qui foutent la merde...


en plus, X*8, c'est mieux de le faire en X lshift 3 (qui s'écrit généralement X<<3 )

for(lecx=(grpx*8) ; lecx<(grpx*8)+8; lecx++)
ça serait plus rapide avec un
truc=grpx*8;for(lecx=truc ; lecx<truc+8; lecx++)

sinon à la première boucle il doit calculer grpx*8 et il le refait à chaque boucle dans le test...

j'ai apporté les modifications, merci. C'est vrai que c'est bien plus fortiche comme ça, lumineux même
Par contre je ne comprend pas la signification Ishift << je l'ai déjà vu quelque part, mais où ?... je regarde sur le site le 0 en me grattant la tête.

Lshift (L comme Left, je suppose)
En binaire, un décalage vers la gauche de n bits correspond à une multiplication par deux puissance n (de la même manière qu'ajouter n zéros à droite multiplie par dix puissance n en base décimale)

Or, 2^3=8, donc décaler un entier à gauche de trois bits retourne cet entier multiplié par 8.


Mais bon, en pratique j'imagine que ton compilateur applique déjà ce genre d'optimisations.

Pen^2 (./16) :
Mais bon, en pratique j'imagine que ton compilateur applique déjà ce genre d'optimisations.

justement, pas nécessairement, les opérations arithmétiques peuvent être sous traitées par le copro (ça va dépendre du type de variables manipulées pour être précis) et les allers-retours sont souvent plus couteux que le calcul...

J'imagine que Pen^2 voulait dire que les multiplications par 2^N sont automatiquement optimisées en décalages de N bits par le compilateur et que ça ne sert donc à rien de rendre le code moins lisible en écrivant ce genre d'opération explicitement, ce en quoi je crayonne.

(par contre, ça n'est pas forcément vrai pour les décalages vers la droite, selon que le nombre est signé ou non)

ah ok , dans ce cas je suis d'accord

Zeph (./18) :
J'imagine que Pen^2 voulait dire que les multiplications par 2^N sont automatiquement optimisées en décalages de N bits par le compilateur et que ça ne sert donc à rien de rendre le code moins lisible en écrivant ce genre d'opération explicitement, ce en quoi je crayonne.

Ca va dépendre du compile, si c'est un compilo C pour 6502, suivant lequel c'est (i.e. un dérivée de LCC), ce n'est pas GCC et les optimisations sont souvent peu présentes.

Sinon oui mon post plus haut était la juste pour détendre l'atmosphère et faire rire un peu (et ce type de boucle peux marcher dans un cas, mais pas forcement dans tous, d'ailleurs je déconseillerais ce type de boucle sur un 6502, il vaux mieux dérouler plus, le 6502 a peu de registres,il faut les conserver. Apres ça dépend l'utilisation de la page 0, bref, l'algo (et le program en général) sont tres lié aux optimisations que tu peux faire...

Si c'est l'ancien compilo C pour la Lynx, il est pourri (mais vraiment), donc ça m'étonnerait pas du tout qu'il n'optimise pas les multiplications/division par 2^N.

pour le compilo C. Ca doit pas être dur de vérifier soit sit en passant mais pas le temps.
Pour en revenir au topic, il y a quelques pistes simples, déjà celle que donne Vince, si un calcul identique doit être fait à chaque itération de boucle, il vaut mieux le stocker en amont dans une variable…

./18 oué voilà

Zerosquare (./12) :
Mauvaise excuse : GT est pas ingénieur, il est garagiste

Zero a été plus rapide que moi Oui je suis mécanicien auto (Bac pro en maintenance 'zotto'). Donc cela n'empeche pas de pouvoir optimisé, quand on commence a programmé, on est emerveillé de voir ce que ce sont capables les autres, mais en fin de compte en prenant un peu de recul, on arrive a faire pareil, voila un exemple perso, une routine de filtrage pour image :

move.l a1,a2
move.l a1,a3

move.w Real_channel,d4
move.w d4,d3
subq.w #1,d4
Make_all_channels_filtre_1:
moveq #0,d0 ; Le premier a rien
move.l a2,a1

move.w Nb_repeat_filter,d7

Application_du_filtre_1:
add.b d0,(a1) ; 12+4
move.b (a1),d0
add.w d3,a1
dbra d7,Application_du_filtre_1
add.w #1,a2
dbra d4,Make_all_channels_filtre_1

move.l a3,a1
add.l Line_offset,a1 subq.l #1,a1

Et maintenant :

move.l a1,a2
move.l a1,a3

add.w Pix_size,a3

move.w Line_size,d7
sub.w Pix_size,d7 ; car on traite pas le premier pixel

Application_du_filtre_1:
move.b (a2)+,d0
add.b d0,(a3)+ ; 12+4
dbra d7,Application_du_filtre_1
add.w Line_offset_raw,a1

Plus court, plus rapide, plus propre, le gain ? 70% !!! Et les deux sont de l'assembleur !! Une technique est parfois de reecrire completement la routine, en 'oubliant' ce qu'on a ecrit avant. On se garde l'ancienne bien au chaud et on repart a zero, meme en preparant sur une feuille de papier.

GT Adore optimisé !!

Oui c'est clairement ton code C qu'il faut revoir avant de passer en ASM.
C'est difficilement comprehensible.
Je n'ai pas regarde en details, pas facile de voir ce qui est faisable sans comprendre ce que tu souhaites faire, mais tu peux peut etre :
* sortir ton if (level==1) de la derniere boucle
* supprimer if (tile_x == 2+lecx) et l'incorporer dans la boucle lecx directement
* fusionner grpx et lecx.
* Te separer des multiplications, les * 7, *24, %29 en particulier (changement de l'algo, tableau pre-calcule, increment (comptey+=24), ...), c'est tres couteux sur la lynx
* Derouler ta boucle comptey
* Utiliser le type le plus petit possible pour tes donnees et variable et unsigned si possible, i.e. tes trucs de 0 a 6 ou 0 a 7 n'ont pas besoin d'etre int.
* Ne pas refaire les meme calculs 50 fois, i.e. ton grpx * 8, comptex * 24, &SCB[tlnb][ 0]
* Avoir des tableaux de taille en ^ 2.([comptex][comptey] a besoin d'etre calcule donc avec des tailles en ^2 les shifts sont utilisables)

Tu n'as que l'embarra du choix, pas necessairement utile de la passer en ASM maintenant.

Merci les gars pour tout ces conseils, j'ai retrouvé la fluidité le développement continu.

Folco (./27) :
• Folco donne une fournée de movea/adda/suba à GT Turbo, parce que c'est un chieur de puriste

Tu as bien raison, maiis mon assembleur le fait tout seul car j'ai cliqué les bonnes options d'assemblage

Prie pour que je tombe pas sur un de tes sources


GT Puriste

P.S. : rend service a la communauté change d'avatar Gros bisous a tous les assembleux

Cadeau : http://www.ticalc.org/archives/files/fileinfo/422/42265.html Tu peux forker pour dépurifier mon source

En fait, moi je pars du principe que l'assembleur est pas là pour comprendre ce que je baragouine : il est là pour créer un binaire correspondant à la perfection à mon source, sans le moindre soupçon de doute, sans avoir à deviner ou rectifier quoi que ce soit.
J'ai une sainte horreur des "optimisations" automatiques : move->moveq, movem->move, xan->an, alignement des dc/dcb/ds, inversion des opérandes de exg, etc...

Que mon code soit assemblé au micron près, ou qu'il ne le soit pas du tout. Mais on ne devine pas mon code, on ne le triture pas, on ne le modofie pas : on assemble.

Folco (./29) :
Que mon code soit assemblé au micron près, ou qu'il ne le soit pas du tout. Mais on ne devine pas mon code, on ne le triture pas, on ne le modifie pas : on assemble.

What else ? Je suis tout a fait d'accord, et je regarderais pas ton code, j'en ai assez en 'attente' Ca serait pas 'règlo' de regardé ton code alors que dans le mien il y a du nettoyage a faire

Mais CHANGE ton avatar car je te l'avais déjà dit un tel avatar peux t'arriver que des problêmes !!


GT Anti C