gnupic: Progress with output logging
Subject:
Re: Progress with output logging
From:
Scott Dattalo ####@####.####
Date:
17 Sep 2001 13:23:58 -0000
Message-Id: <Pine.LNX.4.33.0109170559270.27376-100000@ruckus.brouhaha.com>
Sorry for the delay.
On Wed, 12 Sep 2001, John Sutton wrote:
> Hi Scott
>
> Well, after two days trawling about in the dark I think we have almost got it!
> However, we have hit a gotcha which is *maybe* related to your "problem no 1"
> below:
>
> "1) It assumes the trace buffer is that which was created when the class was
> instantiated."
>
> Can you explain to me what you mean by this?
What I mean is that there is only one trace buffer. If you wanted to
create a separate one for logging, then you'd have to some how copy the
contents of the "main" one to the "logging" one.
>
> Anyway, the problem we have is as follows. When we call Trace::dump() from
> Trace::callback(), there is no guarantee that a there is a cycle counter trace
> in the trace buffer and so find_cycle() returns a 0, i.e. we have lost the
> instruction count which we need for plotting our output graphs. So we have
> attempted to remedy this by calling
>
> trace.cycle_counter(cpu->cycles.value);
>
> as the first thing in the callback so that (trace_index - 1) is guaranteed to be
> pointing at a cycle counter. This *almost* works. Problem is, occasionally
> the resulting instruction cycle count in our output *decreases* rather than
> increasing monotonically as it should.
>
> It's maybe that we just have a silly bug in there which we haven't yet found,
> but I just thought I'd check with you whether or not our inserting a cycle trace
> into the buffer like this is a *good idea* or completely misguided?
A long time ago, gpsim would log cycle increments into the trace buffer.
At 64bits per increment, and one or two cycles per instruction, and 20
million instructions per second, you could imagine the trace buffer
rapidly filling! So what I did was to encode cycle increments in the
instruction trace. The thing lost was the absolute reference to the cycle
counter, the thing gained was that, well, the trace buffer was smaller
(and the simulation ran faster).
To recover an absolute reference to the cycle counter, it will be
necessary to sprinkle absolute cycle traces in the trace buffer. This is
currently not done. I currently trace the cycle counter only at the
beginning of a step or a run. You're suggestion above looks like a
good way to do the sprinkling.
Could you explain what you mean by " the resulting instruction cycle count
in our output *decreases*"? Do you mean the point at which the trace
buffer is copied to the file?
We may need to sprinkle more cycle counter traces in the buffer. For
example, in the callback, we can increase the callback frequency by two
and log more cycle traces, but only copy the buffer every other time.
Regards,
Scott
