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: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 ?
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
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
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é.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.
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.
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.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.
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.