Re: Meilleurs algo d'un test par bouding box

[Stef]

La progression est très rapide, j'ai commencé à remplacé certaines choses lentes en C, en ASM, après c'était les fonctions, je les écrivaient en C, et dés qu'elles marchaient je les convertissaient .
Et à force de remplacer, tu codes tout en ASM, ça va plus vite, car tu optimises quasiment dans la foulée .
Une foi que tu comprends comment ça marche, c'est pas plus dur que le basic .
La difficulté en ASM, c'est de faire un truc de A à Z en écrivant tout, pas si tu as déjà une osature, style un compilateur qui te permet de mettre des lignes asm dedans .
Evidemment pour moi c'est valable sur des consoles/micros 8/16 bit, sur pc ça sert à rien .

Y'a quand même un truc très galère avec l'assembleur... Ca prend quand même nettement plus de temps à écrire que du C. Et surtout quand tu as optimisé une fonction en assembleur et que tu dois faire un changement dedans, parfois (même souvent) tu dois modifier une bonne partie de la fonction pour garder un bon niveau d'optimisation. Pour ça en général je préfère rester en C et passer en assembleur uniquement au tout dernier moment quand je sais que mon code ne bougera plus.

[fanoplusplus64K]

Tu as raison sur le fond , c'est vrai que tu passes plus de temps à écrire ton code qu'en C.Le plus long en fait c'est de penser ton code car tu dois penser aux détails de l'implémentation mais tu finis par chopper des automatismes qui te font gagner du temps.
Après , je dirai que c'est le prix à payer , surtout sur 8bits où tu as peu de ressources et où le C est trop gourmand en temps et en place.
Je serai tenté aussi de dire que si ton code est mal foutu et lent en C, il le sera tout autant en asm.

[Stef]

Tu as raison sur le fond , c'est vrai que tu passes plus de temps à écrire ton code qu'en C.Le plus long en fait c'est de penser ton code car tu dois penser aux détails de l'implémentation mais tu finis par chopper des automatismes qui te font gagner du temps.
Après , je dirai que c'est le prix à payer , surtout sur 8bits où tu as peu de ressources et où le C est trop gourmand en temps et en place.
Je serai tenté aussi de dire que si ton code est mal foutu et lent en C, il le sera tout autant en asm.

Oui un code pourri en C transcrit en assembleur tel quel sera lent aussi :p Pas de doute là dessus mais c'est quand même nettement plus rapide (en tout cas pour moi) de pondre un algo en C un minimum optimisé qu'en assembleur.
Le C s'occupe lui même de l'allocation des registres, de la manière d'accéder tes tableaux, réduction des constantes etc... et c'est quand même très pratique :)
Dans ma lib SGDK j'ai beaucoup analysé le code assembleur produit par le compilateur C, ainsi je sais comment écrire mon code C pour l'aider à optimiser le code généré derrière. Bien sur ça ne sera jamais aussi rapide que de l'assembleur fait main mais au moins dans 90% des cas c'est satisfaisant on va dire :)

[Stef]

Tiens sinon je viens d'optimiser encore un peu la routine 6502: 76 cycles / loop.
Ayé je suis fan de ce CPU :p

edit: je plaisante, je suis juste fan d'optimisation en général  

[Invité]

Y'a quand même un truc très galère avec l'assembleur... Ca prend quand même nettement plus de temps à écrire que du C. Et surtout quand tu as optimisé une fonction en assembleur et que tu dois faire un changement dedans, parfois (même souvent) tu dois modifier une bonne partie de la fonction pour garder un bon niveau d'optimisation. Pour ça en général je préfère rester en C et passer en assembleur uniquement au tout dernier moment quand je sais que mon code ne bougera plus.

Oui mais toi tu es habitué au luxe   
Un bon compilo qui te permet de faire de supers trucs, viens sur pce, tu verras que l'ASM c'est plus rapide au final   
Rien qu'une simple boucle while(1) doit te prendre 100 cycles, je déconne mais pas tant que ça hélas   
j'essaye aussi d'éviter de faire des trucs spécifiques à un jeu/demo quand je dev mes trucs pour éviter ce piège .
Après tout dépend ce que tu cherches à faire, des fois pour des raisons de perfs tu fais au plus rapide .

Tiens sinon je viens d'optimiser encore un peu la routine 6502: 76 cycles / loop.
Ayé je suis fan de ce CPU :p

edit: je plaisante, je suis juste fan d'optimisation en général  

Avantage des instructions simples, quand y'a plus d'optimisation, y'en a encore   
et si tu veux être the best 6502 coder, il faut que tu utilises les illegal opcode  
http://codebase64.org/doku.php?id=base:6502_6510_coding#illegal_opcodes

C'est un CPU très efficace en général, moins pour d'autres taches, mais c'est au dev de faire en sorte que ce type de cas soit le plus rare possible .

Je serai tenté aussi de dire que si ton code est mal foutu et lent en C, il le sera tout autant en asm.

+1

Dans ma lib SGDK j'ai beaucoup analysé le code assembleur produit par le compilateur C, ainsi je sais comment écrire mon code C pour l'aider à optimiser le code généré derrière. Bien sur ça ne sera jamais aussi rapide que de l'assembleur fait main mais au moins dans 90% des cas c'est satisfaisant on va dire :)

en plus pour le C le 68000 est top  ..

[Stef]

Oui mais toi tu es habitué au luxe   
Un bon compilo qui te permet de faire de supers trucs, viens sur pce, tu verras que l'ASM c'est plus rapide au final   
Rien qu'une simple boucle while(1) doit te prendre 100 cycles, je déconne mais pas tant que ça hélas   

Je sais mais bon voilà, c'est aussi un des avantages du 68000, un CPU plus avancé qui peut être utilisé par un compilateur de plus haut niveau. C'est pas la panacé non plus mais ça reste possible

Avantage des instructions simples, quand y'a plus d'optimisation, y'en a encore   
et si tu veux être the best 6502 coder, il faut que tu utilises les illegal opcode  
http://codebase64.org/doku.php?id=base:6502_6510_coding#illegal_opcodes

Là pour le coup ça n'a rien à voir avec le CPU en lui même, enfin si car je supprime une instruction qui n'a pas lieu d'être sur les autres CPU ^^ mais c'est surtout que j'exploite la connaissance des flags lors de mes branchements et ça c'est une astuce assez classique (au détriment de la taille du code mais là osef).

en plus pour le C le 68000 est top  ..

Je ne dirais pas "top", ça marche pas trop mal mais le problème c'est de trouver des anciens compilateur C car les nouveaux optimisent vraiment mal pour un CPU aussi vieux que le 68000 :-/ Genre je reste en GCC 3.4.6 pour cette raison, et encore il est loin d'être parfait (bug et soucis d'optis).

[Invité]

Je sais mais bon voilà, c'est aussi un des avantages du 68000, un CPU plus avancé qui peut être utilisé par un compilateur de plus haut niveau. C'est pas la panacé non plus mais ça reste possible 

Bien sur, j'ai jamais nié, là le 68000 domine largement .
Et il me semble que ecco a été dev en C non ???

Je ne dirais pas "top", ça marche pas trop mal mais le problème c'est de trouver des anciens compilateur C car les nouveaux optimisent vraiment mal pour un CPU aussi vieux que le 68000 :-/ Genre je reste en GCC 3.4.6 pour cette raison, et encore il est loin d'être parfait (bug et soucis d'optis).

Oui top pour les CPU de cette époque .

Là pour le coup ça n'a rien à voir avec le CPU en lui même, enfin si car je supprime une instruction qui n'a pas lieu d'être sur les autres CPU ^^ mais c'est surtout que j'exploite la connaissance des flags lors de mes branchements et ça c'est une astuce assez classique (au détriment de la taille du code mais là osef).

C'est vrai, ce type d'optimisation est valable pour les autres CPU aussi, cependant les illegal opcode du 6502 (et seulement ceux là) peuvent te faire gagner des cycles, peut être pas là, mais je sais qu'elles sont souvent utilisées dans les demos C64 .

[Stef]

Bien sur, j'ai jamais nié, là le 68000 domine largement .
Et il me semble que ecco a été dev en C non ???

C'est ce qu'il se dit, je ne sais pas si c'est vrai mais vu le jeu, techniquement ça pourrait tenir en pur C.

C'est vrai, ce type d'optimisation est valable pour les autres CPU aussi, cependant les illegal opcode du 6502 (et seulement ceux là) peuvent te faire gagner des cycles, peut être pas là, mais je sais qu'elles sont souvent utilisées dans les demos C64 .

Oui j'ai regardé un peu les illegals opcodes mais à part dans de rares cas elles ne sont pas très interessantes je trouve, tu as le même genre de chose sur le Z80 d'ailleurs :p

[Invité]

stef pour calculer un score sur 10 chiffres, tu ferrais comment sur le 68000 ??

C'est ce qu'il se dit, je ne sais pas si c'est vrai mais vu le jeu, techniquement ça pourrait tenir en pur C.

Bah sur 6502 ou 6280 tu peux toujours te gratter pour arriver à ce niveau en C .
Trop de perte en perfs et en mémoire .

 tu as le même genre de chose sur le Z80 d'ailleurs :p

Ah bon, j'aimerai bien savoir si fano en utilise, vu qu'il est aussi demomaker sur CPC .

[Stef]

stef pour calculer un score sur 10 chiffres, tu ferrais comment sur le 68000 ??

T'as des instructions BCD si c'est ta question... d'ailleurs  j'ai vu qu'elles n'existent pas sur le 2A03, ça doit être bien chiant ça ^^

10 chiffres ça fait quand même pas mal, disons que 8 ça rentre dans un registre 32 bits (en BCD), pour 10 chiffres il te faudrait 2 registres.

[Invité]

Oui j'ai ça, mais justement je voulais voir si pour un truc comme ça, ce que ça donne sur 68000, t'a pas une routine déjà faite ??

Code:

2 sed
4  lda   <val_temp1         
2 clc         
5 adc    _score      ; // Unites & dixaines
5 sta    _score
4 lda   <val_temp1 + 1
5 adc   _score + 1   ; // Centaine & milliers         
5 sta    _score + 1
2 cla    
5 adc    _score + 2   ; // 10 aine de millier & 100 aine de millier
5 sta    _score + 2
2 cla    
5 adc    _score + 3   ; // 10 aine de millier & 100 aine de millier
5 sta    _score + 3
2 cla    
5 adc    _score + 4   ; // 10 aine de millier & 100 aine de millier
5 sta    _score + 4
         
2 cld         ; // Désactive le mode décimal        

70 Cycles, mais je sais pas si c'est bcp pour un calcul comme ça .
je garde un peu de ZP pour les situations plus critiques .

Dernière édition par TOUKO le Mer 5 Fév 2014 - 17:05, édité 3 fois

[fanoplusplus64K]

Ah bon, j'aimerai bien savoir si fano en utilise, vu qu'il est aussi demomaker sur CPC .

Je ne suis pas à vrai dire démomaker , plutôt programmeur de jeux même si j'ai une productivité assez faible =)
Mais oui , il y a pas mal de tricks sur Z80, reproductibles ou pas sur d'autres processeurs.
Il y a aussi des opcodes non documentés (enfin documentés depuis car ils sont inclus dans la syntaxe de tout bon assembleur Z80) qui ciblent les parties haute et basse des registres d'index (IXL,IXH,IYL,IYH) pour les plus utiles.C'est très utile car tu te retrouves avec 4 registres en plus que tu peux affecter à des opérations non critiques car il ont une pénalité de 4 cycles au minimum.
Sinon, sympa l'opcode ANC sur 6501, sur Z80 , pour nettoyer la carry on a un effet de bord de AND et OR (au lieu d'un SCF + CPL, soit 4 cycles d'économisés), tu en as des autres dans le genre.

Le Z80 est aussi pourvu d'instructions BCD (DAA notamment , l'horreur du débutant :/)

[Invité]

Merci pour les précisions ..
Un calcul de score sur 10 chiffres prendrait aussi combien sur Z80 ??
Tu dois quand même déjà en avoir une aussi non ??

Et dsl pour la méprise, je pensais que tu faisais aussi dans la démo . 

DAA notamment , l'horreur du débutant :/

lol, pk horreur du débutant ??
Perso j'avoue qu'au départ c'est assez déroutant le fonctionnement du BCD .

[fanoplusplus64K]

Je n'utilise pas le BCD (sauf pour faire des conversions en hexadécimal) car il faut ensuite que je depack mon bcd pour gérer mes caractères à l'affichage.Sur CPC ou MSX (ou sur SMS si je m'y mets un jour) je suis pas à dix octets prêts.
Après, je peux essayer de te faire une addition à 10 chiffres BCD histoire de voir ce que ça donne.C'est moins confus qu'au départ , mais ta routine additionne bien 1 au score dans l'exemple ?

[vingazole]

TOUKO et son BCD  sont de retour :
https://www.gamopat-forum.com/t30642p150-z80-vs-6502-fight?highlight=z80+6502

(lire fin de page)

[Stef]

Oui j'ai ça, mais justement je voulais voir si pour un truc comme ça, ce que ça donne sur 68000, t'a pas une routine déjà faite ??

Code:

2 sed
4  lda <val_temp1
2 clc
5 adc _score ; // Unites & dixaines
5 sta _score
4 lda <val_temp1 + 1
5 adc _score + 1 ; // Centaine & milliers
5 sta _score + 1
2 cla
5 adc _score + 2 ; // 10 aine de millier & 100 aine de millier
5 sta _score + 2
2 cla
5 adc _score + 3 ; // 10 aine de millier & 100 aine de millier
5 sta _score + 3
2 cla
5 adc _score + 4 ; // 10 aine de millier & 100 aine de millier
5 sta _score + 4
 
2 cld ; // Désactive le mode décimal  

70 Cycles, mais je sais pas si c'est bcp pour un calcul comme ça .
je garde un peu de ZP pour les situations plus critiques .

<val_temp1 est une variable 16 bit que je passe à la routine pour ajouter au score .

En fait je suis assez surpris de la relative faiblesse des instructions BCD sur 68000, ça ne fonctionne qu'en 8 bits :p
Je pense que c'est parce-que les instructions BCD sont en général très peu exploitées (perso je converti en base 10 à l'affichage, en interne je garde tout en binaire).

Voici le code en 68000 :

Code:

4       moveq   #0, d5
12      move.l   (a1), d1
12+16   movem.w (a0)+, d0-d3
44
 
6       abcd d4, d0
4       swap d4
6       abcd d4, d1
6       abcd d5, d2
6       abcd d6, d3
28

8+16    movem.w d0-d3, -(a0)
24

96 cycles... mais c'est clairement un truc sur lequel le 68000 n'est pas fort.
Si tu devais faire ça en critique, tu resterais en binaire et converti en BCD via une table à la fin.

[Stef]

TOUKO et son BCD  sont de retour :
https://www.gamopat-forum.com/t30642p150-z80-vs-6502-fight?highlight=z80+6502

(lire fin de page)

Ouais ben ouais, il prend les trucs rapides du 6502 pour comparer forcément :p
Alors que bon le BCD tout le monde s'en fout

[fanoplusplus64K]

Sur Z80, ça te donne 133 cycles :

Code:

   ld B,0      ;7
   ld A,(HL)   ;7
   add 1      ;7
   daa      ;1
   ld (HL),A   ;7
   inc L      ;4

         ;33

   repeat 3
   ld A,(HL)   ;7
   adc B      ;4
   daa      ;4
   ld (HL),A   ;7
   inc L      ;4

         ;26
   rend

   ld A,(HL)   ;7
   adc B      ;4
   daa      ;4
   ld (HL),A   ;7   
         ;22

         ;133

[vingazole]

Non non, ça s'utilise très souvent le BCD en COBOL



(Je crois que TOUKO ajoute 4 chiffres BCD au score dans sa routine)

[fanoplusplus64K]

Autant pour je , tiens en pas compte touko, je reprends ma routine du début lol

[Invité]

Non non vous méprenez pas je cherche pas une comparaison, juste je voulais savoir par rapport aux votres, si mes 70 cycles ça vous paraissait bcp c'est tout .. 
stef je sais pas si tu déjà une routine de faite .
fano ou vingazole, je me doute que vous en avez , même si vous gardez le code confidentiel, j'aimerai savoir comment vous procédez .

C'était juste une question, rien de plus ..

Moi j'ai pris le BCD parce que ça me semblait être une bonne idée (enfin facile à faire surtout), mais vous vous auriez fait comment ??

En fait je suis assez surpris de la relative faiblesse des instructions BCD sur 68000, ça ne fonctionne qu'en 8 bits :p
Je pense que c'est parce-que les instructions BCD sont en général très peu exploitées (perso je converti en base 10 à l'affichage, en interne je garde tout en binaire).

Sans vouloir comparer, je pensais justement que le 68000 ferrait mieux que moi là .

TOUKO et son BCD  sont de retour :

LOL, pour une fois que je partais d'un bon sentiment ..

mais ta routine additionne bien 1 au score dans l'exemple ?

Non elle additionne n'importe qu'elle valeur 16 bit .dans la var

[Stef]

Ben je t'ai donné la routine sur 68000 (96 cycles) mais je ne fais jamais ce genre d'opération donc je l'ai faite en live... y'a tet mieux.

[fanoplusplus64K]

Du code confidentiel ? j'en ai mais pas pour ça   

Sinon , voilà , après petite recorrection , ça fait 133.Désolé j'ai encore du mal avec la syntaxe et le mnémoniques du 6502/6280 (mais je suis sur qu'après avoir codé un peu sur une pc engine ça irait mieux   )

Code:

   ld B,0      ;7
   ld A,(HL)   ;7
   add E      ;4
   daa      ;4
   ld (HL),A   ;7
   dec L      ;4
         ;33

   ld A,(HL)   ;7
   adc D      ;4
   daa      ;4
   ld (HL),A   ;7
   dec L      ;4
         ;26

   repeat 2
   ld A,(HL)   ;7
   adc B      ;4
   daa      ;4
   ld (HL),A   ;7
   dec L      ;4
         ;26
   rend

   ld A,(HL)   ;7
   adc B      ;4
   daa      ;4
   ld (HL),A   ;7   
         ;22

         ;133

Ben je t'ai donné la routine sur 68000 (96 cycles) mais je ne fais jamais ce genre d'opération donc je l'ai faite en live... y'a tet mieux.

héhé bienvenue au club   

[Stef]

Touko> Tiens au fait le code de collision en 76 cycles sur 6502, il en fait combien sur PCE car il me semble que certaines instructions que j'ai utilisé prenne un cycle en plus sur le 6280.

[Invité]

Touko> Tiens au fait le code de collision en 76 cycles sur 6502, il en fait combien sur PCE car il me semble que certaines instructions que j'ai utilisé prenne un cycle en plus sur le 6280.

9 de plus, les ZP du 6280 prennent 1 cycle de plus .

@fano: si tu développe sur console en général ça va tez changer du CPC, la PCE est très simple à coder.

Vous râlez, vous râlez, mais vous postez aucun exemple !!  

[Stef]

Pourquoi pas un algo de decompression ? avec les collisions c'est ce qui me parait le plus couteux dans un jeu. Genre un simple algo RLE... on peut aussi s'amuser a faire du tracer de ligne, ou un tri mais ce n'est plus tres representatif pour du in game (et aussi plus complique).

Au fait si le ZP prend 1 cycle en plus sur le 6280, kel interet de l'utiliser alors ? du coup t'es a 4 cycles comme un acces memoire normal ? ou le normal prend 5 cycles sur pce ?

[fanoplusplus64K]

@fano: si tu développe sur console en général ça va tez changer du CPC, la PCE est très simple à coder.

J'ai commencé en début d'année (pas le PCE) et je dois reconnaitre qu'avoir un VDP te facilite grandement les choses.

Comme exemple , c'est difficile de trouver un exemple qui ne soit pas spécifique à une machine ou qui ne soit pas complexe.

[vingazole]

@fano: si tu développe sur console en général ça va tez changer du CPC, la PCE est très simple à coder.

J'ai commencé en début d'année (pas le PCE) et je dois reconnaitre qu'avoir un VDP te facilite grandement les choses.

Une console avec un z80 ou tu changes de cpu ?

[fanoplusplus64K]

Je garde mon bon vieux Z80 pour l'instant , pas trop de changement d'un coup ça va me tuer   

[MD2B]

quand vous programmez sur une console, vous utilisez que le code du processeur?

comment se gère alors, le son, la carte graphique...

je n'arrive pas trop a m'expliquer en faite, programmer une une console doit se faire en fonction de son architecture? vous voyez ce que je veux dire 

[Stef]

En fait tu écris (avec ton CPU) dans des emplacements mémoires particuliers qui représentent les ports des différents périphériques (processeur video, sonore...). Bien sur tu as toujours une doc pour t'expliquer comment programmer les différents périphériques.