gnupic: Progress with output logging
Subject:
Progress with output logging
From:
John Sutton ####@####.####
Date:
12 Sep 2001 20:05:59 -0000
Message-Id: <01091220593900.14577@diva.localdomain>
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?
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?
TIA
John
On Mon, 10 Sep 2001, Scott Dattalo wrote:
> On Mon, 10 Sep 2001, John Sutton wrote:
>
> > Thanks for that. After a wasted day trying to build a static version of gwave,
> > I've just upgraded glib and gtk+ from 1.2.9 to 1.2.10 and rebuilt
> > gtk+extra-0.99.16 on top, and all is well! I've got gpsim and gwave running
> > and am now trying to hack gpsim to give me an output log... gpsim is
> > beautifully written but my knowledge of C++ is very meagre, so it's going to be
> > a pretty shameful hack I fear ;-(
>
> John,
>
> Good News!
>
> When you start hacking, you may wish to look at src/trace.cc and
> src/pic-processors.cc. At the end of trace.cc is the code for logging to a
> file. This code has been tested and works, but as I said before it creates
> enormous log files. To enable the functionality there's a gross hack in
> pic-processors.cc that's currently commented out. In the
> pic_processors::pic_processor concstructor are two lines:
>
> //trace_log.switch_cpus(this);
> //trace_log.enable_logging("gpsim.log");
>
> If you uncomment these, then a log file will be opened when a new
> processor is instantiated.
>
> To save time, trace.cc will copy the entire trace buffer to this file
> (about a 1000 or so traces at a time). Look in:
>
> void TraceLog::callback(void) {...}
>
> for the code that does this. Also, the trace buffer is copied using
> "fwrite". As a consquence, the traces are not decode and they're binary
> (not human readable). However, the trace buffer can be parsed and dumped
> into a file by:
>
> int Trace::dump(unsigned int n=0, FILE *out_stream=NULL)
>
> Incidently, this routine also implements a trace filter. Now there are at
> least three problems with this routine that will prevent it from being
> used as is to decode an arbitrary trace buffer. 1) It assumes the trace
> buffer is that which was created when the class was instantiated. 2) It
> calls the gui trace window if the gui is being run. 3) The filter is not
> an input parameter.
>
> If we make the trace filter an input to Trace::dump(), then we can call
> this from within TraceLog::callback() to get a human readable parsed file.
>
>
> Scott
--
***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************
