cosinus et sinus - Page 4

Oui mais je ne peut plus optimiser mes multiplications et divisions avec un décalage binaire. C'est ça le pb.

Pour le "mystère du d0", d0 est le premier paramètre de Sprite8...

> Oui mais je ne peut plus optimiser mes multiplications et divisions avec un décalage binaire. C'est ça le pb.
Bah si, 128 est proche de 127, donc à moins que tu aies impérativement besoin de cos(0) = 1 tout rond, ce n'est pas un pb.

Bon je vais rien changé, surtout que d'avoir pi/2... pile poil n'est pas interessant dans mon cas.

J'ai écrit en ./73 :

J'avais oublié de préciser que ma technique de bouclage automatique de l'indice rad ne marche que si la table ne contient que des char (signés ou non).
En représentant 1 par 128, ça coince, dons on pourrait représenter 1 par 127 ... ou mieux par 64 : c'est 2 fois moins précis, certes, mais ça permet encore une autre optimisation que j'avais zappée.[...]

@++

-128 a 127

pas -127 a 127

Attention, ça peut être utile dans certains cas d'être certain que sin(x) = -sin(x+pi) ... (sinon on peut avoir des petits "bugs visuels")
Bien sûr tout dépend de l'utilisation qu'on en fait.

Ethaniel
: grâce à l'overflow (oui, je sais, c'est un abus de langage, puisque l'overflow ne concerne que les signés ...)

On parle aussi de "unsigned overflow", et c'est d'ailleurs le seul qui a un comportement déterminé en C. Si les signés débordent, tu as n'importe quoi en résultat.

Ethaniel
: Sur un unsigned, il n'y a pas de signe, donc pas d'extension de signe.

Mais il y a des extensions par 0 (zero-extensions) à la place.

Et le char, c'est pour travailler directement en 8 bit, sans avoir besoin de faire une translation pour revenir dans [[0 ; 255]].

Sauf que le C définit que les calculs intermédiaires se font dans des int. Mais le compilateur peut optimiser des trucs comme l'addition des char pour calculer directement sur 8 bits.

Ethaniel :
avec juste l'équivalent du Carry Flag (ça existe sur TI ? Je suppose que oui)

Oui (flag C). Et il y a aussi un flag lié, le flag X.

qui sera allumé (exception faite des instructions inc et dec sous x86, mais ceci est une autre histoire)

L'équivalent du 68k (addq #1 et subq #1) gère correctement les flags.

geogeo
:

Oh que si !!!
x_pcos=xpos*128 -> multiplication -> très long à réaliser par le processeur
xpos=x_pcos/128 -> division -> encore pire
x_pcos=xpos<<7 -> décalage de bits -> un seul cycle d'horloge, c'est tout xpos=xpos>>7 -> idem

Euh le compilateur optimise et heuresmeent, si il n'optimiserait pas, je n'aurais pas fait de multiplications et division. Mais je les laisse car c'est plus lissible.
[EDIT] LE compilateur remplce mes multiplications et divisions par des puissances de 2.

Pour la multiplication, soit, mais pour la division d'un nombre signé, il ne donne certainement pas ce que tu attends. Il est obligé de mettre des trucs de plus pour gérer le fait que la division signée arrondit toujours vers 0 alors que le décalage arithmétique arrondit toujours vers le bas (même si on s'éloigne de 0). Il faut impérativement mettre le décalage.

Oui c'est ce que je fait, je met les décalages maintenant, même si c'est un peu moins lisible. Il faut je pense faire de moins en moins faire confiance au compilateur.

Ce n'est pas la faute du compilateur, il ne fait que ce qui est demandé par le standard C.

Je ne disais pas ça, je veux juste dire qu'il faut mieux écrire les optimisations soit même.

L'équivalent du 68k (addq #1 et subq #1) gère correctement les flags.

Je ne sais pas si le "correctement" et le "" sont vraiment justifiés, après tout ça pourrait être utile d'avoir aussi une instruction "inc" qui garde les flags. Pourquoi est-ce que tu essayes de te convaincre que tout va pour le mieux dans le meillleur des mondes?

Il faut je pense faire de moins en moins faire confiance au compilateur.

Ca dépend. Dans certains cas, ce n'est pas une bonne idée, parce que le compilo peut s'améliorer, donc il vaut mieux éviter certaines choses qui ne pourront pas évoluer avec le compilo (asm inline, sauf dans des cas spécifiques du style de rol/ror, ou à moins de vraiment bien maîtriser). Dans d'autres (remplacement par une forme équivalente, ou, comme c'est le cas pour /128 -> >>7, ajout ou modification d'informations données au compilo), c'est effectivement une bonne idée

Pollux
:

L'équivalent du 68k (addq #1 et subq #1) gère correctement les flags.

Je ne sais pas si le "correctement" et le "" sont vraiment justifiés, après tout ça pourrait être utile d'avoir aussi une instruction "inc" qui garde les flags.

Bon, oui, l'idéal serait d'avoir les 2. Mais comment veux-tu faire une boucle convenable si ton addq et ton subq ne mettent pas le flag Z? Donc il faut bien une version qui met les flags. Et comme plus d'instructions = instructions plus grosses, ben, la solution du 68k me va très bien.

Pourquoi est-ce que tu essayes de te convaincre que tout va pour le mieux dans le meillleur des mondes?

Cf. ci-dessus.

Il faut je pense faire de moins en moins faire confiance au compilateur.

Ca dépend. Dans certains cas, ce n'est pas une bonne idée, parce que le compilo peut s'améliorer, donc il vaut mieux éviter certaines choses qui ne pourront pas évoluer avec le compilo (asm inline, sauf dans des cas spécifiques du style de rol/ror, ou à moins de vraiment bien maîtriser). Dans d'autres (remplacement par une forme équivalente, ou, comme c'est le cas pour /128 -> >>7, ajout ou modification d'informations données au compilo), c'est effectivement une bonne idée

Attention, non-objectivité détectée...
La vraie raison pour laquelle il vous déconseille l'assembleur inline est parce que son compilateur ne comprend pas la syntaxe d'assembleur inline que pratiquement tout le monde ici utilise. Pas parce que ça donne du code moins bien. De l'assembleur inline bien fait donnera toujours du code au moins aussi bon que celui du compilateur.

Bon, oui, l'idéal serait d'avoir les 2. Mais comment veux-tu faire une boucle convenable si ton addq et ton subq ne mettent pas le flag Z? Donc il faut bien une version qui met les flags. Et comme plus d'instructions = instructions plus grosses, ben, la solution du 68k me va très bien.

Je crois qu'il y a aussi des instructions de boucles sur x86. Et puis pour l'histoire des "instructions plus grosses", ça ne tient pas debout (un "inc" prend 8x moins d'opcodes qu'un "addq"/"subq", et autant que les "lsl"/"lsr"/"rol"/"ror"/"roxl"/"roxr" pour des opérandes en mémoire, qui sont utilisées très rarement, à part peut-être pour la vieille technique du "scrolling de 1 pixel") En revanche la complexité du processeur est un argument valable. Enfin bon, ce que je voulais dire, c'est que ce n'est pas forcément "bien mieux".

Attention, non-objectivité détectée... La vraie raison pour laquelle il vous déconseille l'assembleur inline est parce que son compilateur ne comprend pas la syntaxe d'assembleur inline que pratiquement tout le monde ici utilise.

Absolument pas. De toute façon je ne sortirai pas GTC sans support de l'asm inline.

Pas parce que ça donne du code moins bien.

Si tu veux que je détaille mon point de vue :
1) l'asm inline n'est qu'un exemple, ça s'applique aussi aux routines en ASM pur
2) en plus l'asm inline présente le danger de ne pas bien lire la doc, résultat : "move.w %1,%%d0;move.w %2,%%a0" au lieu d'utiliser les flags faits pour (et de toutes façons on risque d'oublier des modes d'adressages qui conviendraient aussi, ou encore à la limite d'en rajouter en trop => pbs de compatibilité ascendante)
3) cf point suivant :

De l'assembleur inline bien fait donnera toujours du code au moins aussi bon que celui du compilateur.

On est d'accord, cf dans le post précédent "à moins de vraiment bien maîtriser". Mais même si un être humain peut, à un stade donné du projet, optimiser mieux que le compilo, lorsque le projet évolue, ce qui est important au niveau de l'optimisation (variables les plus fréquemment utilisées, par exemple) risque de changer, et l'optimisation qu'a fait le programmeur risque bien de ne servir à rien, et pire encore, d'empêcher le compilo d'ajuster le code en conséquence. Donc, l'assembleur (inline ou pas), OK, mais il faut vraiment le faire quand on a une idée bien précise de ce qu'on veut faire (i.e. plutôt lorsque l'algorithme tourne bien et qu'on sait quelles seront les variables/fonctions les plus fréquemment utilisées), et quand on connaît bien l'assembleur 68k. Dès qu'on modifie de l'assembleur "optimisé", il a pas mal de chances de ne plus le rester...