cosinus et sinus - Page 3

Ethaniel :
Quelqu'un pourrait-il me faire un petit topo des types de variables utilisés en C sur TI (nom, nombre de bits utilisés, ...).
Je n'y connais rien, donc n'ai rien compris à la phrase 'je m'oblige donc à la coder en short'.

Ce sont ceux du C :
char : un octet
short : deux octets
long : quatre octets

Tous ces types peuvent évidemment être signés (en complément à 2) ou non signés.
Il existe d'autres types, plus compliqués, ceux-ci sont les principaux.

Donc c'est bien ce que je pensais : déclarer rad en tant que unsigned char, comme ça il restera automatiquement dans l'intervalle [[0 ; 255]] sans avoir à faire un and word [rad], 0xFF (chassez le naturel, il revient au galop ).

@++

Sauf que le compilo est obligé de le faire plus tard, le &255 (au moment d'accéder au tableau).

pourquoi ?

move.b d0,a0 -> 'error'
0(a0,d0.b) -> 'error' ...

Sans compter que ça ne marcherait que si la table faisait moins de 128 octets, ce qui n'est pas le cas.

Enfin si tu trouves un moyen révolutionnaire de le faire, vas-y (en tout cas indépendamment d'optimisations plus globales du style : la partie haute du registre dans lequel est stocké 'rad' est toujours nulle, donc pas besoin d'extension de signe)

Ah oui, j'avais oublié ça
Je pensais plutôt à une spécificité du C qui imposerait ce genre de comportement qu'à une spécificité du 68k

Ben ça veut dire qu'il n'y a absolument aucune raison que tu utilises une table fausse alors que tu pourrais en utiliser une qui est juste... Ton code calcule les angles modulo 256, donc nécessairement 2pi doit correspondre mathématiquement à 256 (et pas 255). Après, ton code peut ne pas utiliser le nombre 256 (et donc tu n'as pas du tout besoin de passer aux shorts à cause de ça), mais en tout cas il doit utiliser table_sin[i] = sin(2pi*i/256) et pas sin(2pi*i/255) (sinon ce serait incohérent avec le reste de ton code).

OK, je vais corriger ce petit pb, j'en ai pour pas longtemps.
Je me souviens d'avoir réalisé une table avec un pas divisé par 255. Merci Visual Basic, en 2 mins j'ai ma table.

Il est dommage que tu t'arrêtes à une version qui marche mais qui n'exploite pas du tout les possibilités d'optimisation que permettent l'algorithmie et l'architecture du processeur.
De plus, il est alors totalement impossible du diriger la balle pile à la verticale ou vers la gauche, ce qui est un peu dommage et illogique. En bref, ne te contente pas du minimum, surtout quand il est tout pourri ...

Bah ça serait illogique dans mon jeu que la balle ce déplace pile poil à 2pi/2..., bref je vais arranger ça.

Je ne sais pas si Sasume partage mon opinion, mais telle est la mienne.

Je pense qu'il partage ton optinion et vous avez raison.

C'est la premier fois que je développe un jeu donc je vais tacher de faire un truc propre, rapide et amusant.

Quelqu'un pourrait-il SVP me faire un petit topo des types de variables utilisés en C sur TI (nom, nombre de bits utilisés, ...) ? Je n'y connais rien, donc n'ai rien compris à la phrase 'je m'oblige donc à la coder en short'.

'signed' char=8 bits=-128 à 127
unsigned char=8bits=0 à 255
'signed' short=16 bits=-32768 à 32767
unsigned short=16 bits=0 à 65535
'signed' long=32 bits=2147483648 à 2147483647
unsigned long=32 bits=0 à 4294967295
int=signed short (sur TI)

Ben il faudrait un mode indexé en 'unsigned char', et encore ça ne marcherait pas pour des tables dont les éléments font plus de 1 octets (c'est là où le standard C intervient, parce qu'on ne pourrait pas l'utiliser même avec des tables de moins de 256 octets - le 'unsigned char' est promu en 'size_t' _avant_ la multiplication).

Merci Visual Basic, en 2 mins j'ai ma table.

Clair c'est d'ailleurs la seule utilité qu'on peut lui trouver (je l'ai utilisé aussi à l'époque où j'avais besoin de ça, une boîte de texte, un Form_Load() qui touche à Text et hop, bouclé pas besoin de sauvegarder de fichier ou de créer de projet)

Moi non plus, je ne vois pas pourquoi, et je ne vois pas ce que le compilateur viens faire là-dedans : d'après ce que je sais, un unsigned char est un entier pouvant prendre toute valeur entre 0 inclus et 255 inclus (ce sont justement les limites des tables de sinus et cosinus), avec bouclage automatique (en incrémentant un byte contenant 255, il contiendra 0, et en décrémentant un byte contenant 0, il contiendra 255, avec juste l'équivalent du Carry Flag (ça existe sur TI ? Je suppose que oui) qui sera allumé (exception faite des instructions inc et dec sous x86, mais ceci est une autre histoire)).
Je ne vois pas du tout où est le problème, je fais ça tous les jours (façon de parler ) en Asm x86.

@++

[edit]Et hop, 3 posts le temps que je rédige ...[/edit]

Et ouai, mais c'est utile dans d'autres domaines.
PS: C'est la seule façon pour moi pour l'instant de faire des programmes sur PC.

Il n'y a pas de problème, ça économise même une ligne de code (au prix de qques caractères en plus pour écrire le type ). Sauf que le code généré n'est a priori pas meilleur qu'avec un short et, si le CSE du compilo n'est pas parfait, ce sera même moins efficace.

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.
Voici donc les 3 versions qui en résultent :

; ypos=y_psin/128;

* version originale :	x_pcos=xpos*128; y_psin=ypos*128;
[...]
		xpos=x_pcos/128

4; [...] xpos=x_pcos/64; ypos=y_psin/64;* version '1 représenté par 64', mode basique : x_pcos=xpos*64; y_psin=ypos*6
* version originale '1 représenté par 64', mode 'Asm powaa !>6;

' :	x_pcos=xpos<<6; y_psin=ypos<<6;
[...]
		xpos=x_pcos>>6;
		ypos=y_psin>

@++

Je présume que xpos est un float? Je ne pense pas qu'il y ait de << pour les floats...

xpos n'est pas un float.

Et je ne vois pas l'optimisation majeur ici
x_pcos=xpos*128 = x_pcos=xpos<<7;
xpos=x_pcos/128 = xpos=xpos>>7;

De plus xpos et ypos sont en short.

xpos=x_pcos/128 <=> xpos=x_pcos>>7

Non, pas si x_pcos est négatif (dans ce cas, x_pcos/128=-((-x_pcos)>>7) et x_pcos>>7=~((~x_pcos)>>7)=-1-((-1-x_pcos)>>7), ce qui n'est pas pareil [mais la différence est au plus de 1])


Et je parlais de float parce que diviser un entier par un nombre plus grand que lui n'a pas d'intérêt...

Non, pas si x_pcos est négatif (dans ce cas, x_pcos/128=-((-x_pcos)>>7) et x_pcos>>7=~((~x_pcos)>>7)=-1-((-1-x_pcos)>>7), ce qui n'est pas pareil [mais la différence est au plus de 1])

xpos ne sera jamais négatif.

xpos ne correspond peut-être pas à ce que toi tu as défini, mais tel que l'écrit Ethaniel, xpos peut être négatif puisque le cos peut l'être...

@ Pollux : c'est pcos=Tbl_pcos [rad] qui peut être négatif, pas x_pcos ni xpos.
Cf. post ./26.
@ geogeo :

[...]

Et je ne vois pas l'optimisation majeur ici
x_pcos=xpos*128 = x_pcos=xpos<<7;
xpos=x_pcos/128 = xpos=xpos>>7;
[...]

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

Mathématiquement (et humainement), c'est pareil, mais pour le processeur, ça n'a strictement aucun rapport (jusqu'au jour où un compilateur sera suffisamment évolué pour remplacer automatiquement les multiplications et divisions par des puissances de 2 par les décalages correspondant).

@++

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.

Je ne suis pas convaincu, surtout pour les divisions ...

@++

move.w xpos,%d0
move.w %d0,%d1
lsl.w #7,%d1
move.w %d1,x_pcos
move.w %d4,%d1
lsl.w #7,%d1
move.w %d1,y_psin

Je comprend pas cette optimisation:

move.w xpos,%d0
[4]move.w %d0,%d1[/4]

Je ne suis pas convaincu, surtout pour les divisions ...
@++

Là ça ce vois quand même

move.w x_pcos,%d0
add.w pcos,%d0
move.w %d0,x_pcos
move.w y_psin,%d1
add.w psin,%d1
move.w %d1,y_psin
[u]lsr.w #7,%d0[/u]
move.w %d0,xpos
[u]lsr.w #7,%d1[/u]
move.w %d1,ypos

Par souci de cohérence, je suppose qu'il y a un move.w ypos,%d4 juste au dessus.

Ensuite, pour le transfert xpos->%d0->%d1 (et ypos->%d4->%d1), ma seule explication est que %d0 (xpos) est réutilisé peu après.
Le compilateur avait donc le choix entre :
* cloner %d0 dans %d1, et faire le décalage sur %d1 => transfert registre->registre
* faire le décalage sur %d0, puis réenregistrer xpos dans %d0 => transfert mémoire->registre
Or un transfert registre->registre est plus rapide qu'un transfert mémoire->registre, et est codé sur moins d'octets.

Mais c'est vrai, là, je suis impressionné par les optimisations (multiplication comme division) du compilateur, chapeau !

Note : c'est la première fois que je vois de l'Asm 68k ... c'est tout bidon !
Euh, oui, bon, une fois qu'un connaît déjà l'Assembleur, c'est vrai, je le concede ...

@++

Par souci de cohérence, je suppose qu'il y a un move.w ypos,%d4 juste au dessus.

oui.

Ensuite, pour le transfert xpos->%d0->%d1 (et ypos->%d4->%d1), ma seule explication est que %d0 (xpos) est réutilisé peu après.

Je ne vois aucune réutilisation de d0 après

__main:
	link.w %a6,#0
	movm.l #0x1c38,-(%sp)
	move.l 100.w,OldInt1
	move.l 116.w,OldInt5
	move.l #__dummy_handler__,262244
	move.l #__dummy_handler__,262260
	move.l 200.w,%a0
	move.l 1656(%a0),%a0
	jbsr (%a0)
	jbsr GrayOn
	moveq.l #1,%d5
	move.w __calculator,%d1
	moveq.l #120,%d0
	tst.w %d1
	jbne .L3
	moveq.l #80,%d0
.L3:
	move.w %d0,xpos
	moveq.l #64,%d4
	tst.w %d1
	jbne .L5
	moveq.l #50,%d4
.L5:
	move.w %d4,ypos
	[u]move.w xpos,%d0[/u]
	[u]move.w %d0,%d1[/u]
	lsl.w #7,%d1
	move.w %d1,x_pcos
	move.w %d4,%d1
	lsl.w #7,%d1
	move.w %d1,y_psin
	lea Tbl_cos,%a4
	move.b Tbl_cos+1,%d1
	ext.w %d1
	move.w %d1,pcos
	move.b Tbl_cos+65,%d2
	ext.w %d2
	move.w %d2,psin
	moveq.l #1,%d3
	move.l __L_plane,%a1
	lea ball_sprite,%a0
	moveq.l #8,%d2
	move.w %d4,%d1
	jbsr Sprite8
	jbra .L6
	.even
.L32:
	lea Sprite8,%a3
	clr.w %d3
	move.l __L_plane,%a1
	lea ball_sprite,%a0
	moveq.l #8,%d2
	move.w ypos,%d1
	[u]move.w xpos,%d0[/u]
	jbsr (%a3)
	move.w x_pcos,%d0
	add.w pcos,%d0
	move.w %d0,x_pcos
	move.w y_psin,%d1
	add.w psin,%d1
	move.w %d1,y_psin
	lsr.w #7,%d0
	move.w %d0,xpos
	lsr.w #7,%d1
	move.w %d1,ypos
	moveq.l #-2,%d0
	jbsr (%a2)
	tst.w __calculator
	jbeq .L14
	and.b #-128,%d0
	jbne .L15
	jbra .L13
	.even
.L14:
	and.w #4,%d0
	jbeq .L13
.L15:
	subq.w #4,%d5
.L13:
	moveq.l #-2,%d0
	jbsr (%a2)
	move.w __calculator,%d2
	jbeq .L17
	and.w #32,%d0
	jbra .L34
	.even
.L17:
	and.w #1,%d0
.L34:
	tst.w %d0
	jbeq .L16
	addq.w #4,%d5
.L16:
	move.w xpos,%d0
	jbeq .L20
	move.w %d0,%d1
	addq.w #8,%d1
	tst.w %d2
	jbeq .L21
	cmp.w #239,%d1
	jbeq .L20
	jbra .L19
	.even
.L21:
	cmp.w #159,%d1
	jbne .L19
.L20:
	move.w #128,%d1
	sub.w %d5,%d1
	move.w %d1,%d5
.L19:
	move.w ypos,%d1
	jbeq .L24
	move.w %d1,%d2
	addq.w #8,%d2
	tst.w __calculator
	jbeq .L25
	cmp.w #127,%d2
	jbeq .L24
	jbra .L23
	.even
.L25:
	cmp.w #99,%d2
	jbne .L23
.L24:
	move.w #255,%d2
	sub.w %d5,%d2
	move.w %d2,%d5
.L23:
	and.w #255,%d5
	move.w %d5,%a0
	move.b (%a4,%a0.l),%d2
	ext.w %d2
	move.w %d2,pcos
	add.w #64,%d5
	move.b (%a4,%d5.w),%d2
	ext.w %d2
	move.w %d2,psin
	add.w #-64,%d5
	moveq.l #1,%d3
	move.l __L_plane,%a1
	lea ball_sprite,%a0
	moveq.l #8,%d2
	jbsr (%a3)
	move.l 200.w,%a0
	move.w #1,-(%sp)
	move.w ypos,%d0
	addq.w #4,%d0
	move.w %d0,-(%sp)
	move.w xpos,%d1
	addq.w #4,%d1
	move.w %d1,-(%sp)
	move.l 1696(%a0),%a0
	jbsr (%a0)
	addq.l #6,%sp
	move.w #4999,%d0
	jbra .L27
	.even
.L31:
	subq.w #1,%d0
.L27:
	tst.w %d0
	jbge .L31
.L6:
	move.w #-257,%d0
	tst.w __calculator
	jbne .L10
	moveq.l #-65,%d0
.L10:
	lea _rowread,%a2
	jbsr (%a2)
	tst.w __calculator
	jbeq .L11
	and.w #64,%d0
	jbra .L33
	.even
.L11:
	and.w #1,%d0
.L33:
	tst.w %d0
	jbeq .L32
	jbsr GrayOff
	move.l OldInt5,262260
	move.l OldInt1,262244
	movm.l -24(%a6),#0x1c38
	unlk %a6
	rts

Or un transfert registre->registre est plus rapide qu'un transfert mémoire->registre, et est codé sur moins d'octets.

Oui bien sûr mais ne peut utiliser ce transfert c'est un peu bête.

Note : c'est la première fois que je vois de l'Asm 68k ... c'est tout bidon ! Euh, oui, bon, une fois qu'un connaît déjà l'Assembleur, c'est vrai, je le concede ...

Ouai c'est un bon langage.

Aïe, niveau (dés)optimisation du compilateur c'est encore pire que ce que je croyais ...
Il s'appelle comment, ce compilateur ?

En plus, cette syntaxe Asm fait de la GVM (Gestion de Variables à la MAsm, ou Gestion de Variables M*rdique) ...

Pourrais-tu STP mettre le code C exact à partir duquel tu as obtenu ce listing Asm ?
Je ferai (sans doute demain) des optimisations sur le code Asm, il y a moyen de tailler dans la masse (plus encore lorsque j'aurai compris toutes les instructions Asm et la gestion des registres ... ou lorque j'aurai installé ZGuide ).

Et histoire d'affirmer haut et fort mes convictions : 45m p0w444 ! 17 Ru132 0v3r 012 w3Ur102 !!! (pour ceux qui ne parlent pas le 31337 14n6u463 (eleet language) : Asm powaaa ! It rulez over diz weurldz !!! ).

@++

geogeo> xpos est utilisé dans l'appel à la fonction d'affichage de Sprite.

geogeo> xpos est utilisé dans l'appel à la fonction d'affichage de Sprite.

Ah oui bien sûr, j'avais oublié.

Aïe, niveau (dés)optimisation du compilateur c'est encore pire que ce que je croyais ... Il s'appelle comment, ce compilateur ?

Euh c'est ma faute, il optimise très très bien le compilateur TIGCC.

Pourrais-tu STP mettre le code C exact à partir duquel tu as obtenu ce listing Asm ?

Regarde à la page 2.

Bon j'ai refait la table et y a un pb, il m'est impossible de mettre la valeur 128 dans la table puisque je travail en char donc impossible d'avoir un vrai pi/2...

Essaye de travailler de -127 à 127 alors