Re: [Gems-users] Relation between SIMICS cycle & GEMS cycle

["Min Xu (Hsu)" <xu@xxxxxxxxxxx>]

On Thu, 30 Mar 2006 Weihang Jiang wrote :
> On 3/30/06, Min Xu (Hsu) <xu@xxxxxxxxxxx> wrote:
> > I see, this makes sense. Can you give an example profiling task
> > that is easy to do in DTrace and harder to do in GEMS?
> 
> I think nothing essential prevents us from gathering all the
> information DTrace can provide inside GEMS. But, DTrace offers more
> than 30,0000 monitoring points in the kernel. And I heard DTrace is
> not intrusive.

You are right. Some tasks are perhaps much easier in DTrace than
in GEMS.

> > This surprises me. Can you point me to the document that describes
> > how interrupt frequency is relying on these registers?
> 
> In UltraSparc III User manual, Section 6.7.4,  Timer State Register,
> it describes something about it. It just affects soft interrupt rate.
> 
> http://www.sun.com/processors/manuals/USIIIv2.pdf

Thanks. I didn't know this before. In simics, however, I suspect
you cannot just modify the registers and expect things will work out.
(e.g., you can change the tick register from 100-simics-time to
200-gems-time when solaris reads the register. Then solaris write
the tick_compare with 200-gems-time + 100-gems-time=300-gems-time.
But simics will interrupt at 300-simics-time, which might be
500-gems-time.) I still think you need to modify the simics cycle
count, which is perhaps used to generate the value in the tick
registers in the first place.