Liste des instructions [eZ80] + temps d'exécution !

My calculator programs · by **Adriweb** » 30 Mar 2016, 21:10

Tu peux toujours faire des tables séparées pour les "catégories" d'instructions, et mêmes avec distinctions pour les jumps avec/sans la condition de remplie

J'ai amélioré un poil la page du wiki, mais du coup pour le contenu, je te laisse éditer

→ **MyCalcs** profile · by **TheMachine02** » 30 Mar 2016, 21:14

Merci pour les petits tests

Je crois que j'ai compris à moitié ce qu'il se passe :
en fait, la RAM ne peut fournir une réponse tout les 4 TStates. Le fetch ne peut fonctionner que tout les 4 TStates.
Du coup, par exmple pour add hl,de , en partant d'un fetch vide :

FETCH - 1 TState
maintenant la RAM ne peut plus répondre que dans 3 TStates
DECODE - 1TState (à vérifier cependant)
EXECUTE - 1 TState
Et là, le processeur est bloqué : le fetch requis est bloqué par la RAM, et ne recevra de réponse que dans 1TState
Total : 4TStates
Du coup, pour mlt :

FETCH - 1 TStates, réponse RAM dans 3TStates
*wait 3 TStates*
F&D - 1TStates réponse dans 3TStates
DECODE : 1TState
EXECUTE : 6TStates
->12TStates. Par contre, la RAM devrais pouvoir répondre à un fetch pendant l'execute de la mlt... je réfléchirais à ça demain

→ **MyCalcs** profile · by **grosged** » 01 Apr 2016, 23:47

Bon! J'ai revu mon programme (maintenant baptisé EZ80MES ) afin que le temps d'éxecution soit maintenant une valeur 24bits (et non 8bits, trop limité)
J'ai aussi évité l'emploi de push / pop , et opté pour un passage en registres ' lors de l'éxecution de ce que l'on désire mesurer.
J'ai également inclus la "tare" directement dans l'initialisation du compteur.

EZ80MES:

Code: Select all: .nolist #include "ti84pce.inc" .list .org userMem-2 .db tExtTok,tAsm84CeCmp .assume ADL=1 di ; bloque les interruptions ld (sauv_iy+2),iy ; préserve iy exx ; ainsi que les registres ld (sauv_bc+1),bc ; bc' ld (sauv_de+1),de ; de' ld (sauv_hl+1),hl ; hl' exx ; car on permutera vers ces registres' au coeur du test ld hl,$f20030 ; initialise le timer1 ld a,(hl) ; en prenant le soin and %11000000 ; de ne pas déranger ld (hl),a ; les timers 2 et 3 inc l set 1,(hl) ; On veut 1 chrono (et pas un compte-à-rebours) ld bc,1000 ; On va tester 1000x la même chose L00p: ld de,-145 ; remet à -145 le compteur (valeur 32bits) ld hl,$f20000 ; histoire d'avoir comme résultat 0 ld (hl),de ; lorsque rien n'est à mesurer ld l,3 ; (c'est une tare!) ld (hl),$ff ld l,$30 timer_on: set 0,(hl) ; lance le chrono exx ; bascule en registres ' (pour préserver bc, de & hl) ld (sauv_sp+1),sp ; sauvegarde l'état de la pile SP ld ix,EnRam ld iy,EnRam ld hl,EnRam ld de,EnRam ld bc,30 ld a,5 ;-------------------------- Placer ici ce que l'on veut mesurer cpir ;------------------------------- exx ; revient vers l'utilisation de bc, de & hl timer_stop: res 0,(hl) ; on stoppe le chrono sauv_sp: ld sp,0 ; rétabli l'état de la pile ld l,h ; lit le compteur ld de,(hl) ; et le compare ld hl,(resultat) ; au meilleur des scores sbc hl,de ; précédents... jr c,pass ; C'est plus bas? ld (resultat),de ; Alors on actualise pass: dec bc ; sinon on décremente ld a,b ; le compteur de boucle or c ; Pas encore à 0 ?... jr nz,L00p ; Alors on boucle! exx ; restaure sauv_bc: ld bc,0 ; les valeurs initiales sauv_de: ld de,0 ; stockées dans bc' , de' , & hl' sauv_hl: ld hl,0 exx sauv_iy: ld iy,0 ; restaure iy ld hl,(resultat) ; affiche le résultat retenu jp _DispHL ;------------------------------------ Sprog: ret ; pour tester les CALL... resultat: .db $ff,$ff,$ff ; contient le résultat EnRam: .db 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16

Il est enfin possible de mesurer le temps d'éxecution d'un LDIR !
Par exemple, un LDIR opérant un transfert depuis la ram vers la ram, avec bc=30
nous donne comme résultat 218 = 8+7*30

En ce qui concerne CPIR, j'en arrive à la conclusion suivante:
Temps d'un CPIR = 7+(nb de comparaison avant de trouver)*6

→ **MyCalcs** profile · by **TheMachine02** » 03 Apr 2016, 18:46

Pourrais-tu essayer de timer du code exécuté entre l'adresse $E30800 et $E30BFC ? (C'est censé être l'image en RAM du curseur de l'écran, 2 wait states R / 1 wait state W)
Cette adresse pourrait être intéressante pour les codes sensibles niveau vitesse (et en plus elle fait ~1020 octets)

My calculator programs · by **Adriweb** » 03 Apr 2016, 21:51

Ouai, calc84 utilise cette zone de 1024 octets dans son émulateur Gameboy, justement pour sa rapidité.

→ **MyCalcs** profile · by **grosged** » 04 Apr 2016, 16:20

...Absolument !!!

Je viens de tester quelques instructions (sans adressage) , lancées tout d'abord en Ram, puis en $e30800 :

Code: Select all: ld bc,$123456 ; 16 / 12 add a,a ; 4 / 3 nop ; 4 / 3 ret ; 21 / 19

Ensuite, j'ai testé l'instruction ld a,(bc) avec bc pointant sur la Vram , et sur $e30800...
Et j'ai mesuré ces 2 instructions exécutées aussi bien en Ram qu'en adresse $e30800

Voici les résultats:

Code: Select all: ;ce code exécuté en Ram: ld bc,$d40000 ; 16 ld a,(bc) ; 8 ld bc,$e30800 ; 16 ld a,(bc) ; 7 ;ce même code exécuté en $e30800: ld bc,$d40000 ; 12 ld a,(bc) ; 7 ld bc,$e30800 ; 12 ld a,(bc) ; 6

Très intéressant !!!

En plus, cette zone d'1 Ko résiste au reset !!!

EDIT:

Je me suis aventuré dans la zone mémoire d'accès ultra-rapide : $e00000-$e20000 ! ! (wait-states = 1 que ce soit en écriture ou lecture)
He bien, j'ai fini par trouver des mini-zones exploitables dans la zone $e00000 (laquelle est, en fait, constituée de 256 octets reproduits à l'identique pendant 256 fois)
ça sera dur d'y mettre du code!.. Bien que ces zéro aux alentours ne soient que des NOP, après tout!..Mais pour y stocker des données, c'est cool!

cf. Epharius

$e0xx09 :

$e0xx0a : on peut y écrire une valeur de 0 à 15

$e0xx0b - $e0xx0f : 5 octets disponibles

$e0xx11 :

$e0xx12 : on peut y écrire une valeur de 0 à 15

$e0xx13 - $e0xx17 : 5 octets disponibles

Intéressant, non ?!

→ **MyCalcs** profile · by **MateoConLechuga** » 25 Apr 2016, 17:04

I noticed above that you say you measure 256 times and take the lowest time because the CPU timer sync is not aligned. This is slightly incorrect; you are noticing the variable times because of the DMA access by the LCD, which halts execution of the CPU while it is copying to the screen. Just a heads up, nice work on getting the actual values

→ **MyCalcs** profile · by **Epharius** » 25 Apr 2016, 19:48

Oué mais... j'ai eu un bug assez bizarre en voulant écrire dans cette partie de la mémoire. Tu devrais faire un peu attention...

Quand j'ai écris 01 à l'adresse $e0xx08, ma calculatrice est devenue super lente (3 secondes pour effacer l'écran). Il a fallu mettre 0 à cette adresse pour la remettre à la vitesse normale. J'ai d'ailleurs ensuite remarqué que quand c'était un nombre pair, c'était rapide, et impair, c'était lent. Donc ça a bien à voir avec le 8ème bit en partant de la gauche.

Bref, en effet, ce qui m'a fait peur c'est que c'était insensible au RAM CLEARED, mais plus de peur que de mal x)

→ **MyCalcs** profile · by **grosged** » 26 Apr 2016, 07:09

MateoConLechuga wrote:I noticed above that you say you measure 256 times and take the lowest time because the CPU timer sync is not aligned. This is slightly incorrect; you are noticing the variable times because of the DMA access by the LCD, which halts execution of the CPU while it is copying to the screen. Just a heads up, nice work on getting the actual values

Thanks Mateo, we have now the proof DMA access does disrupt execution of the CPU

Epharius wrote:Oué mais... j'ai eu un bug assez bizarre en voulant écrire dans cette partie de la mémoire. Tu devrais faire un peu attention...
Quand j'ai écris 01 à l'adresse $e0xx08, ma calculatrice est devenue super lente (3 secondes pour effacer l'écran). Il a fallu mettre 0 à cette adresse pour la remettre à la vitesse normale. J'ai d'ailleurs ensuite remarqué que quand c'était un nombre pair, c'était rapide, et impair, c'était lent. Donc ça a bien à voir avec le 8ème bit en partant de la gauche.
Bref, en effet, ce qui m'a fait peur c'est que c'était insensible au RAM CLEARED, mais plus de peur que de mal x)

Merci pour l'info, Epharius

, je vais ,de ce pas, rectifier mon post afin de mettre en garde vis-à-vis de l'adresse $e0xx08 , également $e0xx10 (par prudence) . J'ai l'impression que le fait d'altérer le contenu de ces 2 adresses enclencherait comme une fonction (?), un mode (?) . Concernant l'adresse $e0xx08, d'après les symptômes dont tu nous as fait part, Mateo pense que celle-ci pourrait être un miroir de l'adresse $e30008 :
LCDTiming2 0x008 R/W 0x00000000 Clock and Signal Polarity Control Register