interrupt, gray, keyboard, et tout le bordel - Page 3

c'est un ROMCall??

yep (mais avec une convention d'appel un peu particuliere, cf doc)

merci, je vais voir ca tout de suite

c'est _du32u32 la romcall??, elle est absolument pas renseignée dans la doc tigcc.
y'a meme pas l'adresse pour l'excuter... Bon, je crois que je vais faire comme j'av prevu:
/100
Vo que je gere les chiffres jusqu''a un million ca me donne un chiffre inferieur a 10000 qui tient dans un word. donc ca devrait le faire.

/1000
et m'arrager en ajoutant les restes

oui si t'as pas besoin de toute la plage de valeurs c'est bon (tu peux meme aller jusqu'a 100 000 000 en divisant par 10000)

Perso pour itoa j'ai réalisé ce type de fonction:
Je sais pas si elle est plus rapide que celle proposée par lionel Debroux.

|=========================================================================
|Func_IntToStr
|-------------------------------------------------------------------------
|Convertie un entier en chaîne de caractères
|-------------------------------------------------------------------------
|input:
|  dc.l %d0 = Entier.
|  dc.l %a0 = Chaîne de caractères de destination.
|
|output:
|  dc.l %a3 = Chaîne de caractères.  
|
|destroy: %a3, %d3
|=========================================================================
_Func_IntToStr_zero:
		move.b    #'0',-(%a3)
		rts
		
Func_IntToStr:
		lea.l     12(%a0),%a3
		clr.b     -(%a3)
		moveq.l   #0,%d7				|Signe négatif
		move.l    %d0,%d1
		jbeq      _Func_IntToStr_zero
		jbge      _Func_IntToStr_next
		moveq.l   #-1,%d7
		neg.l     %d1
_Func_IntToStr_next:
		move.l    %d1,%d3
_Func_IntToStr_loop:
		moveq.l   #10,%d0
		ROM_CALL  _mu32u32
		addi.b    #'0',%d1
		move.b    %d1,-(%a3)
		move.l    %d3,%d1
		moveq.l   #10,%d0
		ROM_CALL  _du32u32
		move.l    %d1,%d3
		jbne      _Func_IntToStr_loop
_Func_IntToStr_end_loop:
		tst.w     %d7
		jbeq      _Func_IntToStr_exit
		move.b    #'-',-(%a3)
_Func_IntToStr_exit:		
		rts

movea.l %a0,%a3 ; lea.l 12(%a3),%a3 => lea.l 12(%a0),%a3

Et il n'y a pas une erreur quand le nombre est nul (il faut mettre a3 au lieu de a0) ?

Et on peut optimiser le test du signe (avec sCC) à mon avis.

Par contre, il faut que la chaine de destination contienne des espaces, et les données seront alignées à droite ; et ta routine détruit aussi d0,d1,d7.

tiens t'as utilise _u32du32
ppour l'appelr, c'est
x/y
x en d0
y en d1
reste en d1
resultat en d0?

nan, y a une fonction pour la division (_dmachin) et une autre pour le modulo (_mmachin), faut faire 2 appels...

et :
- c'est tout sauf fast pour les gros nombres, ca fait 2 appels des fonctions lentes de TI a chaque chiffre, donc a moins que fastitoa soit franchement lent, c vite vu...
- a0 est tout sauf la chaine de destination, c'est plutot un buffer temporaire de 12 caracteres (mais je ne vois marqué ca nulle part dans la spec ), qui sera utilisé pour stocker le résultat

bon je oste ma routine qui marche bien... le nombre esd pas socké en chaine de caractere mais sous la form $FF,$FF,$FF,$01,$02,$00,$05,$09 pour 12059 par exemple, ca limite est de 10million je crois. et j'uilise ma propre police et mes propres routines d'affichage et a peu pres tous les registres utilisés sont effacés je pense

Afficher_Chiffre
 lea	buffer(pc),a0
 move.b	#0,(a0)+
 move.l	#1000,d1
 moveq	#1,d3
 divu.l	d1,d0
 clr.l	d2
 swap	d0
 move.w	d0,d2
 clr.w	d0
 swap	d0
 \loop:
 divu.w	d1,d0
 move.b	d0,(a0)+
 clr.w	d0
 swap	d0
 divu.w	#10,d1
 tst.w	d1
 bne	\loop
 move.w	d2,d0
 moveq	#100,d1
 dbra	d3,\loop
 lea	buffer(pc),a0
 moveq	#6,d1	
 \loop1:
 move.b	#$ff,(a0)+
 tst.b	(a0)
 dbne	d1,\loop1
 rts

Sasume :
movea.l %a0,%a3 ; lea.l 12(%a3),%a3 => lea.l 12(%a0),%a3

Et il n'y a pas une erreur quand le nombre est nul (il faut mettre a3 au lieu de a0) ?

Et on peut optimiser le test du signe (avec sCC) à mon avis.

Par contre, il faut que la chaine de destination contienne des espaces, et les données seront alignées à droite ; et ta routine détruit aussi d0,d1,d7.

En effet corrigé tout ça, pourquoi la chaîne de destination devrait-elle contenir des espaces, c'est inutile tout sera écrasé et de toute façon en sortie on obtient dans %a3 le début de la chaîne.

nan, y a une fonction pour la division (_dmachin) et une autre pour le modulo (_mmachin), faut faire 2 appels...

et :
- c'est tout sauf fast pour les gros nombres, ca fait 2 appels des fonctions lentes de TI a chaque chiffre, donc a moins que fastitoa soit franchement lent, c vite vu... - a0 est tout sauf la chaine de destination, c'est plutot un buffer temporaire de 12 caracteres (mais je ne vois marqué ca nulle part dans la spec ), qui sera utilisé pour stocker le résultat

Normal, il faut spécifier soit même dans %a0 la destination donc soit même un buffer temporaire.

Bizarre j'avais ajouté ça avant de poster , on dirait que c'est pas passé en entier.
"Je sais pas si elle est plus rapide que celle proposée par lionel Debroux. Mais j'en doute fort "

geogeo :
Normal, il faut spécifier soit même dans %a0 la destination donc soit même un buffer temporaire.

Ben c'est pas du tout documenté... On ne peut pas utiliser ta fonction sans avoir lu le code source avant (enfin je me doute bien que c'est pas [trop] genant si la routine est juste pour toi dans un de tes projets, mais le fait d'avoir voulu faire un joli header en ASCII art avec une description et tout et tout peut faire croire que la doc permet d'utiliser la fonction sans lire le code, alors que c'est pas du tout le cas ; c'est un peu le meme probleme que si tu détruisais d4 et que tu ne le rajoutais pas dans la liste des registres détruits)

J'ai encore un probleme, pour choisir un nombre au hasard j'utilise rand de tigcc.a, mais la fonction randomize pour initialiser le hasard est definie en macro et ne peut pas etre utilisèe, ce qui fait que j'ai des nombres au hasard, mais toujours les memes. Vous avez une solution pour randomiser?.. ou sinon, j'ai vu que y'a une fonction basic (ROMCALL) pour faire du random... mais je capte pas comment elle marche c'est push_rand.

Regarde le code de la macro et réécrit la en ASM.

Je me demandais quelque chose, c'est normal que si je vire toutes les options d'optimisation de tigcc, mon progranne prenne 3* plus de place????

Bah... oui.
Tu sais ce qu'"optimiser" veut dire ?

ct juste pour savoir, je savais pas que optimiser ca voulais dire diminuer la taille du prog par 3 ou 4.
Mais tant mieux ^^.

Faut voir le prog aussi

bah en mode "pas optimisé", il utilise pas les registres pour stocker les variables, donc ouais c'est vite vu, si t'as un truc du genre x += y, ca fait "move.w y(a7),d0;add.w d0,x(a7)", i.e. 8 octets au lieu de 2 pour "add.w d0,d1"... et c'est encore pire si tu rajoutes un "if (x!=0)" apres, parce qu'il va s'amuser a aller re-chercher x sur la pile pour tester le résultat, alors qu'il est déja dans les flags...

Ouais, je pense que mon prog est paticuulierement mal programmé ¨_¨

Autre chose, y'a un moyen simple de savoir si on a a faire a une ti89 ou a une 92+/v200?. est ce que la taille de l'ecran est enregistrée qqpart en ram par exemple?

ah merde j'ai pas vu que tu parlais d'un truc fait en assembleur... tu parles des optimisations de l'assembleur ou du linker ?

d l'assembleur je crois

hmm essaye de t'arranger pour que la taille non optimisée soit (presque) la meme que la taille optimisée, ca te fera certainement découvrir plein d'optimisations que t'aurais pas forcément découvertes autrement (par exemple utiliser moveq a la place de move.l, ou utiliser les adresses pc-relatives au maximum et n'utiliser les adresses absolues qu'en cas de stricte nécessité)

jibax :
Autre chose, y'a un moyen simple de savoir si on a a faire a une ti89 ou a une 92+/v200?. est ce que la taille de l'ecran est enregistrée qqpart en ram par exemple?

> Autre chose, y'a un moyen simple de savoir si on a a faire a une ti89 ou a une 92+/v200? Est ce que la taille de l'ecran est enregistrée qqpart en ram par exemple?
Oui (les programmes de TICT sont pour la plupart faits comme ça - même en incompatible on-calc, il faut détecter qu'on n'a pas affaire au mauvais modèle), oui (ScrRect il me semble).

Variable CALCULATOR (doit etre dispo en _nostub aussi).

En C, oui. En ASM, pas directement, il me semble. Regarder les sources de TIGCCLIB.

Si, je crois. Mais il faut un xdef je ne sais plus quoi en plus je crois.

Accéder à la variable est une chose, mais il faut qu'elle ait été initialisée: il faut donc aussi demander le code d'initialisation (dont je ne sais plus le nom non plus - RTM)...