Hi Klaus,
The actual tracer lost a lot of information, especially:
the time, which is important if clock settings are different for the
traced cores.
All information about data handled in the instructions are lost. That
makes the trace a bit useless for me.
You are right, that time is isn't there. But on the other things, I not
agree. Except the time, what means "a lot"? Filename, PC, label address,
instruction processed, SREG value and, if changed, SP value (this wan't
there before!). There is one more not there: register value. Ok!
I'm not sure, maybe I have made something there, I have to look with git
onto repo about this. :-)
Problem, what I can see is, that we get with all (!?) informations a
huge file, which is difficult to handle and not easy to read. I agree
with you, that it's usefull to have this information. So we need a
solution to handle it. Maybe a option to have "full trace" and " short
trace"?
I think, to make a rewrite of it all is a lot of work and not easy to
fit all. Maybe, if you linke to change it: create a working branch, make
there your changes (to not to push all in "master" branch and to get
discussions with other to break "all" :-) and push this work branch to
savannah and announce it. So everybody, who want's can check it and
comment it, if necessary.
About your question in other post:
> Tracing actually only allows a fixed number of instructions to trace. Is
> there someone who needs this "feature". I dislike this because I would
> be able to do traces over night or longer :-)
Yes, one trace file holds at maximum 1000000(!) lines, but it (should!?
Does it?) write subsequent trace files: e.g. trace.txt, trace_2.txt,
trace_3.txt and so one. See code in
SystemConsoleHandler::TraceNextLine(). (avrerror.cpp, line 108) Setting
is on main.cpp, line 296.
cu, Thomas
_______________________________________________
Simulavr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
