Mini concours ASM 68k - Page 3

(ou simplement un "move.l a2,d1"... le code généré est quand même pas terrible, surtout pour un truc aussi courant qu'un test de nullité de pointeur)

Pollux :
(ou simplement un "move.l a2,d1"... le code généré est quand même pas terrible, surtout pour un truc aussi courant qu'un test de nullité de pointeur)

Hihi, bonne idée! Mais c'est pas aussi simple que ça, parce que (selon les termes du "concours") si tu ne sauves pas d1 sur la pile (et c'est coûteux!), tu n'est pas sensé le modifier.

SebRmv :
et encore, on dirait que tu n'as pas vu ce thread topics/88824-du-c-kinenveu

Sisi j'ai vu! Je viens d'essayer le prog d'exemple... fichtre ça torche!!! Ca donne sérieusement envie de se lâcher grave!!

stabylo
:

Pollux :
(ou simplement un "move.l a2,d1"... le code généré est quand même pas terrible, surtout pour un truc aussi courant qu'un test de nullité de pointeur)

Hihi, bonne idée! Mais c'est pas aussi simple que ça, parce que (selon les termes du "concours") si tu ne sauves pas d1 sur la pile (et c'est coûteux!), tu n'est pas sensé le modifier.

quels "termes du concours" ? (et puis a priori le gcc qui a compilé ça est configuré pour avoir le droit de détruire un certain nb de registres, genre d0-d1/a0-a1 ^^)

-

non, mais c'est clair, le code généré n'est probablement pas un code optimal
en fait, je voulais voir si un programmeur ici aurait l'idée spontanée d'utiliser pea
mais bon, comme dit Stabylo, je me suis un peu extasié pour pas grand chose
le plus important, c'est surtout que C et Jaguar ne font pas trop mauvais ménage

Orion_ :
c'est a demi hors sujet, mais j'ai réussi a faire une init de la jag (pal/ntsc) + gestion d'une oplist minimal pour afficher un ecran de 320x240 en 16bits (avec interuption vbl donc), et afficher un pixel sur cet ecran en 256 octets ^^

fais péter le code si tu veux pas être hors sujet

-

Pollux :
quels "termes du concours" ?

rien de méchant, seb n'a pas insisté sur ces détails. alors oui t'as raison, on peut faire comme on veut. De toute façon l'idée à trouver c'était la décrémentation "gratuite" (mais pas tant que ça) avec pea

(et puis a priori le gcc qui a compilé ça est configuré pour avoir le droit de détruire un certain nb de registres, genre d0-d1/a0-a1 ^^)

la config je sais pas, il faut demander à seb en tout cas le code produit fait bien gaffe de ne modifier que d0

Orion D_CTRL tu peux aussi le passer en relatif


GT

après tout, allons-y, comptons les cycles

_fact:
        movel a2,sp@-             ;  12
        movel sp@(8),a2          ;  16
        moveq #1,d0               ;    4
        cmpw #0,a2                 ;  10
        jeq L1                         ;  8 ou 10 (je compte un beq.s)
        pea a2@(-1)                ;  16
        jbsr _fact                     ;  18 (je compte un bsr.s)
        movel d0,sp@-            ;  12
        movel a2,sp@-            ;  12
        jbsr ___mulsi3             ;  20 (j'ai pris le pire jsr abs.l)  
        lea sp@(12),sp            ;  8
        .even
L1:
        movel sp@+,a2           ;  12
        rts                             ;  16

au total, (sans compter les cycles pris par mulsi3): 164 ou 80 (suivant que le saut est pris ou pas)

alors le pea en lui même est une bonne idée puisque la séquence

subq.l #1,d0
move.l d0,-(sp)

coute 8+12 = 20 au lieu de 16 cycles (et encore, ici c'est parce que c'est un petit immédiat)

par contre, le code suivant est probablement meilleur:

_fact:
       move.l 4(sp),d0      ; 16
       beq.s   L1               ; 8 ou 10
       move.l d0,-(sp)       ; 12
       subq.l #1,d0           ; 8
       move.l d0,-(sp)       ; 12
       bsr.s     _fact          ;  18
       addq.w  #4,sp         ; 8
       move.l d0,-(sp)       ; 12
       jsr       __mulsi3       ; 20
       addq.w #8,sp           ; 8
       rts                          ; 16
L1:
       moveq  #1,d0          ; 4
       rts                          ; 16

ça fait au total: 130 ou 46
(notez que j'utilise la commutativité de mul)

donc sans surprise, je suis meilleur qu'un compilateur! (et encore, je me suis permis le luxe de gaspiller 8 cycles: ça sert à rien de dépiler pour rempiler juste après)
par contre si on fait le ratio avec le temps pris pour coder, le compilateur me torche complètement

le convention d'appels de fonctions est bien celle dont Pollux parle

-

stabylo :
(Bon, mais en fait il aurait pu faire un "move.l a2,d0" pour faire le test, quitte à passer le "moveq" deux fois après le test, une fois dans chaque branche du code. Mais c'est un compilo, il faut être indulgent quoi. )

Il y a milles fois plus simple :

Au lieu de

          movel sp@(8),a2
          moveq #1,d0 
          cmpw #0,a2
          jeq L1 

faire un

          moveq #1,d0 
          movel sp@(8),a2  ; ici on ne touche pas a d0, donc on peu setter d0 avant de toucher a a2
          jeq L1 

suffit

humm j'ai du sauter 1 ou 2 pages

Godzil :

faire un

          moveq #1,d0 
          movel sp@(8),a2  ; ici on ne touche pas a d0, donc on peu setter d0 avant de toucher a a2
          jeq L1 

suffit

humm j'ai du sauter 1 ou 2 pages

euh, perdu
le "move.l 8(sp),a2" ne change pas les flags du CCR

ha ? ok lol

(bon en meme temps je ne connaissais pas cette forme de movel, c'est du 680x0 > 68000 non ?)

-

Orion_ :
aucun move ne change les flag je crois (pareil pour load sur le gpu/dsp)

je dirais au contraire, tous les move changent les flags
sauf ceux qui ont un registre d'adresse comme destination

(il y a peut être d'autres exceptions mais de tête je crois que c'est ça)

Godzil :
ha ? ok lol

(bon en meme temps je ne connaissais pas cette forme de movel, c'est du 680x0 > 68000 non ?)

y a pas de mal
non, movel, c'est de la syntaxe gnu
ça correspond à move.l en syntaxe habituelle des codeurs de 68000

-

Orion_ :

(et au passage le parseur il pootr quand même xD)

moi, je ne le trouve pas si bon que ça au contraire puisqu'il ne gère pas la priorité des opérateurs...

Orion> tu peux gagner au moins 50 octets :

;--------------------------
; Init

	lea	BASE,a6		; <- DO NOT ERASE !

	move.w	#$100,JOYSTICK
	clr.l	$2114(a6)		; G_CTRL
	clr.l	D_CTRL
	move.w	#%11010111001100,2(a6)	; MEMCON2
	move.w	#$2000,sr
	move.l	#INITSTACK,a7

	lea	palconst(pc),a0
	move.w	CONFIG,d0
	andi.w	#VIDTYPE,d0	; 0 = PAL 50Hz, 1 = NTSC 60Hz
	beq.s	palvals
	addq.w	#8,a0
palvals:
	move.l	#((ListAdrs&$FFFF)<<16)|(ListAdrs>>16),$20(a6)	; OLP (swap manuel)
	move.w	#RGB16|CSYNC|BGEN|PWIDTH4|VIDEN,$28(a6)		; VMODE
	clr.l	$2A(a6)		; BORD1
	move.w	(a0),$38(a6)		; HDB1
	move.l	(a0)+,$3A(a6)		; HDB2+HDE
	move.w	(a0)+,$46(a6)		; VDB
	move.w	#$FFFF,$48(a6)		; VDE
	move.w	(a0)+,$4E(a6)		; VI
	clr.w	$58(a6)		; BG

	lea	OPList(pc),a0
	movem.l	(a0)+,d1-d6
	movem.l	d1-d6,ListAdrs

	move.l	a0,LEVEL0
	move.w	#C_VIDENA,$E0(a6)	; INT1

elop:	stop	#$2000
	bra.s	elop

;--------------------------

	.phrase
OPList:		; precalculé (et au passage le parseur il pootr quand même xD)
	dc.l	((Data>>3)<<11)|((ListAdrs+16)>>(3+8)),(((ListAdrs+16)>>3)<<24)|(Hauteur<<14)|(Y<<(1+3))	; Bitmap Object (sprite ecran)
	dc.l	$8000|(Largeur>>(2+4)),((Largeur>>2)<<28)|((Largeur>>2)<<18)|$C000|X
	dc.l	0,4	; Stop Object

;--------------------------

VBLRoutine:
	movem.l	d1-d6,ListAdrs

	move.w	#$3F,Data+320*20+40	; et un pixel ! un !

	move.l	#$01010000,$E0(a6)	; INT1/2
	rte

;--------------------------

palconst:
	dc.w	4+PAL_HMID-PAL_WIDTH/2,$400|(PAL_WIDTH/2-1)
	dc.w	PAL_VMID-PAL_HEIGHT
	dc.w	1|(PAL_VMID+PAL_HEIGHT)
ntscconst:
	dc.w	4+NTSC_HMID-NTSC_WIDTH/2,$400|(NTSC_WIDTH/2-1)
	dc.w	NTSC_VMID-NTSC_HEIGHT
	dc.w	1|(NTSC_VMID+NTSC_HEIGHT)

;--------------------------

(on peut sûrement faire nettement mieux, mais j'ai pas jaguar.inc donc par exemple je peux pas toucher au code qui utilise VIDTYPE alors que c'est forcément optimisable)

-

oué je me demandais si l'ordre était sensible ou pas, mais enfin bon a priori tu peux remettre tout ça dans l'ordre original sans perdre grand-chose ^^

Orion_ :
(qui est très delicate donc je voulais eviter de trop toucher a ça pour pas cramer ma télé )

Je pense que pour "bruler" ta tv il faudra plus qu'un pauvre petite console ^^

-

Orion_ :
(j'ai la phobie des ecran cathodique)

mon petit doigt me dit que ça concerne pas que les écrans cathodiques #open#

-

Orion_ :
si tu met n'importe quoi dans les registres tu peu claquer un moniteur je pense :/
maintenant le terme cramer c'etait une expression (j'ai la phobie des ecran cathodique)

Oula je t'assure que pour "claquer" un tube cathodique (comprendre imploser ou ne serait-ce que le casser le tube) c'est pas électriquement que tu y arriveras

Et meme abimer le cannon, enfin bref, tu as peu (aucune ?) chance de bruler ta tv© juste en faisant mumuse avec les registre de ta jaguar ^^ tout ce que tu risque c'est de n'avoir un affichage tres bizzare

Détrompe-toi Godzil, tu peux par exemple cramer le HOT (Horizontal Output Transistor) avec des signaux de synchro biscornus... les moniteurs actuels sont assez bien protégés, mais sur un vieux moniteur à fréquences fixes par exemple, ça pardonnait pas.

T'inquiete, j'ai deja envoyé des trucs plsu que bizzare a des moniteurs plus ou moins recent/vieux aucun n'a jamais cramé, autrement que par vieillesse, donc bon, tue un CRT il faut vraiment en vouloir avec un signal video

Et meme si l'electronique peut etre fragile dans certain cas, si tu vois que tu balance un signal completement délirant, tu laisse pas 15ans... Le temps de faire surchauffer un T assez pour le griller (si encore celui que tu as est pas assez costaud pour) c'est que tu l'a laissé trainer un moment...

Godzil (./74) :
(bon en meme temps je ne connaissais pas cette forme de movel, c'est du 680x0 > 68000 non ?)

A proprement parler, il s'agit d'un "movea.l". Je crois que Motorola et les orthodoxes du 68k utilisent cet opcode spécifique pour marquer le différence de comportement vis-à-vis du CCR.

Il y a d'autres opcodes de type "move" qui ne modifient pas le CCR (movem, movep, movec, par exemple) à chaque fois, on rajoute une lettre à la fin pour marquer la différence.