Logicielsmoto.com

Nous sommes le 28 Mar 2024, 20:35

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 276 messages ]  Aller à la page Précédente  1 ... 9, 10, 11, 12, 13, 14, 15 ... 19  Suivante
Auteur Message
MessagePosté: 15 Avr 2021, 18:32 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Citation:
Ce sait ce que je dis


Apparemment non! :roll:

Et oui je connais DAA. On s'en sert pour la conversion décimal/hexadécimal...

Et surtout, arrêtes cette agressivité, j'ai dit donc c'est, qui n'est pas plus constructive


Dernière édition par jasz le 15 Avr 2021, 18:46, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Avr 2021, 18:43 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Si tu veux gagner du temps et de l'espace il vaut mieux éviter le CMP pour afficher le score. Il faut factoriser.
Tes gfx pour les chiffres font 16 octets.
A l'extraction du chiffre tu l'additionnes à lui même
Code:
ADDA ,A; x2
ADDA ,A; x4
ADDA ,A; x8
ADDA ,A; x16

LDX   .gfxChiffres
LEA   A,X

Cette solution est plus "rapide" que les LSLA et est très utilisée en 68000


1/ Ceci n'est pas possible en 6809 (On ne peut pas ajouter A à A, seulement via des registres X, Y, U ou S)
2/ Si cela était possible, c'est moins rapide que le LSLA à droite (qui ne prend que 2 cycles par utilisation)
3/ Ca ne marche que dans le sens droite vers gauche, or ce que j'ai proposé est de Masquer le quartet de garder, pour garder le chiffre de droite puis de masquer le quartet de droite et effectuer 4 LSR à droite (ces 4 décalages ne prennent que 8 cycles)

Et l'utilisation de DAA permet d'avoir directement des chiffres en système décimal. C'est direct.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Avr 2021, 18:52 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Citation:
Ce sait ce que je dis


Apparemment non! :roll:

Et oui je connais DAA. On s'en sert pour la conversion décimal/hexadécimal...

Et surtout, arrêtes cette agressivité, j'ai dit donc c'est, qui n'est pas plus constructive


C'est pas la première fois que tu écrit des choses qui sont fausses dans ce forum, tu es souvent repris et là je le fais également parce que ta méthode ne peux pas être appliquée sur le 6809 et en plus de dire que ta méthode est plus rapide que les LSL et LSR c'est FAUX (et elle n'est applicable que pour un décalage à gauche en plus, hors ici, c'est pas ce qu'on souhaite mais plutôt un décalage à droite.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Avr 2021, 20:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Code:
ADDA ,A; x2
ADDA ,A; x4
ADDA ,A; x8
ADDA ,A; x16
Ca n'existe pas sur 6809.
Code:
LEA   A,X
Ca n'existe pas plus, mais j'imagine que c'est une typo et tu veux parler de LEAX A,X.

Allez je vais mettre d'accord tout le monde: le code le plus rapide est celui qu'on execute pas (inutilement). Alors la solution n'est pas d'afficher le score à chaque frame, mais uniquement quand il vient d'être changé ce qui est "rare" dans la logique du jeu. Le gain sera déjà substantiel et indépendant de la techno pour calculer les chiffres car cela se produira très rarement.

Ensuite, les conversions BSD tout ca c'est bien mais ca coute des cycles quand même. Ce que font les jeux pour aller vite c'est d'avoir le score avec 1 octet par chiffre. L'addition chiffre à chiffre avec propagation de retenue est trivial, rapide et se combine facilement avec la mise à jour du chiffre à l'écran si nécessaire. Exemple
Code:
NUM_CHIFFRES EQU 6
score:
  RMB  NUM_CHIFFRES,0
increment_1500:
  FCB  0,0,1,5,0,0
..

  LDX #increment_1500
  BSR incremente_score
..
incremente_score:
   LDB  #NUM_CHIFFRES-1
   LEAU #score
   CLRA   ; retenue initiale
boucle:
   ADDA B,X
   BEQ  chiffre_suivant; on ajoute 0, on passe au chiffre suivant sans rien faite (fast!)
   ADDA B,U   ; ajout chiffre score
   CMPA #10   ; débordement ?
   BGE  retenue  ; oui => retenue
   BSR  mise_a_jour_chiffre
chiffre_suivant:
   DECB
   BNE  boucle
   RTS
retenue: ; un peu plus long (et encore), mais la retenue est un phénomène rare
   SUBA #10
   BSR  mise_a_jour_chiffre
   INCA ; retenue
   BRA chiffre_suivant
mise_a_jour_chiffre:
   STA  B,U ; écrit le nouveau chiffre dans score
   BSR  mise_a_jour_chiffre_ecran  ; affiche le chiffre "A" à l'offset "B" du score sur l'écran
   CLRA ; pas de retenue (cas le plus fréquent)
   RTS

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Avr 2021, 12:47 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Le pense que les 2 méthodes (la tienne et celle par DAA) sont à peu près équivalente en terme de cycle d'horloge, et effectivement on est d'accord sur le fait que c'est à tout changement de score qu'on affiche le score (je pensais que c'était le cas pour le Pac-Man). C'est pas le calcul du score lui même qui bouffe tant de cycles. DAA ne fait qu'un calcul pour 2 chiffres décimaux, on ne fait pas de comparaison avec 9, A contrario, ça suppose d'appliquer un AND 15 pour le premier chiffre (quartet faible) et 4 décalages (8 ccles d'horloge) à droite pour le 2ème (quartet fort), alors que le calcul est déjà fait, .

Ce qui bouffe du temps est bien l'affichage des "sprites" pour les scores! C'est pourquoi il faut éviter que ces sprites soient trop gros (6 chiffres à 16x32 ça serait trop AMHA, du 4X8 pxl comme faisait l'Amstrad ça devrait suffire, peut-être du 8x16 ?)

Combien de pxl font tes sprites score ADNZ ?

Autre chose, pour l'affichage su high score, il suffit de faire une copie écran de la zone de score, si celui ci a le statut "high" d'une zone écran vers une autre.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 17 Avr 2021, 22:50 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Quelques petits update pour savoir où on en est :W

- update hi-score (l'update se fait après le gameover au début de chaque nouveau jeu )
- affichage du level (pour savoir combien de fois on à fait le tableau)
pour infos à chaque level (pour le moment jusqu'au level 3, le temps des superpacgum est réduit)
- j'ai ajuster l'inter-chiffre les digits
- l'espace sous les scores va servir à afficher les fruits mangés (j'afficherais à 60% de la tailles des sprites pour en afficher un maximum)

Même moi je galère, c'est trop dur lol, mais je ferais des réglages de tout ça :)

Fichier(s) joint(s):
pacman-test-game-20210417.png
pacman-test-game-20210417.png [ 25.7 Kio | Vu 6699 fois ]

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Avr 2021, 17:54 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Samuel Devulder a écrit:
Code:
ADDA ,A; x2
...
Ca n'existe pas sur 6809.

Oui, je le sais maintenant car je me suis inspiré du code 68000 ADD.B D0,D0 qui est deux fois plus rapide qu'un LSL #4,D0. De même pour le LEA A,X pour LEA 0(A0, D0.W),A0. D0 etant A et A0, X. C'est la même erreur que pour INC qui à mon sens influençait le carry pris pour un ADDQ #1,D0. :tourne:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Avr 2021, 12:13 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Samuel Devulder a écrit:
Code:
ADDA ,A; x2
...
Ca n'existe pas sur 6809.

Oui, je le sais maintenant car je me suis inspiré du code 68000 ADD.B D0,D0 qui est deux fois plus rapide qu'un LSL #4,D0. De même pour le LEA A,X pour LEA 0(A0, D0.W),A0. D0 etant A et A0, X. C'est la même erreur que pour INC qui à mon sens influençait le carry pris pour un ADDQ #1,D0. :tourne:


Tu te trompes!

Pour obtenir l'équivalent de LSL #4 DO (4 fois décalage à gauche), il faut faire 4 fois ADD B, DO,DO, et d'après cette source https://wiki.neogeodev.org/index.php?title=68k_instructions_timings#Standard_instructions, Un ADD c'est AU MOINS 6 (en moyenne 8 + les cycles pour le calcul de l'adresse effective donc on peut dire 10 cycles en moyenne) par ADD, donc ça fait 40 cycle pour faire l'équivalent du LSL #4 DO
LSL #4, DO prend 8+2n (n étant le nombre de décalages), soit ici 16 cycles seulement contre 40 pour ta méthode que tu dis "plus rapide" (en plus il faut répéter 4 fois le ADD, et ça nécessite une boucle...)

Le LSL LSR est la méthode la plus rapide pour les x2 ou /2

Je constate aussi sur ce site que les opérations de multiplication (70 cycles) et division (140 cycles) sur 16 bits, les instruction sur 68k sont moins efficaces que les même opération sur l'Hitachi 6309 (sur 2x16 bits, qui prend, un peu plus de 40 cycles). Sur le 6309 le MUL se fait sur 2 registres interne pas en mode d'adressage, ceci explique peut-être cela. Je trouve étrange que le DIV prenne 2 fis plus de temps alors que l'algorithme assembleur pour effectuer une multiplication oiu une division sur 8 vers 16 ou 16 vers 8 bits est quasiment le même


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Avr 2021, 18:03 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Bon, j'abandonne!

Tu expliqueras ta théorie aux codeurs sur Amiga, je pense notamment à insane, scoopex et d'autres sur ST dont je me suis largement inspiré pour faire mes codes à l'époque... :roll:


Dernière édition par jasz le 21 Avr 2021, 03:48, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Avr 2021, 18:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Attention aux multiplications sur 68000, ce sont du 16x16 -> 32. C'est forcément plus long que du 8x8 -> 16 bits, et pas qu'un peu: il y a 2x plus de bits à traiter et comme l'algorithme utilisé est quadratique ca prends 4x plus de temps à la base. Si tu ajoute que l'addition 32 bits est plus lente sur 68000 que le 16bits tu réalises qu'une mul 16x16 est une grosse opération.

Pour la multiplication signée, il y a des algorithmes hardware bigrement efficaces (multiplication de Booth) mais avec un temps variable en fonction du motif de 1/0 dans les nombres. Les 70 cycles du 68000 sont une valeur max dans le pire des cas. La multiplication est micro-codée sur le 68000 avec des étapes indépendantes, mais faute de portes logiques suffisantes elles sont faites en séquences. Sur 68010 il y a ces resources en plus et des trucs se font en parallèle descendant la multiplication à 40 cycles. (source).

Par contre diviser n'a pas vraiment d'algo parallèle est toujours super super lent à produire les bits un à un ou 2 par 2 (ce qui n'est qu'à peine mieux vu la complexité logique impliquée).

On peut retrouver une re-implémentation "cycle-exact" du mc6809 en verilog (ici) et voir que la multiplication est assez simple. Il y a le fetch (1 cycle) comme sur toutes les instructions + le décode/init (1 cycle) + une boucle de 8 itérations (8 cycles) qui fait du shift + add consommant un bit à la fois d'un des nombres + une étape finale pour écrire le résultat dans D et mettre à jour le registre de contrôle. Total 1+1+8+1=11 cycles. Ca colle assez bien.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Avr 2021, 23:14 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Citation:
On peut retrouver une re-implémentation "cycle-exact" du mc6809 en verilog (ici)

Le gars est bon ... il a même pensé à masquer la non-masquable interrupt après un reset tant que S n'est pas chargé, subtilité peu connue mais ô combien indispensable quand on y réfléchit une seconde. Ce code pourrait bien m'être utile un jour.

Edit: mais je n'ai pas trouvé l'implémentation de HCF ? :D


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Avr 2021, 23:48 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Il fait gaffe aussi de mettre $FF dans la partie haute du registre destination quand on fait un tfr/exg entre 8 et 16bits (TFR A,X).

Il a même fait en sorte que EXG coute 8 cycles, donc seulement 2 qui font quelque chose et 6 don't care avec $FFFF sur le bus d'adresse. Je ne sais pas ce qu'il se passe pendant ces 8 cycles dans l'implémentation Motorola d'origine. Sans doute que l'optimisation du nombre de porte logique les a forcés à découper le TFR / EXG en pleins de plus petites opérations élémentaires, mais je me demande bien lesquelles.

Il a même une page de réflexions sur ce que serait un super 6809... et surprise, il ne préconise pas le 6309.

Le HCF c'est à la base un truc de débug qui sort NNNN,NNNN+1,NNNN+2,... sur le bus à toute vitesse. Ca serait facile à ajouter si besoin. M'enfin pour ce que ca sert...

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Avr 2021, 11:40 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Attention aux multiplications sur 68000, ce sont du 16x16 -> 32. C'est forcément plus long que du 8x8 -> 16 bits, et pas qu'un peu: il y a 2x plus de bits à traiter et comme l'algorithme utilisé est quadratique ca prends 4x plus de temps à la base. Si tu ajoute que l'addition 32 bits est plus lente sur 68000 que le 16bits tu réalises qu'une mul 16x16 est une grosse opération.


Oui mais c'est aussi le cas du 6309 que j'ai cité!! Sur 6309, l'instruction MULD (mult 16x16 bits vers 32) prend 28 cycles d'horloges seulement et DIVD n'en prend que 27!! On est loin des 70 et 140 du 68k!! (Je viens de relire la doc pdf du 6309).

Samuel Devulder a écrit:
Par contre diviser n'a pas vraiment d'algo parallèle est toujours super super lent à produire les bits un à un ou 2 par 2 (ce qui n'est qu'à peine mieux vu la complexité logique impliquée).


Eh si!! L'algo pour la division est quasiment le même! On fait des décalage à gauche (de A vers B par exemple) et quand on obtient une valeur >= au dividende (sur B), on ajoute un bit au même niveau du quotient (sur A!!) AU MEME NIVEAU de bit et on soustrait au diviseur. C'est quasiment la même chose (et c'est pourquoi le DIV sur 6309 prend le même nombre de cycles d'ailleurs)...

Quant au problème de signe, j'ai déjà dit qu'il suffisait de le stocker dans un drapeau, sachant qu'un -par - donne un + et qu'un + par + donne un -, il suffit de faire un XOR sur le signe (1 xor 1 1xor 0 etc)

Samuel Devulder a écrit:
On peut retrouver une re-implémentation "cycle-exact" du mc6809 en verilog (ici) et voir que la multiplication est assez simple. Il y a le fetch (1 cycle) comme sur toutes les instructions + le décode/init (1 cycle) + une boucle de 8 itérations (8 cycles) qui fait du shift + add consommant un bit à la fois d'un des nombres + une étape finale pour écrire le résultat dans D et mettre à jour le registre de contrôle. Total 1+1+8+1=11 cycles. Ca colle assez bien.


Perso j'avais trouvé le même genre d'algorithme sur un site mais au format image. Effectivement c'est proportionnel aux nombre de bits. Je t'en avais parlé d'ailleurs Sam. Mais évidemment, on ne peux pas reproduire en un seul cycle la boucle citée ici en assembleur seul.


Dernière édition par Neotenien le 21 Avr 2021, 11:58, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Avr 2021, 11:52 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Bon, j'abandonne!

Tu expliqueras ta théorie aux codeurs sur Amiga, je pense notamment à insane, scoopex et d'autres sur ST dont je me suis largement inspiré pour faire mes codes à l'époque... :roll:


A toi de voir et comprendre ce que je t'ai expliqué (je t'ai donné les références tu n'as qu'à faire les calcul toi même), je ne pense pas qu'il y ait d'erreur, je suis quasi ingénieur informatique au CNAM et j'en ai fait de l'optimisation de code déjà (par exemple avec le tri knuth ou des optim de calcul d'inversion de matrice).

Et pour ce qui est de la référence en 68k, je connais Vincent Rivière qui est une pointure du monde Atari, il bosse à l'INRIA si je ne me trompe pas, et a adapté des truc d'unix vers le tout nouvel ordinateur compatible ST le FireBee"

Et d'ailleurs la méthode de multiplication et division rapide en assembleur existant en ordi 8 bits est basée sur des décalages de bits. A fortiori ça inclut les multiplication division par puissances de 2.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Avr 2021, 12:26 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Citation:
Eh si!! L'algo pour la division est quasiment le même!

Oui mais non. C'est l'une des complexité quand on pense HDL: ca n'est pas du soft. Ca a l'air idiot comme remarque, mais cela a toute son importance car c'est ce qui rend les instructions à microcode plus lentes et moins gourmand en portes logiques que les instruction directement encodées dans le matériel.

En soft tout est séquentiel et c'est lent. En HDL tout est massivement parallèle. Les mêmes algorithmes ne s'appliquent pas forcément à l'un et à l'autre.

L'algo de division est séquentiel. Le tour suivant attends le résultat complet de l'étape antérieure avant de pouvoir décider si tel nombre est plus grand ou plus petit que tel autre (ce qui permet de savoir si le bit du diviseur est à 0 ou 1). Il lui faut donc beaucoup de temps pour obtenir tous les bits. Remarquons aussi que c'est le cas de la multiplication classique telle qu'implémentée dans les vieux CPUs comme le 6809/6309 aussi.

Par contre l'opération de multiplication peut être massivement parallélisée au point de pouvoir la réaliser en nettement moins de temps qu'il y a de bits à produire. En effet les additions étant commutatives, leur ordre n'importe pas. On peut les regrouper comme on veut, par exemple 3 par 3, 4 par 4, et utiliser additionneur s'épargnant la retenue (carry-save adder) pour avoir le résultat de l'addition de plusieurs nombre dans sensiblement le temps que prendrait une seule addition avec retenue classique.

Ceci explique que même sur des CPU super modernes comme le mc68060, la division reste nettement plus lente qu'une multiplication.

Citation:
Quant au problème de signe, j'ai déjà dit qu'il suffisait de le stocker dans un drapeau, sachant qu'un -par - donne un + et qu'un + par + donne un -, il suffit de faire un XOR sur le signe (1 xor 1 1xor 0 etc)

Oui, mais tu passe à coté de l'ensemble du calcul. Ce n'est pas tout de décider le signe final. Ce qui coute aussi est de passer à la valeur absolue des entrées et appliquer le signe à la sortie et faire le produit au milieu. Ca fait pas mal d'étapes plus coûteuses qu'un xor. Heureusement, pour les multiplications signées il y a des algorithmes efficaces qui font mieux que ca: Booth algorithm ou d'autres.

sam (oui je sais ca fait beaucoup d'indiens à cette heure, mais qu'on se rassure chez Motorola on utilise surtout des Big Endians :langue: :bouffon: )

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 276 messages ]  Aller à la page Précédente  1 ... 9, 10, 11, 12, 13, 14, 15 ... 19  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 23 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com