salut!!! - Page 1

Salut!!!
je voulais savoir si c'était possible d'optimiser cela.
je pense pas qu'on puisse beaucoup l'accelerer, mais bon, on sait jamais avec les dieux qui trainent

decall:
	lea	virt_screen1,a1 	    ;adresse plan0 de graphlib dans a1
	move.l	virt_screen_adress3,a0
	move.w	posymap,d4
	lsl.w	#6,d4		    ;multiplie le y par le nb de byte de la map pour ligne
	add.w	d4,a0		    ;on postionne le sprite map
	move.w	posxmap,d5		    ;on prend le x de la map
	divu.w	#8,d5		    ;on divise le x par 8
	add.w	d5,a0		    ;on ajoute le quotient à a1
	move.w	#0,d5		    ;on efface le mot faible de d5
	swap	d5		    ;on écange les 2 mots de d5
	move.w #8,d2		    ;on met 8 dans 2
	sub.w	d5,d2		    ;on fait 8-reste division
	lea	(a1),a6
	lea	(a0),a3
	move.w  #127,d7		    ;nb de ligne d'un écran de ti92+
retourdecall:
	move.w  #29,d0 		    ;met 30 dans d0 car 30 bytes dans l'écran
boucledecall:
	move.b	(a0)+,d1		    ;met un octet de a0 dans d1
	lsl.b	d5,d1
	move.b	#0,(a1)
	or.b	d1,(a1) 		    ;on ajoute à a1
	move.b	(a0),d1 		    ;on met 1 octet a0 dans d1
	lsr.b	d2,d1		    ;décallage vers la droite
	or.b	d1,(a1)+		    ;ajoute mem vid
	dbf	d0,boucledecall
	add.w	#30,a6		    ;ajout 30 bytes à pointage écran graphlib bien positionné
	lea	(a6),a1 		    ;on remet a1 à la nouvelle adresse
	add.w	#64,a3		    ;on ajoute la largeur du sprite de la map positionné au
	lea	(a3),a0 		    ;debut et on le met dans a3
	dbf	d7,retourdecall 	    ;et c'est reparti pour un tour ;)

[edit]Edité par gugusg le 18-11-2001 à 10:27:50[/edit]
[edit]Edité par gugusg le 19-11-2001 à 12:39:36[/edit]

y'a p'tet la division par 8, mais apres faudrait calculer le rest alors je sais pas si c'est rentable

bah... je v sans doute dire une connerie, mais bon...
pour ta division, tu peux pas t'en tirer ac un ror ?

t'as:

divu.w	#8,d5		    ;on divise le x par 8
add.w	d5,a0		    ;on ajoute le quotient à a0
move.w	#0,d5		    ;on efface le mot faible de d5
swap	d5		    ;on écange les 2 mots de d5
moveq.l	#8,d2		    ;on met 8 dans d2
sub.w	d5,d2

pkoi tu fé pas:

ror.l	#3,d5		    ;rotation de 3 bits vers la droite ->division par 8, reste*32 dans le second mot de d5
add.w	d5,a0
move.w	#0,d5		    ;efface le premier mot de d5 (peut-être pas nécessaire)
swap	d5		    ;échange les 2 mots
lsr.w	#5,d5		    ;divise reste*32 par 32 -> d5.w=reste
moveq.l	#8,d2		    ;on met 8 dans d2
sub.w	d5,d2

ça peut le faire ça, non?
bah, logiquement ça devrait marcher, nan?

merde, fo mettre un pre!
[edit]Edité par sBibi le 18-11-2001 à 22:23:49[/edit]

v regarder
est ce plus rapide ???
sinon, dans la boucle meme, celle qui prend le plus de temps, on peut pas optimiser ??

Je ne voudrais pas paraitre chiant, mais ce serait cool de garder un minimum une ecriture correct: par exemple: "v regarder", "pkoi tu fé pas", "fo mettre"... C'est bon pour ICQ et l'IRC ça...

Très cher,
mon humble personne est absolument d'accord avec vous. Toutefois, comme vous l'avez très certainement remarqué, je n'en doute pas, ce forum est quelque peu particulier, et s'apparente plus à un "chat à mémoire" qu'aux forums classiques tels que les étrangers à yakaclicker les connaissent.
C'est pourquoi, étant très souvent amenés à discuter en temps réel, nous ne pouvons nous pencher de façon profonde et détaillée sur l'orthographe et la grammaire de la langue de molière lors de l'écriture de nos messages.
La cause de tout ceci est la nature même du forum sur lequel vous venez de poster.
Donc, personnellement je ne pense pas que cette gêne soit très importante, du moment que cela reste correct et compréhensible.

Il est également nécessaire de prendre en compte la flemme innée de la grande majorité des utilisateurs de yaka, ainsi que la volonté de ne pas perdre de temps à écrire des lettres superflues.

sur ce, ça ma f grv chier d'écrr ce pt1 de pst a la cn, g prdu o - 2 min !!

lol, mais c vrai que zewwo a raison, ... dans un certain sens, de fait, c chiant de taper tous les mots ... on est deja obligé de faire ca en francais

zewoo > t'as parfaitement raison, mais je pense que n'ecrit comme un porc sur ce forum, et là j'était pressé et comme j'ai pris des abréviations que tous le monde a compris
Sbibi>
sinon, si on revenait à la cause première de ce topic

Parlant d'écriture correcte:
moveq.W N'existe PAS!!!

Je vais bien finir par supprimer le support pour les tailles incorrectes dans A68k, même si Pollux est contre. J'en ai marre de lire des horreurs comme ça.

La seule taille permise avec moveq est .L!

arf, j'avais pas fé gaffe, dsl, g juste fait un copier-coller de ce qu'il avait marqué

OK. C'est surtout gugusg (l'auteur original de ces horreurs) que j'ai critiqué.
[edit]Edité par Kevin Kofler le 18-11-2001 à 22:50:25[/edit]

Oui, y'a de la marge d'optimisation mais g pas le temps de le faire.

dsl kevin
j'ai pas remarqué
PpHd > sur quoi tes optimisation???

genlib:ptimisation_totale_de_tt_programme

sur tout, je pense
tout code est optimisable, sauf peut-être quand tu l'as réduit à une seule instruction

et encore, y'a des instructions que tu peux optimiser, je crois...
par ex, est-ce que ceci n'est pas de l'optimisation ?
move.l #2,-(a7)
=> moveq.l #2,-(a7)

(ou quelque chose comme ça )

vi

mais ça, je pense que le compilo le fait tt seul

bas du moins après "boucle decalle", je vois pas
mais je suis pas un dieux, moi !!!

ça viendra

Boh, on s'en fout du moveq.w car le compilo ignore le .w donc pas de probleme mais ce n'est pas bo, et comme d'hab, c du a une meconnaissance de l'asm
faut lire un peut plus les tuto asm,

ouais moveq tt court
encore la faute au zGuide?

ben ecoute comme moveq c'est toujours sur un mot long, pas besoin de mettre le .l
c'est pour ca que l'on peut juste mettre:
moveq
qui equivaut pour le compilateur a
moveq.l (et moveq.w ou moveq.b qui sont faux dans l'absolu...)

sBibi> normalement, la majorité des compilateurs ASM sont censés optimiser le move en moveq si possible.
Si je ne me trompe pas, d'après la doc de Jimmy Mardel, A68k devrait le faire.

ué, il le fait, g vérifié ac une doc que g retrouvée

OK.

'moveq.l #2,-(a7)' .
C'est INTERDIT, la seule syntaxe correcte est move.l #2,-(a7) car moveq ne s'applique que sans taille, et uniquement à des registres de données.

Y'a quand meme un codeur asembleur autre que moi, ca fait plaisir

arf...

decall:
lea virt_screen1,a1 ;adresse plan0 de graphlib dans a1
move.l virt_screen_adress3,a0
move.w posymap,d4
lsl.w #6,d4 ;multiplie le y par le nb de byte de la map pour ligne
add.w d4,a0 ;on postionne le sprite map
move.w posxmap,d5 ;on prend le x de la map
move.w d5,d2
lsr.w #3,d2 ;on divise le x par 8
add.w d2,a0 ;on ajoute le quotient à a1
moveq #7,d2 ;on met 8 dans 2
eor.w d2,d5
and.w d5,d2 ;on fait 8-reste division
addq.w #1,d2
lea (a1),a6
lea (a0),a3
moveq #127,d7 ;nb de ligne d'un écran de ti92+
retourdecall:
moveq #29,d0 ;met 30 dans d0 car 30 bytes dans l'écran
boucledecall:
move.b (a0)+,d1 ;met un octet de a0 dans d1
lsl.b d5,d1
move.b d1,(a1)
move.b (a0),d1 ;on met 1 octet a0 dans d1
lsr.b d2,d1 ;décallage vers la droite
or.b d1,(a1)+ ;ajoute mem vid
dbf d0,boucledecall
lea 30(a6),a6 ;ajout 30 bytes à pointage écran graphlib bien positionné
lea (a6),a1 ;on remet a1 à la nouvelle adresse
lea 64(a3),a3 ;on ajoute la largeur du sprite de la map positionné au
lea (a3),a0 ;debut et on le met dans a3
dbf d7,retourdecall ;et c'est reparti pour un tour

Bon g juste optimiser un poil, mais je sais pas a quoi ca sert...