Yea, I'm working with Soymayaroop on it.... I'll make sure whatever patches are made get in the tree...
On Thu, Aug 20, 2009 at 4:06 PM, nathan binkert <[email protected]> wrote: > 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 <http://www.csee.usf.edu/%7Esroy> > > _______________________________________________ > > 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 > -- - Korey
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
