Re: Papi Commando fait de ... L'assembleur 68000 !

par tfdi Dim 19 Juin 2016 - 12:09

Vetea:

Moveq #0,d0 ->4 Cycles
clr.l d0 -> 8 Cycles
move.l #0,d0 -> 12 Cycles

Un moveQ #0 est bien plus rapide qu'un clr.l ... Wink

....

Un petite explication concernant moveQ, la valeur que tu affectes au registre de donnée de destination est sur 8 bits, mais elle est étendue sur 32 bits lors du transfert.

En clair, parce que ce sont ces petites différences qui changent le monde en assembleur :

Code:: move.l #$12345678,d0 ; d0=12345678 move.b #$FF,d0 ; d0=123456FF move.w #$FF,d0 ; d0=123400FF move.l #$FF,d0 ; d0=000000FF moveq #$FF,d0 ; ATTENTION d0=FFFFFFFF moveq #$7F,d0 ; AUTRE PIEGE d0=0000007F

Comme tu peux le voir, il y a des grosses différences en fonction du fait que tu utilises en destination .b, .w, .l ou moveq. Ce sont ces petites "astuces" qui sont longues à maitriser .. Wink

Mais en persévérant, on y arrive toujours, et je sais que tu y arriveras Wink

par Spirale Dim 19 Juin 2016 - 12:09

Excellent Vétéa, je suivrais ton post avec grande attention.

Pour l'instant, j'ai pas du tout le temps avec notre projet à terminer avant juillet.

Mais vivement la suite de ton aventure dans les entrailles de la bête.

Bonne continuation.

par Invité Dim 19 Juin 2016 - 13:17

Merci a vous ! amoureux

@Tfdi : je ne connais pas encore ces histoires de cycles/Opcodes ... Mais c'est vrai qu'il est important d'optimiser.
Par contre avec Moveq sur tes 2 derniers exemples, moi pas comprendre ...
Moveq #$ff,d0 : FF sur 32 bits
Moveq #$7f,d0 : 7f sur les 2 derniers bits et pas sur les 32 ??
J'ai pas mal pratiqué ces histoires de Move auparavant avec Bex ... En travaillant avec des manipulations de variables. Ça rentre petit a petit.

par Invité Dim 19 Juin 2016 - 13:33

je ne connais pas encore ces histoires de cycles/Opcodes

c'est justement ce qui va facilement te permettre de savoir si une routine est plus rapide qu'une autre,et la connaissance des opcodes et de leurs cycles va te permettre (avec l'expérience) d'optimiser au mieux on the fly, pendant que tu codes, ce qui n'est pas possible avec un langage de haut niveau .

Tfdi te donne juste un petit exemple de pk utiliser un opcode plutôt qu'un autre pour faire la même chose .
et franchement n'hésites pas à demander des conseils, astuces à ceux ici qui connaissent bien le 68K, tu verras que ça vient très vite .

par Invité Dim 19 Juin 2016 - 19:08

Bonjour à tous,

J'ai réussi à faire un petit effet de Raster :
Papi Commando fait de ... L'assembleur 68000 ! - Page 2 Scr22

... En modifiant très légèrement mon code et ma boucle principale :

Code:: ;Notre boucle principale Main1: move.w #$870C,VDPControlPort ;12 éme couleur de la palette 0 nop move.w #$8702,VDPControlPort ;2 ème couleur nop move.w #$8703,VDPControlPort ;3 ème couleur nop bra Main1

Avec les NOP ( No Operand ), on peut varier l'effet ... Bref, rien de bien folichon. Wink

J'arrive à afficher un "HELLO WORLD" mais pas comme je le voudrais ..

Ce que je veux faire, c'est de charger l'intégralité de mes caractères en VRAM.
Et ensuite, trouver le moyen de créer une routine pour faire correspondre le bon caractère avec la bonne adresse VRAM.
En basic, je sais faire .. Mais en ASM, c'est pas gagné ! Very Happy

Autre question : A quoi sert l'OP : SWAP xx ?
Merci ! :)

par grostonton Dim 19 Juin 2016 - 20:51

Très intéressant de suivre papy dans toutes ses aventure, et l'image du premier post où l'on voit papy en mode programmation, j'adore !!!

par Invité Lun 20 Juin 2016 - 17:16

Merci grostonton !! :)
Oui c'est une belle aventure pour Papi ... C'est assez chaud pour aborder un projet car c'est pas la même méthode, mais j'essais de ne pas baser tout sur la compréhension sinon j'en finirai jamais. Je vais marier les méthodes connues et génériques avec le corps d'un jeu et ses algos.
J'espère proposer un autre projet avec la gestion du texte ... Gestion qui sera utilisable pour les futurs autres. :)
Merci à Bex et sa librairie qui vaut tous les tutos mal foutus du net.

par grostonton Lun 20 Juin 2016 - 21:42

Ben écoutes (ou lis c'est comme tu veux ;-) ), depuis que je suis ton parcours sur gamopat, je t'ai toujours vu "dompter" les différentes machines/techniques auxquelles tu t'essayais, donc je ne me fais pas trop de soucis ;-) et je suis ça avec intérêt

par Invité Lun 20 Juin 2016 - 21:49

Merci copain, on va essayer !!
Petit apparté :
Basic : Print "hello !" ( 1 ligne )
Assembleur : pas fini ... Mais j'en suis a plus de 200 lignes !! °_°
Hihi !!

par Invité Mar 21 Juin 2016 - 0:17

Bonsoir à tous,

J'aurai besoin d'un éclairage sur ces quelques lignes de codes ASM .... Du moins, savoir si j'ai bien compris dans le principe ...

Code:: move.l #60, d0 move.w d0, -(a7) move.l #33, d0 lsl.w #5, d0 clr.l d1 move.w d0, d1 clr.l d0 move.w (a7)+, d0

move.l #60, d0 --> On charge 60 en décimale dans d0 : 00000060
move.w d0, -(a7) --> On stocke le contenu de d0 dans la pile a7
move.l #33, d0 --> On charge 30 en décimale dans d0 : 00000033
lsl.w #5, d0 --> On multiplie par 2^5 le contenu de d0 soit : 33*32 = 00001056
clr.l d1 --> Raz de d1 ( que l'on peut remplacer par MoveQ #0,d1 )
move.w d0, d1 --> d1=D0 soit d1=00001056 et d0=00001056
clr.l d0 --> Raz de d0 ( ou MoveQ #0,d0 )
move.w (a7)+, d0 --> On récupère le contenu de notre pile a7 et on le stocke dans d0.

Donc au final : d0=00000060 & d1=00001056

J'ai bon ?? Wink

Autre question j'ai donc appris que l'OPCODE SWAP va intervertir les deux Words d'un registre de donnée.
Par contre, si notre registre de donnée est de type décimal, est ce que SWAP va travailler en décimal ou en hexadécimal :
move.l #1234,d0
swap d0
00001234 - SWAP -> 12340000 ? ( Nombre déclaré en décimal )

J'ai bon ?

Merci !!! Very Happy

( Hors propos, j'ai trouvé un super site expliquant vraiment clairement les nombreux OPcode du 68000 avec exemples & Exercices .. Vraiment génial : http://mrjester.hapisan.com/04_MC68/Index.html )

par dub Mar 21 Juin 2016 - 9:46

Faut vérifier par les pros de l'asm ...

Mais normalement quand tu charges en decimal, il y a conversion en hexa :
move.l #60, d0
d0 = 0000003C

move.l #$60, d0
d0 = 00000060

Et si tu passes qu'un byte, move.b suffit

par tfdi Mar 21 Juin 2016 - 11:28

Vetea a écrit:Merci a vous !
@Tfdi : je ne connais pas encore ces histoires de cycles/Opcodes ... Mais c'est vrai qu'il est important d'optimiser.
Par contre avec Moveq sur tes 2 derniers exemples, moi pas comprendre ...
Moveq #$ff,d0 : FF sur 32 bits
Moveq #$7f,d0 : 7f sur les 2 derniers bits et pas sur les 32 ??

C'est pour ça que je t'ai donné cet exemple Wink

... c'est important de bien comprendre ce qu'il se passe en "vrai". Ne néglige pas le SR (statut register), les débutants en asm ont tendance à "zapper" ce registre parce qu'ils ne comprennent pas son utilité.

moveq #$ff,d0 ; ca te met -1 dans d0, les valeurs sont signées ! ... et -1 étendu sur 32 bits, ca fait bien $FFFFFFFF. Ici le SR a le flag N positionné à 1

moveq #$7f,d0 ; ca te met +127 dans d0, étendu sur 32 bits ca fait bien $0000007F. Ici le SR a le flag N positionné a 0.

Les tests sous un debuggueur sont très important quand tu démarres, il faut bien regarder ce qu'il se passe au niveau des registres, les "détails" aussi sont importants, tel que bien comprendre l'utilité du SR, et le format des valeurs passées (ici, les valeurs signées).

Concernant ton exemple:

Code:: move.l #60, d0 move.w d0, -(a7) move.l #33, d0 lsl.w #5, d0 clr.l d1 move.w d0, d1 clr.l d0 move.w (a7)+, d0

Je te déconseille d'utiliser la pile pour stocker des valeurs, du moins tant que tu ne maitrises pas bien l'assembleur.

Pourquoi ? Parce qu'à un moment, tu vas commencer à toucher les interruptions, et que si tu as plusieurs routines en // qui stockent des infos dans la pile, forcément à un moment quand tu vas restaurer un registre à partir de la valeur contenu dans la pile, tu ne remettras pas la bonne valeur, et ca va coincer via un bon gros "bus error".

Tu vas te retrouver avec un bon gros bug à corriger incluant des routines en interruptions, tu vas connaitre la signification du mot "enfer" .... MDR

Tu définis une variable style:

backup dc.w 0

Et tu fais ton

move d0,backup

Comme ca t'es tranquille .. Wink

Je confirme bien sûr ce que disais dub, quand tu stockes une valeur, elle est automatiquement convertie en hexadecimal, tu verras donc toujours une valeur hexadecimale dans tes registres et variables sous un debuggueur.

Et enfin, quelques commentaires sur ton exemple pour l'optimisation, c'est une habitude à prendre Wink

Code:: move.l #60, d0 move.w d0, -(a7) move.l #33, d0 lsl.w #5, d0 clr.l d1 move.w d0, d1 clr.l d0 move.w (a7)+, d0

Ton move.l #33,d0 prends 12 cycles, un move.b #33,d0 prend 8 cycles. Ici t'as pas besoin d'utiliser un move.l, vu que t'en as fait un 2 ligne au dessus.

Ton raisonnement quand au résultat final est juste .. thumleft

... j'aurai juste modifie ton prog comme ça:

Code:: move.l #60, d0 move.w d0,backup move.b #33, d0 lsl.w #5, d0 moveq #0,d1 move.w d0, d1 moveq #0,d0 move.w backup,d0

Là t'es à 80 cycles pour cette routine, au lieu de 76 cycles pour la tienne, mais celle là est "safe", t'auras pas de bug lié à l'utilisation de la pile si t'utilises des routines en interruptions qui touchent à la pile en même temps.

Sinon en gardant l'enregistrement de d0 dans la pile, et en modifiant par les moveq et le move.b, on est à 64 cycles soit mine de rien, 18,75% plus rapide .. XD

C'est bien d'utiliser un lsl pour faire un mulu quand tu peux, c'est déjà un bon réflexe Wink

par Invité Mar 21 Juin 2016 - 11:52

Merci beaucoup Tfdi, t'es un amour. amoureux

En effet, ces histoires de SR ( CCR aussi ?! ) est assez alambiqué ...
J'ai compris "en gros" mais bon .. J'y reviendrai le temps que ma cervelle intègre cette nouvelle gymnastique d'esprit.
Et tu m'a donné le chemin pour déclarer une variable en plus ...
Dans ma tête vu que la RAM commence à $FF00 ben j'avais l'idée de faire :
Mavriable: Equ#FF00
Mavar2: Equ#FF02
Etc ...
Bref, comme tu dis faut que je teste avec le debugger de Gens en mode 68k, chose que je fais systématiquement pour voir l'État de tous mes registres.

Ça rentre doucement ... Wink

Merci encore.

par tfdi Mar 21 Juin 2016 - 12:10

Pour déclarer des variables et des buffers :

Variable:
var1 dc.l 0 ; reserve un .l avec la valeur 0 initialement
var1 dc.w 20 ; reserve un .w avec la valeur 20

Buffers:
buf1 ds.l 200 ; reserve 200 .l, donc 800 octets en mémoire avec la valeur 0

Ne jamais utiliser la Ram en direct ... sauf quand t'as le grade d'Empereur Sith du dark side of the spoon .. XD

En clair, faut attendre de VRAIMENT bien savoir ce qu'on fait ... Wink

par Invité Mar 21 Juin 2016 - 12:27

Oui Maître. batman

par Invité Mar 21 Juin 2016 - 15:58

Conseil : ne pas faire d'assembleur avant d'aller au dodo ... °_°

par Invité Mar 21 Juin 2016 - 17:24

Bon, je suis au boulot, mais j'ai le cerveau en double file et j'aurai une question.
Quel est l'intérêt de l'Opcode ROL et ROR par rapport a LSL et LSR sachant que ces derniers sont très utiles pour des opérations de * ou / à 2^n .
Merci. Wink

par Invité Mar 21 Juin 2016 - 17:56

Vetea a écrit:Conseil : ne pas faire d'assembleur avant d'aller au dodo ... °_°

Non, sinon ton cerveau continu à compiler la nuit Confused

Quel est l'intérêt de l'Opcode ROL et ROR par rapport a LSL et LSR sachant que ces derniers sont très utiles pour des opérations de * ou / à 2^n .

Il est de garder tout les bits, contrairement aux shift.
ROL/ROR font une rotation des bits, donc arrivé à la fin de ta variable, les bit reviennent au début ou à la fin(selon la direction),avec le shift, les bits de début/fin sont perdus .

ROL de %10000000 (nombre binaire sur 8 bit) = %00000001
LSL de %10000000 (nombre binaire sur 8 bit) = %00000000

je schématise mais le principe c'est ça .

par Invité Mar 21 Juin 2016 - 18:02

Merci Touko.
Donc sur un word en faisant un ROL.w sur 8 bits, on fait une sorte de swap.
Même chose en Long ( a part que la Swap suffit ), bref je me comprends ... Je vois.
Putain avec l'ASM t'oublies presque a coder un jeu ... °_°

par Invité Mar 21 Juin 2016 - 18:08

Vetea a écrit:Merci Touko.
Donc sur un word en faisant un ROL.w sur 8 bits, on fait une sorte de swap.
Même chose en Long ( a part que la Swap suffit ), bref je me comprends ... Je vois.
Putain avec l'ASM t'oublies presque a coder un jeu ... °_°

Alors je sais pas exactement comment fonctionne le 68k, mais un ROL.w est sur 16 bit .
donc sir tu as:
ROL.w %00000000 11111111 = il me semble %00000001 11111110
après je crois que tu peux faire des shift/rotation de plusieurs bits avec 1 seule instruction .

par Invité Mar 21 Juin 2016 - 19:54

Ouiii pardon me suis gourré !!
C'est ROL.l que je voulais dire ...
Bref, j'espère fournir un nouveau projet avec écriture de Tile a l'écran au coordonnées X,Y par le biais des textes.
En quelques jours j'ai intégré pas mal de nouveaux concepts, plus qu'auparavant avec Bex.
C'est très particulier ... Ça me fait bizarre de bosser en Hex/Binaire et moins en DEC. En plus il y a des variables signed et unsigned couplé avec un CRR ... Ahah ...
Complètement diffèrent oui ... C'est dingue quand tu viens du 300% Basic comme moi.
Meme si j'arriverai pas a sortir un vrai jeu, ca sera une belle experience. :)

par Invité Mar 21 Juin 2016 - 20:06

Meme si j'arriverai pas a sortir un vrai jeu, ca sera une belle experience. :)

C'est ce qu'on se dit tous au début, tu verras si tu continues ta persévérance,l'asm deviendra très naturel, et surtout quand tu verras le gain de perfs .

par **Urbinou** Mar 21 Juin 2016 - 20:11

TOUKO a écrit:ROL/ROR font une rotation des bits, donc arrivé à la fin de ta variable, les bit reviennent au début ou à la fin(selon la direction)

Pour ma culture générale, le 68K rolle directement sans passer par un Carry ou équivalent ? C'est pourtant bien utile quand on veut injecter le bit qui tombe dans un autre octet Very Happy

par Invité Mar 21 Juin 2016 - 20:24

Oui il va dans la carry avant Wink

par **Urbinou** Mar 21 Juin 2016 - 20:31

Ca me semble important de le préciser ! Parce que c'est le carry précédent qui entre, tu ne peux donc cycler le même octet (ou mot) par une simple instruction.

par Invité Mar 21 Juin 2016 - 20:58

Tu as raison,mais je voulais essayer de lui expliquer la difference simplement, mais c est peut être un tord de ne pas expliquer tout le processus Confused

par **65c02** Mar 21 Juin 2016 - 21:25

Vetea, je t'adore !
Sérieux, ça fait plaisir de te voir progresser comme ça.
Tu level up comme un chef thumleft

par **Urbinou** Mar 21 Juin 2016 - 21:31

TOUKO a écrit:Tu as raison,mais je voulais essayer de lui expliquer la difference simplement, mais c est peut être un tord de ne pas expliquer tout le processus

ce n'était pas une critique Wink

Je comprends ta démarche, mais ça m'a induit en erreur, alors un débutant

par Invité Mar 21 Juin 2016 - 21:56

Merci a vous et a toi 65c02 ! amoureux

Lors de notre après midi ensemble, tu m'en avais parlé ... Il me manquait juste le petit truc pour commencer, et c'est fait !!
Pour ROR et ROL oui y a une retenue CR, j'avais vu. Je ne comprends pas encore a quoi ça me servira ... Mais j'ai des petites idées. Wink

par Invité Mar 21 Juin 2016 - 23:14

Mise a part le debugger de l'émulateur Gens, peu pratique pour regarder l'État des registres, auriez vous un autre émulateur type 68000 "scolaire" avec une visualisation directe de tous les registres et éventuellement, un compilateur intégré .. ?
Merci.
( Pas de code ce soir ... °_° )

EDIT :
C'est bon !!! J'ai trouvé mon bonheur :
http://www.easy68k.com/
Parfait pour se faire la main. :)

Papi Commando fait de ... L'assembleur 68000 ! - Page 2 Ex1m

Papi Commando fait de ... L'assembleur 68000 ! - Page 2 Ex1m

Je confirme, c'est trop de la balle !! Parfait pour bien comprendre ce qui se passe ... Avec un mode Step/Step vraiment utile !
Yaouhhhhh c'est génial ! Very Happy

Bon, je coupe lde PC ... °_°

par **F.L** Mer 22 Juin 2016 - 9:27

Et moi qui trouvait bex compliqué comme langage..... MDR

L'assembleur ça a l'air bien maso !
Ça me fait penser a l'expression "pourquoi faire simple quand on peut faire compliqué"
Bon courage pour ce nouveau défi , meme si à part le coté challenge perso, je n'en saisi trop la finalité... tongue