[eZ80] FastClr : pour effacer très rapidement l'écran!

→ **MyCalcs** profile · by **Epharius** » 12 Jun 2016, 13:45

Èm'préssionant ! Quand tu repenses au basic qui efface l'écran 10000 fois en plus de 10 minutes, tu te dis que 10000 fois en 51 secondes c'est bien assez x)

→ **MyCalcs** profile · by **TheMachine02** » 12 Jun 2016, 15:55

Adriweb wrote:Mateo se demande si c'est vraiment plus rapide qu'avec les ldir, sur eZ80 (ça serait le cas sans aucun souci sur z80) - parce que le ldir n'aurait pas besoin d'être re-fetché dans la "pipeline".
Qui s'y colle ?

En vrai, je crains que la RAM étant trop lente pour suivre, y'a plus vraiment d'effet du pipeline sur le code ... Mais sinon cette méthode est la plus efficace pour effacer l'écran et c'est cool

→ **MyCalcs** profile · by **Lionel Debroux** » 12 Jun 2016, 19:27

Au fait, grosged: la deuxième routine que tu as postée gagne moins d'un pour mille de vitesse, alors qu'elle est un peu moins d'un tiers plus grosse, ce qui est un très mauvais compromis. C'est "toujours" ainsi quand on va à l'extrême dans une direction ou une autre (et pas qu'en optimisation, d'ailleurs)

Je suggère de chercher, dans la décomposition en facteurs premiers de 320 x 240 x 8 bpp = 76800 (avec un éventuel petit reste), un autre arrangement permettant de réduire la taille de la routine tout en perdant une quantité insignifiante de vitesse. Typiquement, diviser la taille de la routine par 2 pour un ralentissement de quelques pour mille, et diviser la taille par 4 pour un ralentissement de 1-2%, seraient d'excellents compromis, beaucoup plus équilibrés.

Dans le temps, pour le fun, j'avais fait l'exercice sur les TI-68k, justement pour l'effaçage ou la copie d'écran (240 x 128 x 1 bpp = 3840 octets). Le déroulage complet de la boucle de "movem", instruction permettant de lire vers / écrire depuis les registres jusqu'à 64 octets (en pratique, habituellement 52 ou 56 octets de données, selon qu'on utilise sp ou pas), fait évidemment exploser la taille de la routine dans des proportions effrayantes, alors que la vitesse augmente de moins d'1%. Solution extrémiste, résultat décevant conformément aux prévisions (comptage de cycles) - pas de surprise.

→ **MyCalcs** profile · by **Ti64CLi++** » 12 Jun 2016, 19:59

Waouh super.
Franchement, il me semble que 10000 effaçage de l'écran en 51 secondes, cela reste très correct

→ **MyCalcs** profile · by **grosged** » 13 Jun 2016, 14:26

ça trace, hein !!!

Finalement ,bien qu'un tout petit peu moins rapide, c'est donc la 1ère version la plus intéressante

→ **MyCalcs** profile · by **Lionel Debroux** » 13 Jun 2016, 18:31

Oui. Et je pense qu'on pourrait faire encore plus intéressant.

→ **MyCalcs** profile · by **grosged** » 15 Jun 2016, 10:19

En effet, j'ai trouvé "plus intéressant"

...Cependant, moyennant une certaine contrainte...

Hier, j'ai exposé cette idée à PT_, et comme mon cerveau était un peu "hors service" (revenu, naze du boulot!) , il m'a donné un petit coup de main pour la mise en pratique

L'idée est de créer du code tout en effaçant l'écran !!
C'est-à-dire qu'on va PUSHer des PUSHs !!!!
Exemple:

Code: Select all: ld de,$d5d5d5 push de

étant donné que "PUSH DE" est codé $d5, avec DE=$d5d5d5, un "PUSH DE" écrit 3 "PUSH DE" !!!
C'est ça l'astuce , héhé

Dans un premier temps , l'idée était d'implanter en mémoire-écran la routine, de sorte qu'à la fin de cette routine, on bascule directement dans les "PUSH DE" fraîchement écrits. Mais un LDIR long de 6400 "PUSH DE" , ça prends du temps ...Et beaucoup de place !!

Alors le compromis est de faire une boucle, puis d'aller dans les "PUSH DE" créés.
Bien sur , il faudra implanter tout à la fin , (c-à-d juste après le 1er PUSH écrit)...

Code: Select all: ld sp,hl ei ret

...Afin de pouvoir quitter le programme, tout de même !

Et la contrainte, c'est ,bien sur, de ne pouvoir effacer l'écran qu'avec l'octet $d5
(mais bon!..en mode 8bpp, c'est pas un problème puisqu'on peut modifier la palette de 256 couleurs

)

Voici la version finale:

Code: Select all: ld bc,$c9fbf9 ; pour écrire "ld sp,hl \ ei \ ret" ld de,$d5d5d5 ; $d5=code de "push de" or a ; en PUSHant $d5d5d5, on crée du code sbc hl, hl ; (des PUSHs qui créent des PUSHs !!) di add hl, sp ; mémorise SP dans HL ld sp,$D52C03 push bc ld b,52 PushLp: .fill 123,$d5 ; 6400 = 52*123+4 djnz PushLp ; là, on "PUSH DE" 6400 fois ( = 1/4 de l'effaçage écran) push de ; pour ensuite aller dedans!! (car c'est aussi du code!) push de ; (afin de de poursuivre l'effaçage des 3/4 restants de l'écran) push de push de jp $d52C00-(6400*3)

Taille du code = 153 octets !!

16+16+4+8+4+4+16+10+8+(123*10+13)*52-5+10+10+10+10+17+19200*10+4+4+21= 256803 states !!!

Encore mieux, non ?..

My calculator programs · by **Adriweb** » 15 Jun 2016, 11:15

Ben dis donc... on n'arrête pas le progrès

Tu as une estimation du temps que ça prend avec ton chronomètre ?

→ **MyCalcs** profile · by **grosged** » 15 Jun 2016, 11:18

Non, je n'ai pas encore chronométré pour 10 000 effaçages..Vu l'heure j'dois d'abord m'occuper de mon...estomac

Je verrais ça cet après-midi

EDIT : ça y est, j'ai testé le temps d'exécution pour 10 000 effaçages!

Code: Select all: ld a,$27 ld ($e30018),a ld bc,10000 BigLp: push bc call FastClr pop bc dec bc ld a,b or c jp nz,BigLp ld a,$2d ld ($e30018),a ret ;----------------------------------------------------------------------- FastClr: ld bc,$c9fbf9 ; pour écrire "ld sp,hl \ ei \ ret" ld de,$d5d5d5 ; $d5=code de "push de" or a ; en PUSHant $d5d5d5, on crée du code sbc hl, hl ; (des PUSHs qui créent des PUSHs !!) di add hl, sp ; mémorise SP dans HL ld sp,$D52C03 push bc ld b,52 PushLp: .fill 123,$d5 ; 6400 = 52*123+4 djnz PushLp ; là, on "PUSH DE" 6400 fois ( = 1/4 de l'effaçage écran) push de ; pour ensuite aller dedans!! (car c'est aussi du code!) push de ; (afin de de poursuivre l'effaçage des 3/4 restants de l'écran) push de push de jp $d52C00-(6400*3) ;------------------------------------------------------------------------

... ça prends 57 secondes !! (gain d'une petite seconde)

(J'ai même mesuré la version "relogée" en $e30800, hé bien ça n'en vaut pas la peine: 56 secondes ! )

→ **MyCalcs** profile · by **Lionel Debroux** » 15 Jun 2016, 19:37

Hmm. J'aime beaucoup l'idée, parce qu'il fallait penser à cette combine-là... mais franchement, à mon avis, faire des contraintes sur les palettes pour 1% de vitesse en plus ne vaut pas la peine

Pour l'exercice, je vais montrer ce que je voulais dire plus haut:
* on peut utiliser 251 itérations de 102 instructions pour transférer 76806 octets, ce qui prendra 16+4+8+8+4+4+16+251*(102*10+13)-5+4+4=259342 T-states, soit ~1.5 pour mille plus lent que ta première routine, mais 16 octets - plus de 10% - plus petit. Pour moi, 251 itérations de 102 instructions sont donc un bien meilleur compromis que 217 itérations de 118 instructions.

* pour éviter les vilains débordements de tableau, la décomposition en facteurs premiers 2^10 * 3 * 5^2 indique qu'il faudrait faire par exemple 256 itérations de 100 instructions, 400 x 64, 512 x 50 ou 800 x 32. Mais il faudrait ajouter un deuxième compteur, ce qui doit largement être faisable en moins de 18 octets - bref, même 256 x 100 serait quand même une routine plus petite que ton premier jet