What happened with the FloatRF is that other CPU models accessed the FloatRF only through the main "RegFile" object but didnt instantiate the FloatRF separately. Since the InOrder model wanted to instantiate the FloatRF separately then it needs those accessor functions. Kind of odd that it wasnt there before.
And yea, the other change was unnecessary. I just got paranoid at one point with those TLB request segfaulting. On Fri, Apr 10, 2009 at 2:10 AM, Steve Reinhardt <[email protected]> wrote: > Why all the new methods on FloatRegFile? Are they used only by the > in-order CPU? I'm just surprised they weren't there already. > > Also, is this change below really necessary? > > diff -r 0555121b5c5f -r d4ff65e87a0b src/cpu/inorder/resources/tlb_unit.cc >> --- a/src/cpu/inorder/resources/tlb_unit.cc Wed Apr 08 22:21:30 2009 >> -0700 >> +++ b/src/cpu/inorder/resources/tlb_unit.cc Fri Apr 10 01:04:35 2009 >> -0400 >> @@ -82,7 +83,7 @@ TLBUnit::execute(int slot_idx) >> // After this is working, change this to a reinterpret cast >> // for performance considerations >> TLBUnitRequest* tlb_req = >> dynamic_cast<TLBUnitRequest*>(reqMap[slot_idx]); >> - assert(tlb_req); >> + assert(tlb_req != 0x0); >> >> DynInstPtr inst = tlb_req->inst; >> int tid, seq_num, stage_num; >> > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
