Meilleurs algo d'un test par bouding box

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.

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.

fanoplusplus64K a écrit: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 :)

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  

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  ..

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).

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 .

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

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 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.

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 .