[DCMOTO] Amélioration de la fonction "Trace"

Couvre tous les domaines de l'émulation ou de la virtualisation ainsi que les discussions sur les divers outils associés.

Modérateurs : Papy.G, fneck, Carl

__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par __sam__ »

Daniel a écrit : 15 juin 2021 17:23A noter le cas particulier des branchements relatifs longs : Le nombre de cycles est différent selon que le branchement se fait ou pas. La trace donne les deux cas, alors qu'elle pourrait savoir quelle branche est prise et retenir seulement le nombre de cycles correspondant. Je ne l'ai pas fait pour simplifier, je ne sais pas si c'est acceptable ?
Pour mon cas d'usage où je fusionne les lignes concernant la même instruction il vaut mieux garder le même contenu tout le temps par adresse mémoire, donc 6/5 doit marcher. Par exemple si je coupe à la colonne 46 j'obtiens:

Code : Tout sélectionner

$ cut -c1-46 dcmoto_trace.txt | sort | uniq  -c 
 Compte Addr Hexa       Instruction                Cycles
    152 6323 A4E0       ANDA   ,S+                 6
    152 6325 2713       BEQ    $633A               3
    228 633A 7F982E     CLR    $982E               7
    228 633D 35F6       PULS   A,B,X,Y,U,PC       15
     ../..
     57 64A1 EBE4       ADDB   ,S                  4
     57 64A3 BD646D     JSR    $646D               8
     57 64A6 FD9808     STD    $9808               6
    171 64A9 F6981A     LDB    $981A               5
    171 64AC E128       CMPB   $08,Y               5
    171 64AE 102700BB   LBEQ   $656D               6/5
A la limite si je coupe en colonne 44 je m'arrête au 6, ce qui est "le cas le plus probable" (branche prise lors d'une boucle.) C'est finalement une bonne idée l'alignement à droite sur cette colonne (cf le PULS de l'exemple.) Je ne sais pas trop ce qu'il se passerait si j'avais un 5 ou un 6 variable dans la trace pour cette ligne. Si ca se trouve ca marche quand même et on aura un truc genre:

Code : Tout sélectionner

    171 64A9 F6981A     LDB    $981A               5
    171 64AC E128       CMPB   $08,Y               5
      1 64AE 102700BB   LBEQ   $656D               5
    171 64AE 102700BB   LBEQ   $656D               6
A essayer ?
Toutes les instructions exécutées sont tracées, jusqu'à ce que la taille maxi du fichier soit atteinte ou que le fichier soit fermé par STOP. Quand on sélectionne STOP la trace s'arrête et le fichier est fermé. On peut alors le retrouver dans le répertoire de travail de dcmoto.
Ah ok. Il n'y a donc pas de "liste circulaire" en mémoire avec les N dernières lignes qui serait écrite sur disk quand on stoppe la trace comme je l'imaginais. Cette notion de liste circulaire permettrait d'avoir précisément les N dernières étapes après le phénomène recherché observé.

Là on enregistre donc les premières instructions. Peut-être serait-il intéressant de stopper le débuggeur quand la trace s'arrête. Ainsi on éviterait la frustration de voir un phénomène particulier avec le débuggeur, et de se dire "super j'ai la trace en route, je le retrouverais dedans", pour voir que la trace a été stoppée bien plus tot sans qu'on le sache.

On a le choix de 10Mo à 10Go en multipliant par 10 à chaque fois, soit des 74 565 aux 74 565 404 premières instructions. Ca couvre de 0.3sec à 5min environ. J'ai pas trop d'idée si c'est trop ou pas, mais je me demande si on ne pourrait pas plutôt compter en unité de temps (on a accès au compteur cycle?) plutôt qu'en espace disk: 20ms / 50ms / 100ms / 200ms / 500ms / 1s / 2s / 5s / 10s/ 15s / 30s / 1m / 2m / 5m me semble plus parlant par exemple.
Pour la troisième idée, c'est beaucoup moins simple et le traitement est plus lourd, on va laisser un temps de réflexion avant de tenter l'aventure.
Oui. Perso j'imagine assez une 3e fenêtre avec une image 256x256 où chaque pixel représente un octet de la ram. Ce pixel se colorie dynamiquement en R/G/B suivant le type d'accès (R=lecture, G=écriture, B=execution par exemple). Ils se combinent: un accès RW sur une même adresse donnerait R+G=jaune. Quand on click sur un pixel alors l'adresse et le type d'accès correspondant s'affiche dans la fenêtre. Enfin un bouton permettrait de tout remettre à zero pour refaire une autre cartographie.

C'est clairement un outil à l'usage très restreint qui ne concerne pas grand monde. Cela dit ca doit être un effet très captivant (voire psychédélique) de voir l'image se remplir et évoluer en direct avec le programme en cours d'execution. :shock:
Dernière modification par __sam__ le 15 juin 2021 18:44, modifié 3 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

Merci Daniel pour cette version,

Pour les branchements longs le "/" risque d'interférer au moment de faire des sommes, mais ça ne doit pas être insurmontable.
Cependant si tu trouves une solution je suis preneur (c'est vrai qu'on voit de suite dans la trace si le branchement a été fait (argument du branchement = le PC de la ligne du dessous).
Si vraiment c'est trop complexe a prendre en compte, on peut toujours remplacer par la bonne valeur a posteriori dans le .txt au travers d'une moulinette.

Tout ça me donne envie de bosser sur un front end pour exploiter le fichier (en croisant avec des fichiers de symboles issus de la compilation par exemple) ... mais au vu de mes devs en cours ce ne sera pas de suite ;-(
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

C'est clairement un outil à l'usage très restreint qui ne concerne pas grand monde. Cela dit ca doit être un effet très captivant (voire psychédélique) de voir l'image se remplir et évoluer en direct avec le programme en cours d'execution. :shock:
Pour ce genre d'outils spécifiques (j'ai aussi d'autres idées dans le même style) je me demande si la solution ne serait pas de mettre en place dans DCMOTO un système de mémoire partagée accessible à des applications tierces.

On pourrait donc depuis une application indépendante de DCMOTO, avoir un accès en lecture (seulement) à l'intégralité de la RAM, ROM, des registres processeur, de l'horloge (ou compteur de cycle ?), les adresses en cours de lecture/ecriture ...

Je n'ai jamais mis en place ce système, c'est juste une piste.

Edit: Chacun serait ainsi libre de faire son propre dev spécifique indépendant de DCMOTO.
Dans mon esprit ça me paraissait simple (allocation d'un segment de mémoire partagée en remplaçant malloc par shmat), mais ça doit être plus complexe que ça ...
Dernière modification par Bentoc le 16 juin 2021 06:26, modifié 1 fois.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par __sam__ »

Une notion de plugin, d'api rest ? On est sans doute parti trop loin :)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

Rien n’est trop beau pour dcmoto :roll: :D
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

Bon pour en revenir à la trace je suis tombé sur un cas aux limites :

Code : Tout sélectionner

dcmoto trace
610B 8E96B0     LDX    #$96B0              3     D=FF04 X=96AF Y=C3DD U=4366 S=9FFA DP=60 CC=F8 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
610E 58         ASLB                       2     D=FF04 X=96B0 Y=C3DD U=4366 S=9FFA DP=60 CC=F8 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
610F 3A         ABX                        3     D=FF08 X=96B0 Y=C3DD U=4366 S=9FFA DP=60 CC=F0 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
6110 CE6141     LDU    #$6141              3     D=FF08 X=96B8 Y=C3DD U=4366 S=9FFA DP=60 CC=F0 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
6113 AD94       JSR    [,X]               10     D=FF08 X=96B8 Y=C3DD U=6141 S=9FFA DP=60 CC=F0 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
FFFF CCA6C8     LDD    #$A6C8              3     D=FF08 X=96B8 Y=C3DD U=6141 S=9FF8 DP=60 CC=F0 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
10002 18        ???                       ??     D=A6C8 X=96B8 Y=C3DD U=6141 S=9FF8 DP=60 CC=F8 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
0003 48         ASLA                       2     D=A6C8 X=96B8 Y=C3DD U=6141 S=9FF8 DP=60 CC=40 | Banques: SYST=0 ROM=1 RAM=04 MEMO=0 VIDEO=0
Quand le PC est à $FFFF, (oui c'est mauvais signe ;-)) le PC suivant "dépasse" les 16bits au niveau de l'affichage.
Idem dans l'interface du debugger :
2021-06-16 07_23_54-DCMOTO  - Mise au point (1).png
2021-06-16 07_23_54-DCMOTO - Mise au point (1).png (17.24 Kio) Consulté 6084 fois
Daniel
Messages : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Daniel »

Ce bug du désassembleur doit être aussi vieux que dcmoto (25 ans) et personne ne l'avait encore signalé. J'ai corrigé. Merci !

Avant de publier la dernière version, je voudrais appliquer l'idée de __sam__ : quand la limite de taille est atteinte, au lieu d'ignorer la suite de la trace on continue au début du fichier en écrasant les plus vieilles lignes. Il en résulte un début de trace à une position aléatoire dans le fichier. Je marque la limite par une ligne bien visible.

Je me pose deux questions :
- Est-ce gênant que le début de la trace ne soit pas au début du fichier ?
- Est-ce gênant que le début de la trace ne soit pas au moment où on l'a lancée, mais à une ligne fonction du moment où on l'a arrêtée ?

On pourrait ajouter un paramètre pour choisir entre la perte du début ou la perte de la fin si la limite est atteinte, mais j'ai peur que ça devienne trop compliqué.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par __sam__ »

Daniel a écrit : 16 juin 2021 10:26 Je me pose deux questions :
- Est-ce gênant que le début de la trace ne soit pas au début du fichier ?
- Est-ce gênant que le début de la trace ne soit pas au moment où on l'a lancée, mais à une ligne fonction du moment où on l'a arrêtée ?
Ca peut perturber la lecture par un humain.

Tu peux aussi stopper le débuggeur quand tu arrives à la fin. A la suite l'utilisateur fait "jusqu'au prochain point d'arret" sait que la trace reprends au début en écrasant le reste.

Humm les choix ergonomiques sont compliqués à imaginer hors sol. L'idéal est de faire en sorte que ca marche bien "sans réfléchir" pour toi en pratique, et espérer que du coup ca marche aussi bien pour les autres.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

Tu peux aussi stopper le débuggeur quand tu arrives à la fin. A la suite l'utilisateur fait "jusqu'au prochain point d'arret" sait que la trace reprends au début en écrasant le reste.
ça me plait bien comme idée cet arrêt du debugger sur fin de fichier de trace.

Du coup ça veut dire, qu'une fois arrivé à ce point d'arrêt (log remplie) : si jamais l'utilisateur avait besoin de repartir sur un fichier "vide" (a l'inverse de vouloir une log circulaire), comme le debugger s'est mis en pause, il peut faire "STOP" puis choisir une nouvelle taille de trace et cliquer sur "jusqu'au prochain point d'arrêt".

Pour cette histoire de log circulaire, remettre les lignes dans le bon ordre peut se faire au moment où l'on clique sur "STOP".
(en cas d'arrêt automatique sur fichier plein pas besoin de réordonner, il n'y a plus de lignes "anciennes").
A ce moment là on sait où on en est sur l'écriture fichier et si on n'est pas en fin de fichier, on en produit un nouveau avec les données dans le bon sens.
Daniel
Messages : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Daniel »

Nous avons raison de discuter, ça apporte de bonnes idées.
L'arrêt du debugger quand le fichier est plein est excellent, simple et logique, je l'adopte.
On n'a plus besoin de buffer circulaire, la trace commence au début du fichier et se termine à la fin, tout devient simple et clair.
En mettant le compteur de cycles à zéro au départ de la trace, il peut servir à limiter la taille en secondes et donc remplacer la taille en octets ou en nombre de lignes. Et en prime je peux l'afficher dans chaque ligne de la trace, il n'est plus nécessaire de faire le calcul en post-traitement.

S'il n'y a pas d'objection je retiens cette solution.
Daniel
L'obstacle augmente mon ardeur.
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

De mon coté ça me semble très bien (et toi _sam_ ?).
A propos de pause processeur et en rapport avec la trace :

Quand je coche l'option "arrêt sur instruction invalide" ET que j'ouvre le debugger :

Lors d'une instruction invalide (on peut en forcer une en écrivant $10 suivi de $00 en remplacement de l'instruction à venir) : la boite de dialogue s'ouvre avec le message d'erreur mais le pc et le compteur de cycle tournent toujours derrière.
=> Le processeur n'est pas mis en pause.
=> si je ferme le debugger, le processeur se met bien en pause.

Je ne sais pas si c'est normal ou pas, mais dans le cas ou on a activé la trace ça continue a remplir le fichier, ce n'est pas pratique.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par __sam__ »

@Bentoc tu fais des trucs trop bizarres avec ces menus comme "arrêt sur instruction invalide".. Perso j'avais même oublié que cela existait :)

Pour le compteur de cycle cumulatif, cela ajoutera une étape en plus pour le calcul du temps par instruction (il faut faire la différence entre avant/après). C'est pas dramatique. Par contre faire gaffe aux débordements. Il est sur 32 bits je suppose, et compter des µs, donc après 2147 secondes (35mins) il déborde et passe de >0 à <0. Donc il faut proscrire les enregistrements de plus de 30mins pour être tranquille :D (bon en même temps 30mins ca fait 62Go sur disk à la louche)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17286
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Daniel »

Version de développement 2021.06.17 de dcmoto (à tester) : http://dcmoto.free.fr/emulateur/index.html

- Choix de la taille de la trace : 2, 4, 8 ou 16 secondes.
- La trace et l'exécution s'arrêtent quand la limite est atteinte.
- La trace peut être arrêtée avant la limite en sélectionnant STOP.
- Le nombre de cycles depuis le début de la trace est dans le fichier (à la suite du nombre de cycles de l'instruction).
- Quand la trace est active, toutes les instructions effectuées sont enregistrées quel que soit le mode : pas à pas, subroutine, jusqu'au point d'arrêt.

D'autre part l'exécution "jusqu'au point d'arrêt" s'arrête sur instruction invalide si l'option a été choisie.
Il faut se méfier de la notion d'instruction invalide pour deux raisons :
- Beaucoup d'instructions non documentées ont été programmées et ne sont pas considérées comme invalides
- DCMOTO utilise quelques instructions invalides préfixées par $11 pour détourner des entrées sorties (cassette et disquette en particulier). Elles ne sont pas considérées comme invalides.

Comme toujours les tests effectués sont loin d'être exhaustifs, des bugs résiduels sont possibles.
Daniel
L'obstacle augmente mon ardeur.
Bentoc
Messages : 178
Inscription : 14 sept. 2019 13:35
Localisation : Var - France

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par Bentoc »

Merci Daniel !
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [DCMOTO] Amélioration de la fonction "Trace"

Message par __sam__ »

Bon je joue beaucoup avec la trace en ce moment pour un prochain article. Le fait que le format soit tabulaire est très très bien. J'ai une question. Je viens de découvrir cette trace

Code : Tout sélectionner

F09D B6E7C3     LDA    $E7C3               5      2871730   D=B500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D0 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
F0A0 84DF       ANDA   #$DF                2      2871735   D=B500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D8 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
F0A2 B7E7C3     STA    $E7C3               5      2871737   D=9500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D8 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
F0A5 11FC       ???                       ??      2871742   D=9500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D8 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
F0A7 203C       BRA    $F0E5               3      2871774   D=9500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D8 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
F0E5 B6E7C3     LDA    $E7C3               5      2871777   D=9500 X=0100 Y=0180 U=5D80 S=612D DP=60 CC=D8 | Banques: SYST=1 ROM=0 RAM=02 MEMO=0 VIDEO=1
A quoi correspond le 11FC (???) ? Je vois bien que c'est une instruction inexistante, mais elle prend 32 cycles. C'est énorme. A quoi cela correspond-t-elle ?

Autre chose que j'ai découvert: si le dossier dans lequel DCMOTO tourne est compressé, alors le fait de jouer à un jeu avec la trace allumée est vite pénible car il y a des coupures toutes les secondes environ. Cela est fait par la compression du fichier de trace par windows en tache de fond. Il ne le fait pas à la toute fin mais en cours de route ce qui ralentie la machine et l'émulation dans la foulée. Si on fait la même chose sur un dossier non compressé c'est beaucoup plus fluide.

Enfin, je ne sais pas s'il est possible d'avoir une trace plus longue que 16sec, car toujours dans un jeu ca fait vraiment peu entre 2 arrêts du débuggeur pour mon cas d'usage (que j'expliquerais plus tard.)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Répondre