gnupic: Progress with output logging
Subject:
Re: Progress with output logging
From:
John Sutton ####@####.####
Date:
17 Sep 2001 14:35:02 -0000
Message-Id: <01091715171700.01230@diva.localdomain>
Hi Scott
On Mon, 17 Sep 2001, Scott Dattalo wrote:
> Sorry for the delay.
No problem, we've kept busy...
> On Wed, 12 Sep 2001, John Sutton wrote:
> > 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?
There was no problem here, just a silly bug in our code.
> 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.
Just adding one cycle counter every time you come into the callback works fine.
I'll mail you the patches shortly but first I want to split up our mods into
two parts - fixes to bugs/features in your code which we uncovered in getting
our stuff to work, and which I think you'll want to put into your code base, and
our mods proper which you'll probably want to think twice about because they're
a bit vulgar!
Regards
John
***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************
