encore une chtite question - Page 2

-- double post --

ok pour plus de nop, mais fo que je rentre chez moi (1/2 h de marche) pour vérifier
pareil pour le beq/bne, fo que je vérifie

./29> C'est pas en faisant un programme mal codé que tu vas apprendre. Commence déjà par les bases, à savoir:
- Les accès mémoire sont plus longs que les accès au registres, alors essaye au maximum de stocker tes variables dans des registres, donc:
- si tu as assez peu de variables pour que tout tienne dans des registres fait-le
- si tu as une variable utilisée très souvent que tu peux stocker dans un registre, alors fais-le
- Il y a des instructions andi, subi, c'est pas pour les chiens.
- Les bouts de codes utilisés plusieurs fois tu les mets dans des fonctions.
- La convention sur les ti est que les registres d0-d2/a0-a1 peuvent être déruits sans préavis par une fonction
- Sauvegarde les registres au début de ton programme, ça se fera pas tout seul
- L'instruction clr est faite ppour éviter les move.w #0,...
(partie "optimisations"
- si tu fais deux move.w #imm,-(a7) à la suite, autant utiliser un seul pea
- y'a rien d'autre (enfin, aps grd chose de plus) à dire pr ce prog)

GoldenCrystal
: C'est pas en faisant un programme mal codé que tu vas apprendre.

Et bien moi je pense que si, parceque sinon ça veut dire que tu ne te mets à coder que quand tu est bon, donc en fait tu ne t'y mets jamias.

Pour le reste de tes suggestion, merci bien, je vais voir ça

double post???

au oué, tiens
Comme la redirection marchait pas, j'ai cliqué sur ok, et ça m'a ramené en bas de la page () alors j'ai pas vu mon post...

d'autre aide en perspective?

GoldenCrystal
: - Sauvegarde les registres au début de ton programme, ça se fera pas tout seul

En mode kernel (qu'il utilise malheureusement ), le kernel le fait.

- si tu as assez peu de variables pour que tout tienne dans des registres fait-le - si tu as une variable utilisée très souvent que tu peux stocker dans un registre, alors fais-le

Et si tu n'as pas assez de registres pour tes variables, utilise la pile (variables locales), pas des labels (variables globales).

Et je rajouterai un conseil: http://members.chello.at/gerhard.kofler/kevin/ti89prog/asmnstbf.htm. L'âge des kernels est passé. Et oublie graphlib::fill, ScrRectFill est fait pour ça. Et c'est dans la ROM, donc pas besoin de mettre graphlib sur sa calculatrice.

Kevin Kofler
: * il paraît qu'attendre plus longtemps réduit les effets de "bouncing".

Qu'est-ce que c'est ?

Et comment on sait qu'il faut au minimum 48 cycles ?

nounoun> Beaucoup de fonctions qui sont fournies par les librairies kernel ont leur équivalent dans la ROM, autant utiliser ces équivalents, ça évitera d'avoir à mettre les librairies et le kernel sur la calc de l'utilisateur.

GoldenCrystal
: - Il y a des instructions andi, subi, c'est pas pour les chiens.

Quels sont leurs avantages ?

reste au mode kernel, c'est très bien

Ben si on peut s'en passer sans sacrifice, autant le faire, non ?

- Il y a des instructions andi, subi, c'est pas pour les chiens.

l'assembleur remplace tout seul add.s #val,add par un addi, non ?

Oui, et c'est d'ailleurs dommage, personnellement, je trouve.

Personne ne sait répondre au post ./40

Sasume
:

Kevin Kofler
: * il paraît qu'attendre plus longtemps réduit les effets de "bouncing".

Qu'est-ce que c'est ?

Des touches appuyées 1 fois, mais détectées 2 fois.

Et comment on sait qu'il faut au minimum 48 cycles ?

Parce que les programmes qui utilisaient 10 ou 11 nops étaient bogués ("bouncing", curseur vers le haut pris pour ESC, ...) sur HW2.

nounoun> Beaucoup de fonctions qui sont fournies par les librairies kernel ont leur équivalent dans la ROM, autant utiliser ces équivalents, ça évitera d'avoir à mettre les librairies et le kernel sur la calc de l'utilisateur.

En effet.

Sasume
:

GoldenCrystal
: - Il y a des instructions andi, subi, c'est pas pour les chiens.

Quels sont leurs avantages ?

Aucun. A68k et GNU as les utilisent tout seul.

Flanker :
reste au mode kernel, c'est très bien

Non. (Je n'ai pas envie de dire plus que ça parce que ça va encore finir en bagarre. )

Kevin Kofler
:

Sasume
:

GoldenCrystal
: - Il y a des instructions andi, subi, c'est pas pour les chiens.

Quels sont leurs avantages ?

Aucun. A68k et GNU as les utilisent tout seul.

Oui, mais quels sont les avantages de ori/subi/cmpi par rapport à sub/or/cmp ?

D'ailleurs, 48 cycles, je ne sais pas si c'est assez. Je me souviens vaguement d'histoires de 12 nops qui n'étaient pas assez, et il fallait en fait prendre 18 nops -- enfin ça fait un bout de temps, donc je suis plus trop sûr. A vérifier.

Sasume
:

Kevin Kofler
:

Sasume
:

GoldenCrystal
: - Il y a des instructions andi, subi, c'est pas pour les chiens.

Quels sont leurs avantages ?

Aucun. A68k et GNU as les utilisent tout seul.

Oui, mais quels sont les avantages de ori/subi/cmpi par rapport à sub/or/cmp ?

Tu peux faire subi #x,(a0)+, alors que tu peux pas faire sub[tout court] #x,(a0)+, parce qu'il n'y a que sub dn,<ea> et sub <ea>,dn. Evidemment n'importe quel assembleur "optimise" ça tout seul.

Pollux
: D'ailleurs, 48 cycles, je ne sais pas si c'est assez. Je me souviens vaguement d'histoires de 12 nops qui n'étaient pas assez, et il fallait en fait prendre 18 nops -- enfin ça fait un bout de temps, donc je suis plus trop sûr. A vérifier.

Et pour ne pas prendre de risques, TIGCCLIB attend plus longtemps.
Cela dit, je n'ai jamais eu de problèmes avec mes 12 nops dans XtraKeys.

Mais, comme l'a dit Sasume, pourquoi attendre avec des nops plutôt qu'avec une boucle ?

Parce que tout le monde le faisait à l'époque où j'ai écrit ce code (novembre 2000, je suis d'ailleurs passé de 9 à 12 nops en février 2001).

Bah non, GTools, lui, faisait autre chose (aller chercher le masque suivant) pendant ce temps-là

voici ce que j'ai pondu, l'écran défile, le clavier marche, mais on peut taper dans le noir, ça fait rien pour le moment:

include "tios.h"
include "userlib.h"
include "graphlib.h"
xdef _main
xdef _ti89
;--------------------------------------------------------------------------------
_main:
move.w #77,D6 ;abcisse du vaisseau
move.w #59,D7 ;abcisse du haut du chemin
lea (ship),A6 ;adresse du vaisseau
clr.w D0
clr.w D1
move.w #159,D2
move.w #100,D3
move.w #2,D4
jsr graphlib::fill
move.w #59,D0
move.w #40,D2
move.w #1,D4
jsr graphlib::fill
;--------------------------------------------------------------------------------
loop:
move.w #7,D0 ;nombre aléatoire entre 0 et 6
jsr userlib::random
sub.w #3,D7 ;on enlève 3 à l'abcisse du haut
add.w D0,D7 ;et on rajoute le nombre aléatoire
bsr control ;on controle si on ne sort pas de l'écran

clr.w D0
clr.w D1
move.w #159,D2
move.w #2,D3 ;on trace 2 lignes horizontales noires
jsr graphlib::horiz ;sur le haut de l'écran
move.w #1,D1
jsr graphlib::horiz

move.w D7,D0
clr.w D1
move.w D0,D2
add.w #40,D2
move.w #1,D3 ;on trace les deux lignes horizontales blanches
jsr graphlib::horiz ;du chemin
move.w #1,D1
jsr graphlib::horiz

clr.w D0
clr.w D1
move.w #20,D2
move.w #98,D3
jsr graphlib::scrtomem ;on copie l'écran - les 2 lignes du bas
move.w #2,D1
jsr graphlib::memtoscr ;on le redessine deux crans + bas

move.w #%11111110,D4
bsr keytest
btst.b #3,D3
beq droite
btst.b #1,D3
beq gauche ;test des touches droite et gauche

move.w D6,D0
move.w #93,D1
move.l A6,A0
jsr graphlib:ut_sprite ;on dessine le vaisseau

move.w #%10111111,D4
bsr keytest
btst.b #0,D3
beq fin ;on teste la touche esc

bra loop
;--------------------------------------------------------------------------------
droite:
add.w #2,D6
bra loop ;touche de droite appuyée
;--------------------------------------------------------------------------------
gauche:
sub.w #2,D6
bra loop ;touche de gauche appuyée
;--------------------------------------------------------------------------------
control:
cmp #1,D7 ;on regarde si le chemin ne sort pas,
ble limit_g ;de l'écran
cmp #119,D7
bge limit_d
bra retour
limit_d:
sub.w #4,D7 ;on le ramène vers la gauche
bra retour
limit_g:
add.w #4,D7 ;on le ramène vers la droite
retour:
rts
;--------------------------------------------------------------------------------
keytest: ;on teste le clavier, la ligne
move.w #$700,-(A7) ;à tester doit être dans D4
jsr tios::OSSetSR
move.w D4,$600018
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
move.b $60001b,D3
clr.w (A7)
jsr tios::OSSetSR
lea 2(A7),A7
rts
;--------------------------------------------------------------------------------
fin:
rts
;--------------------------------------------------------------------------------
ship:
dc.w 7,1
dc.b %00111100
dc.b %01111110
dc.b %01111110
dc.b %00111100
dc.b %00111100
dc.b %01111110
dc.b %01111110
;--------------------------------------------------------------------------------
end




vous pouvez me dire si c'est mieux, et ce que je peux faire encore?

subi parce que, si tu regardes le code (celui d'avant) de nounoun, tu vois qu'on pouvait remplaçermove.w #1,D0 add.w D0,abcisseSasume> Je parlais de addi et sseparaddi.w #1,abci(voire même par addq, mais ce n'est pas le problème )

c'est vrai, mais je n'avais pas vu que addi existait, et qu'il était de toute façon remplacé
au fait GoldenCrystal, t'as vu j'y suis arrivé !
Comme quoi ...

C'est vrai que le code est beaucoup mieux qu'avant Mais comme tu utilises à plusieurs reprises deux move.w #imm,-(a7) à la suite, tu pourrais remplacer les paires par des pea, ce qui prendrait moins de place et serait plus rapide(je crois)
EDIT: Et aussi, n'oublie pas de préciser la taille des cmp (.b/.w/.l) si tu veux éviter des erreurs

??????????
je ne fais qu'un move xxx,-(A7), c'est pour la lecture du clavier

enfin, il me semble...

Ah oui, c'est vrai qu'en mode kernel les paramètre se passent souvent par les registres

kernel powaaaaaaaaaaaaaaaaaa

Tiens ça faisait presque longtemps