Korey, Will you take responsibility for integrating Soymayaroop's Changes?
Thanks, Nate On Thu, Aug 20, 2009 at 12:49 PM, soumyaroop roy<[email protected]> wrote: > Hello everybody, > > I was able to zero in on a couple of places in 'thread_state.hh' of the > inorder code where the thread id was hardcoded with a '0'. The following > changes makes the 01.hello.2t.smt work correctly in inorder now. > > diff --git a/src/cpu/inorder/thread_state.hh > b/src/cpu/inorder/thread_state.hh > --- a/src/cpu/inorder/thread_state.hh > +++ b/src/cpu/inorder/thread_state.hh > @@ -69,7 +69,7 @@ > > InOrderThreadState(InOrderCPU *_cpu, ThreadID _thread_num, > Process *_process) > - : ThreadState(reinterpret_cast<BaseCPU*>(_cpu), 0/*_thread_num*/, > + : ThreadState(reinterpret_cast<BaseCPU*>(_cpu), _thread_num, > _process), > cpu(_cpu), inSyscall(0), trapPending(0) > { } > @@ -83,7 +83,7 @@ > /** Returns a pointer to the TC of this thread. */ > ThreadContext *getTC() { return tc; } > > - int readTid() { return 0; } > + int readTid() { return threadId(); } > > /** Pointer to the last graduated instruction in the thread */ > //DynInstPtr lastGradInst; > > Although, corresponding to the second change above in O3 (named threadId() > instead of readTid()) returns thread->threadId(). Can someone tell me which > one is the right way of doing it? I could email a patch subsequently. > > regards, > Soumyaroop. > > On 8/19/09, Korey Sewell <[email protected]> wrote: >>> >>> Could you give me any pointers to debug this? >> >> Sure ... Thanks for your interest... >> >> I think the problem is that right now the model is hardcoded for 1 thread >> in some places. The resources for the model are specified in >> "pipeline_traits.cc" and then I believe workloads are registered somewhere >> in "cpu.cc" and/or "*_cpu_builder.cc". >> >> To debug, I would be more interested in what's happening on cycle 0. Are >> the workloads even getting setup correctly? There may be another flag that >> you can turn on (Process?) ... Compare the output you are getting w/out SMT >> in inorder and w/SMT for inorder. Do you see the workload getting setup in >> one of those? If not, I would add my own DPRINTF debug messages to the >> aforementioned files. >> >> Once you've verified the workloads are being loaded, then the next >> question is why aren't the threads being fetched from? Check >> "first_stage.cc" in that case... I would guess the threads arent being added >> to the activeThreads list correctly maybe. >> >> If you are willing to help debug and commit changes, we'd more than >> appreciate it. Personally, I've got my hands full with getting around to O3 >> SMT stuff but help would be much appreciated on inorder. I'm going to dig up >> and send you some of the hardcoded SMT stuff I have for inorder to help you >> along the way as well... >> >> >> >> -- >> - Korey >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > > > -- > Soumyaroop Roy > Ph.D. Candidate > Department of Computer Science and Engineering > University of South Florida, Tampa > http://www.csee.usf.edu/~sroy > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
