[ASM] un SetPixel cross-compatible

→ **MyCalcs** profile · by **MMBC** » 02 Dec 2017, 16:54

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

→ **MyCalcs** profile · by **Lionel Debroux** » 02 Dec 2017, 17:05

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.

→ **MyCalcs** profile · by **MMBC** » 02 Dec 2017, 17:14

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

→ **MyCalcs** profile · by **Lionel Debroux** » 02 Dec 2017, 17:17

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

→ **MyCalcs** profile · by **grosged** » 18 Dec 2017, 21:19

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)

→ **MyCalcs** profile · by **Lionel Debroux** » 18 Dec 2017, 22:46

[...] 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.

→ **MyCalcs** profile · by **grosged** » 18 Dec 2017, 23:35

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}