Forum TI-Planet.org

Il y a pas longtemps, voulant faire un programme en assembleur, je me heurte à un problème : ma Nspire rev AA a un écran un peu bizarre : du 240*320 contrairement à du 320*240 sur les rev antérieures à W. Pour pouvoir continuer mon programme sans casser la compatibilité avec les autres Nspires, j'ai fait une routine de setPixel (avec clipping mais possibilité de l'appeler sans clipping) compatible 320*240 et 240*320, et sous la demande de grosged, je la poste ici
La routine en elle même est:

Code: Select all

; arguments : r0 = lcd base, r1 = x, r2 = y, r11 = y
setPixel:
   cmp r1, #0
   bxlt lr
   cmp r1, #320
   bxge lr
   cmp r2, #0
   bxlt lr
   cmp r2, #240
   bxge lr
setPixelNoClip:
   stmfd sp!, {r0,r3,r4}
   ldr r3, =.LCD_T
   ldrb r4, [r3]
   cmp r4, #2
   beq setPixel240x320
   cmp r4, #6
   beq setPixel240x320
setPixel320x240:
   add r0, r0, r1, lsl #1
   add r0, r0, r2, lsl #9
   add r0, r0, r2, lsl #7
   strh r11, [r0]
   b endsetpx
setPixel240x320:
   add r0, r0, r2, lsl #1
   mov r3, #480
   mla r0, r1, r3, r0
   strh r11, [r0]
endsetpx:
   ldmfd sp!, {r0,r3,r4}
   bx lr

(je sais y'a des optis à faire, à faire avec le temps)
Pour pouvoir l'utiliser, il faut définir une "variable" LCD_T quelque part (je la met à la toute fin du code perso ) et appeler cette routine :

Code: Select all

checkLcdType:
   stmfd sp!, {r0,lr}
   bl lcd_type
   ldr r3, =.LCD_T
   strb r0, [r3]
   ldmfd sp!, {r0,pc}

Cette routine vérifie l'écran pour savoir si c'est du 320*240 ou du 240*320 (enfin pas que, ça gère aussi les monochromes et autres écrans chelous qu'il peut y avoir)
Un truc qui serait bien aussi maintenant est d'ajouter la compatibilité monochrome au setPixel
Voilà, maintenant faites en ce que vous voulez

Quelques notes d'optimisation et d'utilisation, pour aller un peu plus loin

* pour les cmp du début de la routine, tu devrais pouvoir utiliser des comparaisons non signées, et ainsi passer de 4 à 2 comparaisons;
* tu devrais utiliser des constantes symboliques pour les bornes de l'écran, et des macros (si elles sont gérées par l'assembleur que tu utilises) pour le calcul de la multiplication par 480. Je n'ai pas fait ça dans ExtGraph pour TI-68k et j'ai vraiment eu tort;
* sauvegarder et restaurer quantité de registres que tu ne détruis pas consomme du temps et d'espace sur la pile;
* je les retrouve bien en lisant le code, mais tu n'as pas documenté les registres utilisés par la routine pour prendre les paramètres (et j'ai l'impression que la convention d'appel que tu as utilisée n'est pas celle du C)
* vu que tu n'utilises endsetpx qu'à un endroit, tu peux déplacer ce label avant le strh, ce qui permettrait de l'enlever de l'autre chemin de code. Pure optimisation taille, sans effet sur la vitesse.
* la vitesse des routines (out of line, donc) de dessin de pixel souffre des branchements aller et retour, ainsi que des vérifications de bornes, qui pourraient être optimisées par un compilateur. C'est pour ça qu'ExtGraph ne vérifie pas les bornes et utilise un ensemble de macros, mais pour proposer l'optimisation maximale (une seule instruction, dans certains cas), leur définition n'est pas très lisible; ça devrait aller mieux sur la plate-forme dont il est question ici.

J'ai edit pour l'utilisation des registres et le stack, a voir plus tard pour modifier le code en lui même
L'assembleur que j'utilise personnellement est nspire-as, mais je ne pense pas que nAssembler supporte les macros ou les defines, par conséquent j'hésite a les ajouter pour les personnes qui utilisent cet assembleur

Comme tu ne les modifies pas, tu n'as même pas besoin de sauvegarder r1, r2 et r11

Personnellement, je préfère ne pas utiliser setpixel en tant que sous-routine : je viens de finir d'écrire ma propre routine de tracé de droite (avec gestion de coordonnées hors-écran "clipping") et appeler setpixel en sous-routine m'enmpêcherait d'optimiser autant.
A propos de cross-compatibilité, étant donné que les modèles monochromes peuvent afficher jusqu'à 32 niveaux de gris (en basculant en 8bpp), je trouve qu'adopter ce mode 8bpp, commun à tous les modèles, serait l'idéal, non?
Il reste toujours à gérer les récentes versions hardware (et leur résolution 240x320) ... (et je ne possède pas ce genre de modèle : ça m'embête un peu pour développer/tester)

[...] appeler setpixel en sous-routine m'empêcherait d'optimiser autant.

Ca serait une grosse pessimisation, en effet. Recalculer à chaque fois est très inefficace, alors qu'on peut garder le pointeur du pixel actuel et l'incrémenter soit de 1, 2, 3, 4 (rarement davantage) octets pour passer au pixel suivant en x, soit de la stride pour passer au pixel suivant en y. C'est encore plus criant en 1 bpp, comme entre autres sur TI-Z80 monochrome et TI-68k.

C'est exactement ce que j'ai fait
J'évite de perdre du temps avec des droites qui ne traverseront jamais l'écran principal : dans ce cas je fais stopper illico!...Autrement, si c'est viable, je fais en sorte de commencer le tracé depuis la gauche vers la droite : j'inclue le tracé pixel par pixel seulement quand le segment atteint la zone visible (c-à-d quand abscisse ET ordonnée enfin >=0) ; enfin le programme stoppe dès que le tracé ressort de la zone (donc pas uniquement si le point d'arrivée est atteint )

Voici le programme-test de ma routine (en mode 16bpp):

Code: Select all

@   arm-linux-gnueabihf-as -aln -mcpu=arm926ej-s -o temp.o draw4.s && arm-linux-gnueabihf-objcopy -O binary temp.o draw4.prg.tns && rm temp.o
@__________________________________________________________________________________________

   .asciz   "PRG"
DEBUT:   push   {r0-r12,lr}

   @bl   CLS

   mov   r0,#0xc0000010
   ldr   r0,[r0]

   mov   r1,#-128   @ démarre avec "Line (-128,0)-(512,0)"
   mov   r2,#0
   mov   r3,#512
   mov   r4,#0
   mov   r11,#0      @ pour l'instant en noir
   
   mov   r5,#1024   @ tout dernier tracé sera "LINE (895,0)-(-1534,1023)
dessin:   bl   LINE
   add   r1,r1,#1
   sub   r3,r3,#2
   add   r4,r4,#1
   add   r11,r3,r5,lsl#3
   subs   r5,r5,#1
   bne   dessin

   bl   PAUSE

   pop   {r0-r12,pc}
@__________________________________________________________________________________________

LINE:   tst   r1,r3      @ les 2 abscisses sont négatives ?.. ("tst r1,r3" opère un "r1 AND r3" )      
   tstpl   r2,r4      @ ou les 2 ordonnées sont négatives ?..
   bxmi   lr      @ Alors retour!
   push   {r0-r12,lr}
   cmp   r1,#320      @ les 2 abscisses >=320 ?..
   cmpge   r3,#320
   popge   {r0-r12,pc}   @ Alors retour!
   mov   r7,#240   
   cmp   r2,r7      @ les 2 ordonnées >=240 ?..
   cmpge   r4,r7
   popge   {r0-r12,pc}   @ Alors retour!
   mov   r8,#1
   subs    r5,r3,r1
   rsbmi   r5,r5,#0   @ il faut que le tracé aille de gauche à droite!
   movmi   r12,r1      @ alors, on va parfois devoir permuter les 2 coordonnées
   movmi   r1,r3
   movmi   r3,r12
   movmi   r12,r2
   movmi   r2,r4
   movmi   r4,r12
   subs   r6,r4,r2
   rsbpl   r6,r6,#0
   movmi   r8,#-1      @ r8=1 si tracé descendant, sinon =-1
   movmi   r7,r8      @ r7=valeur d'ordonnée qui arrive hors-écran (=240 si tracé descendant , sinon =-1)
   add   r9,r6,r5
   b   PXLout
nodraw:   add   r10,r9,r9
   cmp   r10,r6
   addge   r9,r9,r6
   addge   r1,r1,#1
   cmp   r10,r5
   addle   r9,r9,r5
   addle   r2,r2,r8
PXLout:   orrs   r12,r1,r2   @ tant que l'abscisse et/ou l'ordonnée < 0
   bmi   nodraw      @ on ne trace rien!
   mov   r12,#640   @ pré-calcul de l'adresse-écran. (on n'aura plus qu'à y ajouter l'abscisse*2)
   mla   r0,r2,r12,r0   @ r12=640 ou -640 (selon la direction du tracé).
   mul   r12,r8,r12   @ afin d'optimiser, on va travailler directement avec cette adresse-écran ;)
draw:   cmp   r1,#320      @ (ainsi, adresse-écran+/-640 dès que l'ordonnée bouge) abscisse >=320 ?
   cmpcc   r2,r7      @ ou ordonnée qui part hors-écran ?
   popcs   {r0-r12,pc}   @ Alors c'est terminé!
   cmp   r2,#240      @ bien sûr, si l'ordonnée est encore hors-écran...(parfois lors d'1 tracé de bas en haut)
   addlt   r10,r0,r1,lsl#1   @ il faut s'abstenir de tracer...
   strlth   r11,[r10]   @ le moindre pixel.
   cmp   r1,r3
   cmpeq   r2,r4
   popeq   {r0-r12,pc}
   add   r10,r9,r9
   cmp   r10,r6
   addge   r9,r9,r6
   addge   r1,r1,#1
   cmp   r10,r5
   addle   r9,r9,r5
   addle   r2,r2,r8
   addle   r0,r0,r12
   b   draw
@__________________________________________________________________________________________

PAUSE:   push   {r0,lr}
   mov   r0,#0x8000000
L0098:   subs   r0,r0,#1
   bne   L0098
   pop   {r0,pc}
@__________________________________________________________________________________________

CLS:   push   {r0-r2,lr}
   mov   r0,#0xc0000010
   ldr   r0,[r0]
   mov   r1,#76800
   mov   r2,#15
L00b8:   strh   r2,[r0],#2
   subs   r1,r1,#1
   bne   L00b8
   pop   {r0-r2,pc}


Ce qui nous donne ...