I'm not sure how useful it would be to the "world", but in
implementing the "Mixie"/flexible model I edited ExecTrace so that it
kept track of when a instruction entered each stage. This way, when a
instruction executed it would:
#1 be in-order of commit
#2 the stalls between stages could be more a
I actually noticed this a long time ago but just ignored it and worked off
of the sequence numbers. There isn't anything I did where commit cycles
would break things, and actually having the time stamp match when the
print actually happens would help significantly some times. If you're
going al
Ok, so I think I agree completely with Steve. To me, this means that
I'd remove the "when" field from the InstTrace object, and just use
curTick in the print function.
I'll also add a flag called ExecInExecute that will print the data in
execute instead of commit would probably be nice for some c
Funny, I just noticed this the other day myself. The default behavior
should definitely be to print at commit (as we do now) because we want to be
able to generate a program-order list of committed instructions to see what
the CPU is doing functionally, and to compare with simpler models to verify
I like option 3, but there are still a few questions with that. Do you
print when the instruction begins to execute, or when it's completed
execution?
I dislike option 4, although it doesn't have the ordering problem. The
problem is that the user would have to have some sort of separate strea
So, there's a bizarre issue with execution tracing. It uses the
DPRINTF framework somewhat, but not completely. The big problem is
that the information is printed at commit, but the time printed is
when the instruction was fetched. So, if you turn on other trace
flags, the time printed will not
