----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1987/#review4627 -----------------------------------------------------------
src/cpu/o3/free_list.hh <http://reviews.gem5.org/r/1987/#comment4379> queue is certainly nice for readability here, but i'm wondering (and not saynig to go do this), but if a vector would actually be faster if you treated it like a stack. It's just a bit funny that we typedef the size so we can have a 16 byte index and two 64 byte pointers. src/cpu/o3/free_list.hh <http://reviews.gem5.org/r/1987/#comment4377> const src/cpu/o3/free_list.hh <http://reviews.gem5.org/r/1987/#comment4378> cost - Ali Saidi On Aug. 22, 2013, 12:40 a.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1987/ > ----------------------------------------------------------- > > (Updated Aug. 22, 2013, 12:40 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 9850:65d5069b045e > --------------------------- > cpu/o3: clean up rename map and free list > > Restructured rename map and free list to clean up some > extraneous code and separate out common code that can > be reused across different register classes (int and fp > at this point). Both components now consist of a set > of Simple* objects that are stand-alone rename map & > free list for each class, plus a Unified* object that > presents a unified interface across all register > classes and then redirects accesses to the appropriate > Simple* object as needed. > > Moved free list initialization to PhysRegFile to better > isolate knowledge of physical register index mappings > to that class (and remove the need to pass a number > of parameters to the free list constructor). > > Causes a small change to these stats: > cpu.rename.int_rename_lookups > cpu.rename.fp_rename_lookups > because they are now categorized on a per-operand basis > rather than a per-instruction basis. > That is, an instruction with mixed fp/int/misc operand > types will have each operand categorized independently, > where previously the lookup was categorized based on > the instruction type. > > > Diffs > ----- > > src/cpu/o3/SConscript 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/cpu_policy.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/free_list.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/free_list.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/regfile.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/regfile.cc PRE-CREATION > src/cpu/o3/rename_impl.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/rename_map.hh 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > src/cpu/o3/rename_map.cc 1ddfb0679c7569fb56382ac2187d6de038fd6f28 > > Diff: http://reviews.gem5.org/r/1987/diff/ > > > Testing > ------- > > > Thanks, > > Steve Reinhardt > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
