gnupic: Re: Trace logging in gpsim
Subject:
Trace logging in gpsim
From:
Scott Dattalo ####@####.####
Date:
12 Sep 2000 22:06:31 -0000
Message-Id: <Pine.LNX.4.21.0009121710410.4975-100000@tempest2.blackhat.net>
Last night I got the first portion of trace logging finally implemented. It's a
good news/bad news result. First, the good news - it works! Bad news - I don't
on stock in any disk drive manufacturing companies.
How it works:
gpsim maintains an internal circular buffer for holding all trace events. A
trace event is anything like a register read/write, cycle counter increment,
opcode execution, skipped instructions, etc. Each of these events is efficiently
encoded into a 32 bit integer and copied to the circular buffer.
For trace logging, the internal trace buffer is periodically written to disk.
I did a couple of experiments. In the first I wrote the trace buffer 32 integers
out in ASCII. In other words, each 32 bit value took 9 bytes in the trace log
file (8 for the 8 nibbles and 1 for the \n). This slowed the simulation down
dramatically. In fact, after 10 seconds of running gpsim would did not even
break the 1-million cycle barrier. OTOH, the log file was 27Meg! I ran this
through bzip2 and 30 seconds later compressed it to 840k.
The second experiment consisted of writing the raw trace buffer to the disk. In
other words, the trace buffer was written using fwrite(). There was no ascii
conversion so the result was much faster. In fact, for the first few seconds
there was no noticable delay in the simulation. But once the internal (OS)
memory buffers were exhausted, the simulation slowed dramatically. In fact, once
the simulation stopped it took several seconds to write the buffered data to
disk. I guess in about 5 seconds 72Megs worth of simulation data was
accumulated! That's a lot of data.
--------
So now I have the question: is this really desirable?
I'm inclined to say no. Perhaps a better approach is to significantly increase
the internal trace buffer and provide some kind of IPC interface to gpsim to
obtain access to this data. This sounds like something that can be done with the
module approach.
Another idea is to provide a mechanism of logging specific data. For example,
log only register writes to a particular register. Or perhaps create triggers
that analogous to break points but enable trace logging instead of halting
execution.
Any ideas here?
Scott
