> On Feb. 14, 2012, 8:36 p.m., Korey Sewell wrote: > > Ship It! > > Andreas Hansson wrote: > Korey, I also made similar changes to the 9stage pipe, but I haven't been > able to test this configuration. It would be great if you can give that a > spin. > > Is everyone else happy? > >
This is fine. The explicit specification of the inst/data ports in the InOrder model is a line of thinking I agree with. After you commit these sets of changes, the plan on my end is to merge the 9stage-specific files into the regular inorder code. The only way to test it now would be to copy the 9-stage files over the respective inorder files (e.g. 9stage.resource_pool.cc -> resource_pool.cc) but I don't think that is necessary since the 9 stage files haven't been on the regular compile path for awhile. I'm happy with the changes as-is and will merge the 5-stage (default) and 9-stage files together to avoid confusion within the model. - Korey ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1046/#review2149 ----------------------------------------------------------- On Feb. 16, 2012, 10:44 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1046/ > ----------------------------------------------------------- > > (Updated Feb. 16, 2012, 10:44 a.m.) > > > Review request for Default. > > > Description > ------- > > CPU: Round-two unifying instr/data CPU ports across models > > This patch continues the unification of how the different CPU models > create and share their instruction and data ports. Most importantly, > it forces every CPU to have an instruction and a data port, and gives > these ports explicit getters in the BaseCPU (getDataPort and > getInstPort). The patch helps in simplifying the code, make > assumptions more explicit, andfurther ease future patches related to > the CPU ports. > > The biggest changes are in the in-order model (that was not modified > in the previous unification patch), which now moves the ports from the > CacheUnit to the CPU. It also distinguishes the instruction fetch and > load-store unit from the rest of the resources, and avoids the use of > indices and casting in favour of keeping track of these two units > explicitly (since they are always there anyways). The atomic, timing > and O3 model simply return references to their already existing ports. > > > Diffs > ----- > > src/cpu/base.hh ef8630054b5e > src/cpu/base.cc ef8630054b5e > src/cpu/base_dyn_inst.hh ef8630054b5e > src/cpu/inorder/InOrderCPU.py ef8630054b5e > src/cpu/inorder/cpu.hh ef8630054b5e > src/cpu/inorder/cpu.cc ef8630054b5e > src/cpu/inorder/resource.hh ef8630054b5e > src/cpu/inorder/resource_pool.9stage.cc ef8630054b5e > src/cpu/inorder/resource_pool.hh ef8630054b5e > src/cpu/inorder/resource_pool.cc ef8630054b5e > src/cpu/inorder/resources/cache_unit.hh ef8630054b5e > src/cpu/inorder/resources/cache_unit.cc ef8630054b5e > src/cpu/o3/cpu.hh ef8630054b5e > src/cpu/o3/cpu.cc ef8630054b5e > src/cpu/o3/fetch_impl.hh ef8630054b5e > src/cpu/o3/iew_impl.hh ef8630054b5e > src/cpu/o3/lsq_impl.hh ef8630054b5e > src/cpu/simple/atomic.hh ef8630054b5e > src/cpu/simple/atomic.cc ef8630054b5e > src/cpu/simple/base.hh ef8630054b5e > src/cpu/simple/timing.hh ef8630054b5e > src/cpu/simple/timing.cc ef8630054b5e > src/cpu/thread_state.cc ef8630054b5e > src/kern/tru64/tru64_events.cc ef8630054b5e > src/mem/fs_translating_port_proxy.cc ef8630054b5e > > Diff: http://reviews.gem5.org/r/1046/diff/diff > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
