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

[grosged]

Oui, je remarque que tu privilégies un bon rapport encombrement/vitesse !..
Alors que je penche plus vers la vitesse

Concernant l'usage d'un 2ème compteur, évidemment ça ralentirait davantage la routine.
A ce propos, j'ai encore une idée d'amélioration : et si on se passait de compteur ?!

En effet, si le programme principal était implanté en mémoire écran, et de sorte qu'arrivés au 1/4 de l'effaçage, les PUSHs "rencontraient/écrasaient notre boucle principale, laquelle serait du genre:

Code: Select all

  ld hl,BigLoop
BigLoop: .fill 100,$d5
       jp (hl)          ; c'est l'instruction de saut la plus rapide (12 states contre 13/8 d'un Djnz)


On n'aurait vraiment plus besoin de compteur, et on pourrait encore grapiller des states

EDIT: Hey mais je sais où doit se trouver le compteur : tout à la fin , juste avant ...

Code: Select all

ld sp,hl
ei
ret

Mais c'est bien sur !!

Donc, la 1ère étape est de constituer l'intérieur de la boucle , la 2ème étant de continuer à boucler x fois

[Lionel Debroux]

Oui, je remarque que tu privilégies un bon rapport encombrement/vitesse !..
Alors que je penche plus vers la vitesse

Le code d'usage général, comme pourrait l'être une version librairie de ta routine, se doit de faire des compromis
Sinon, on arrive à des aberrations d'optimisation vitesse avec un coût en taille et/ou maintenabilité (ici, palette spéciale) très élevé, ou des aberrations d'optimisation taille avec un coût significatif en vitesse.

Ah, j'ai pensé que dans ta recherche de vitesse sans utiliser de code dans l'écran, tu n'es pas allé assez loin
En gardant le même principe que ta deuxième version, il y a au moins cinq façons d'aller plus vite malgré du code plus petit:
16+4+8+8+4+4+16+208*(123*10+13)-5+16*10+4+4 = 258763 T-states, pour (40-16)-3 octets de moins.
16+4+8+8+4+4+16+203*(126*10+13)-5+22*10+4+4 = 258698 T-states, pour (40-22)-6 octets de moins.
16+4+8+8+4+4+16+194*(132*10+13)-5+4+4 = 258661 T-states, pour (40-0)-12 octets de moins (24 octets copiés en trop).
16+4+8+8+4+4+16+183*(140*10+13)-5+4+4 = 258638 T-states, pour (40-0)-20 octets de moins (60 octets copiés en trop).
16+4+8+8+4+4+16+179*(143*10+13)-5+3*10+4+4 = 258368 T-states, pour (40-3)-23 octets de moins.

Concernant l'usage d'un 2ème compteur, évidemment ça ralentirait davantage la routine.

C'est un fait, mais c'est négligeable: pour 256 x 100, une assignation, un test exécuté deux fois, un branch taken et un branch not taken - moins de 100 T-states, donc moins d'un demi pour mille

[grosged]

Excellent !

16+4+8+8+4+4+16+179*(143*10+13)-5+3*10+4+4 = 258368 T-states, pour (40-3)-23 octets de moins.

Superbe, celui-là !!!

EDIT: ...Mais il n'est pas réalisable : 143 PUSHs dans la boucle, alors qu'un DJNZ ne permet que 126 maximum

Sinon...

16+4+8+8+4+4+16+203*(126*10+13)-5+22*10+4+4 = 258698 T-states, pour (40-22)-6 octets de moins.

Par contre, celui-ci est OKAY =D

Ce qui nous donne...

Code: Select all

FastClr:
        ld      de,$555555      ; will write byte 85 (= blue color)
        or      a
        sbc     hl,hl
        ld      b,203
        di
        add     hl,sp           ; saves SP in HL
        ld      sp,vram+76800   ; as a PUSH is decreasing SP, begin at end of 8bpp mode physical screen
ClrLp:  .fill 126,$d5           ;       = 126 * "PUSH DE"
        djnz    ClrLp           ; during 203 times
        .fill 22,$d5            ; 22 * "PUSH DE"
        ld      sp,hl           ; restore SP
        ei

C'est donc la version idéale