Insertion du code de printf - Page 1

yop,

Je voudrais insérer le code de ptintf de tigcc.a, directement dans mon source, après un label, puisque je l'appellerai via un jsr
En fait, je voudrais juste dans un fichier :
PrintfTIGCC:
<le code de printf>

J'ai l'impression que je ne peux y accéder que via un bsr, ce qui m'obligerait à écrire :
PrintfTIGCC:
bsr Printf
<le code de printf devrait être ici, si c'est bien optimisé, vu que c'est le seul appel>

Ya un moyen ?

Pourquoi pas appeler directement printf avec un jsr? Parce qu'il y a des bidouilles d'exportations dans ton truc?

Sinon, le plus efficace est:
PrintfTIGCC: jbra printf

Si tu as toutes les optimisations du linker activées, il va essayer de réordonner les sections pour mettre cette section juste avant printf, puis virer le jbra entièrement.

Et je te signale que PrintfTIGCC: bsr printf est incorrect, il manque le rts et tu devrais faire l'optimisation tailcall de toute façon.

Oui en effet, faut pas un bsr. Sinon, je retiens l'adresse de printf en mémoire, donc celle de printf (TIGCC) ou celle de pedrom:rintf. c'est pour ça que j'ai besoin de son adresse, et non de l'exécuter directement.[nosmile]

lea printf,%a0
Où est le problème?

Le problème n'est pas là. Le problème est que j'aurais voulu écrire un source à part, comprenant juste un équivalent de "include le-code-de-printf". En fait, je vais devoir écrire "bra printf" dans un fichier seul. Vu que ce sera le seul appel, j'espère que le code de printf sera directement à la suite et que le bra sera dégagé. J'enregistrerai l'adresse comme tu le dis, avec un simple lea. Je ferai des jsr en temps voulu dans le programme.

Folco (./5) :
Le problème n'est pas là. Le problème est que j'aurais voulu écrire un source à part, comprenant juste un équivalent de "include le-code-de-printf".

Mais je ne comprends toujours pas l'intérêt. printf est déjà une source à part. Il suffit de référencer directement printf plutôt que ton label.

Euh... mais ya pas de problème jttk J'oubliais que le compilo me foutrait le code de printf où ça l'amuse
Question : ya du smc/des variables/relogements dans printf ? Ou est-ce exécutable en flash ?

En fait, je voudrais aussi pouvoir mettre éventuellement le code de printf dans un exécutable ne contenant que ça (une lib). Je ferai donc juste un bra printf dans un source à part.

Autre question, spéciale PpHd. Si dans mon pack archive que je mance sous PedroM, j'ai une lib qui s'appelle pedrom, un LibsBegin sur pedrom va faire quoi ? Me renvoyer le descripteur de la lib built-in ou celui de la lib du pack ? Et si j'utilise directement pedrom:rintf, ça ira chercher celui de la lib du pack archive même sous PedroM ?
J'aimerais que ça puisse être la lib du pack, j'aurais ainsi le même code d'ouverture pour pedrom et ams

Folco (./7) :
Autre question, spéciale PpHd. Si dans mon pack archive que je mance sous PedroM, j'ai une lib qui s'appelle pedrom, un LibsBegin sur pedrom va faire quoi ?

Prendre la lib built-in

Folco (./7) :
Me renvoyer le descripteur de la lib built-in ou celui de la lib du pack ?

Prendre la lib built-in

Folco (./7) :
Et si j'utilise directement pedrom:rintf, ça ira chercher celui de la lib du pack archive même sous PedroM ?

Non

Merci !

Bon ben parfait en fait. Je vais mettre le printf de TIGCCLIB dans une dll à part dans le pack archive, le code d'ouverture sera identique sous AMS et PedroM, sauf que sous PedroM, j'aurais le bon printf.

Au fait, Kevin, la doc de TIGCCLIB ne précise pas comment se comporte printf au premier appel, sous AMS. Que se passe-t-il ? C'est affiché sur l'écran, directement ? Faut le nettoyer avant ? Il faut initialiser les coordonnées de départ de la première chaine ? Il y a moyen de manipuler ces coordonnées via des romcalls ?

> C'est affiché sur l'écran, directement ?
Oui.
> Faut le nettoyer avant ?
Non, ce n'est pas nécessaire.
> Il faut initialiser les coordonnées de départ de la première chaine ?
Pas vraiment nécessaire: ça commence en haut à gauche, à quelques pixels du bord.
> Il y a moyen de manipuler ces coordonnées via des romcalls ?
Je dirais: "essaie"

Ah ?

Je me demandais si les fonctions de manipulations du "point de dessin" interragissaient avec printf.

oui MoveTo devrait fonctionner je crois.

Je crois aussi, mais je n'en suis plus sûr.

Ah voilà, c'est ce que je me demandais aussi, merci bien.

Folco (./7) :
Question : ya du smc/des variables/relogements dans printf ? Ou est-ce exécutable en flash ?

En général le code de TIGCCLIB peut contenir des relogements et même si ce n'est pas le cas actuellement pour une fonction, ça peut changer à tout moment pour une raison ou pour une autre. Quant au comportement actuel: tu as les sources, tu peux aller vérifier.

Folco (./9) :
Bon ben parfait en fait. Je vais mettre le printf de TIGCCLIB dans une dll à part dans le pack archive, le code d'ouverture sera identique sous AMS et PedroM, sauf que sous PedroM, j'aurais le bon printf.

LOL, la fake lib pedrom.

Folco (./10) :
Au fait, Kevin, la doc de TIGCCLIB ne précise pas comment se comporte printf au premier appel, sous AMS. Que se passe-t-il ? C'est affiché sur l'écran, directement ? Faut le nettoyer avant ? Il faut initialiser les coordonnées de départ de la première chaine ? Il y a moyen de manipuler ces coordonnées via des romcalls ?

C'est affiché à la position actuelle. Sa valeur initiale n'est pas définie, ça dépend du système d'exploitation. AMS la met à (0,0) par défaut, mais si par exemple tu lances le programme plusieurs fois de suite, la sortie du prochain appel s'inscrira à la suite de celle du premier appel (mais ce n'est pas un comportement documenté non plus). Le mieux est d'explicitement régler une position avec MoveTo, ou d'utiliser clrscr qui inclut un MoveTo(0,0);. Pour récupérer la position actuelle, il faut utiliser SaveScrState, il n'y a pas de fonction pour avoir juste la position du curseur.

Quant à ta question "Faut le nettoyer avant ?", bah, si tu ne le fais pas, ça va t'écrire par dessus ce qu'il y a déjà, ce qui est plutôt moche.

Kevin Kofler (./16) :
En général le code de TIGCCLIB peut contenir des relogements et même si ce n'est pas le cas actuellement pour une fonction, ça peut changer à tout moment pour une raison ou pour une autre.

Parfait. Si rien n'est garanti, alors j'éxécuterai ce code en RAM. Même si c'est bon maintenant, ça opurrait partir en kooye plus tard.

Kevin Kofler (./16) :
LOL, la fake lib pedrom.

Carrément J'y pensais depuis longtemps, mais j'avais pas à l'employer. Maintenant j'ai une bonne excuse pour faire le con. Heureusement, pedrom::printf n'est que pedrom@0004 et non 0042 ^^

Et merci pour le reste des infos techniques.

Bon, avec --optimize-code et --cut-ranges, ya plus de relogement, et la lib fait ~300 octets. J'aurais pensé bien plus...

printf est un assez petit code dans les programmes utilisateur, parce que le gros du code de la famille *printf (c'est vcbprintf) est dans AMS.
Voir aussi la faible taille de ROM_CALL_479 "link_printf", qui pousse quelque chose à travers le link port, si la valeur de ROM_CALL_47A (byte) le permet.

Ok. J'ai pas regardé le code de printf (bcp de boulot en ce moment), mais si ça tombe ça ne fait qu'afficher le résultat de sprintf(mêmes arguments). Si non, tant mieux que ce soit si petit.

mais si ça tombe ça ne fait qu'afficher le résultat de sprintf(mêmes arguments)

Non, mais printf utilise sprintf pour trouver l'adresse de vcbprintf:
[code].xdef printf

.text
printf:
movea.l 0xC8,a0
movea.l (a0,0x14C),a0 /* vcbprintf */
lea (a0,32),a0
movea.w (a0),a1
pea (sp,8)
move.l (sp,8),-(sp)
clr.l -(sp)
pea fputchar
jsr (a0.l,a1)
lea (sp,16),sp
rts[/code]

fputchar est une fonction plus grosse:
[code].xdef fputchar

.text
fputchar:
link.w a6,#-20
movem.l d3-d7/a2-a5,-(sp)
clr.w d6
move.b (a6,9),d6
move.l 0xC8,a5
move.l (a5,1592),a0 /* FontGetSys */
jsr (a0)
ext.w d0 /* Yes, I know we technically shouldn't sign-extend an
unsigned char, but it is always positive anyway. */
move.w d0,d4
lsl.w #1,d4
addq.w #6,d4
move.l (a5,188),a3 /* ScrRect */
pea (a6,-18)
move.l (a5,1664),a0 /* SaveScrState */
jsr (a0)
move.w (a6,-8),d5
move.w (a6,-6),d3
move.w d6,-(sp)
move.l (a5,1600),a0 /* FontCharWidth */
jsr (a0)
move.w d0,d7
cmp.b #10,d6
jbeq .L__fputchar_1
move.w d5,d0
add.w d7,d0
clr.w d1
move.b (a3,2),d1
cmp.w d0,d1
jbge .L__fputchar_2
.L__fputchar_1:
clr.w d5
add.w d4,d3
.L__fputchar_2:
move.w d3,d0
add.w d4,d0
clr.w d1
move.b (a3,3),d1
cmp.w d0,d1
jbge .L__fputchar_3
clr.w (sp)
move.w d4,-(sp)
move.l a3,-(sp)
move.l a3,-(sp)
move.l (a5,1580),a0 /* ScrRectScroll */
jsr (a0)
sub.w d4,d3
.L__fputchar_3:
move.w #4,(sp)
move.w d6,-(sp)
move.w d3,-(sp)
move.w d5,-(sp)
cmp.b #10,d6
jbeq .L__fputchar_4
move.l (a5,1680),a0 /* DrawChar */
jsr (a0)
add.w d7,(sp)
.L__fputchar_4:
move.l (a5,1652),a0 /* MoveTo */
jsr (a0)
move.w d6,d0
movm.l -56(a6),d3-d7/a2-a5
unlk a6
rts[/code]

(d'ailleurs, c'est un peu dommage que vcbprintf fonctionne comme ça: à chaque caractère, fputchar entier est appelé, ce qui fait que plusieurs ROM_CALLs qui gardent le même effet et la même valeur pendant toutes les exécutions consécutives du callback - tant qu'on fait, sur cette plate-forme, de la programmation single-thread sans exécutions bizarres dans les handlers d'interruption - sont appelés plusieurs fois, alors qu'ils pourraient ne l'être qu'une seule fois )

hmmm merci, je sens d'ici la fonction super rapide

, surtout sur AMS. Sur PedroM, ScrRectScroll et DrawChar sont beaucoup plus rapides.

Lionel Debroux (./21) :


(d'ailleurs, c'est un peu dommage que vcbprintf fonctionne comme ça: à chaque caractère, fputchar entier est appelé, ce qui fait que plusieurs ROM_CALLs qui gardent le même effet et la même valeur pendant toutes les exécutions consécutives du callback - tant qu'on fait, sur cette plate-forme, de la programmation single-thread sans exécutions bizarres dans les handlers d'interruption - sont appelés plusieurs fois, alors qu'ils pourraient ne l'être qu'une seule fois )

J'ai pas tout compris.

Puis le code de la fonction est pas optimal, je sens que je vais réécrire ça un jour où l'autre ^^

./24: sur cette plate-forme et cet OS mono-tâche, la police courante du système ne changera pas d'un appel de fputchar à l'autre, au sein d'une même exécution de printf. L'appel à FontGetSys (et FontCharWidth, si la police système courante est une police de largeur fixe) est redondant.

Sur AMS, on peut rendre printf beaucoup plus rapide en utilisant des routines de la classe faststr et memmove+memset pour réimplémenter fputchar, mais ça coûte assez cher en place dans le programme utilisateur... le prix de devoir refaire les fonctions mal faites par TI !
Sur PedroM, printf est built-in et implémentée comme il faut.

C'est optimisé taille, pas vitesse. Et puis DrawStr appelle aussi DrawChar en boucle.

Han puis ya des hacks, cette fonction casserait si DrawChar modifiait ses arguments sur la pile par exemple. Pour le coup ça c'est pas beau du tout.