----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/828/#review1482 -----------------------------------------------------------
Assuming there are no stats changes, it seems fine. src/cpu/o3/fetch.hh <http://reviews.m5sim.org/r/828/#comment1983> This comment is nearly useless. src/cpu/simple/base.cc <http://reviews.m5sim.org/r/828/#comment1984> Have you looked at the performance difference here? - Ali On 2011-08-16 03:08:30, Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/828/ > ----------------------------------------------------------- > > (Updated 2011-08-16 03:08:30) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > Decode: Pull instruction decoding out of the StaticInst class into its own. > > This change pulls the instruction decoding machinery (including caches) out of > the StaticInst class and puts it into its own class. This has a few intrinsic > benefits. First, the StaticInst code, which has gotten to be quite large, gets > simpler. Second, the code that handles decode caching is now separated out > into its own component and can be looked at in isolation, making it easier to > understand. I took the opportunity to restructure the code a bit which will > hopefully also help. > > Beyond that, this change also lays some ground work for each ISA to have its > own, potentially stateful decode object. We'd be able to include less > contextualizing information in the ExtMachInst objects since that context > would be applied at the decoder. Also, the decoder could "know" ahead of time > that all the instructions it's going to see are going to be, for instance, 64 > bit mode, and it will have one less thing to check when it decodes them. > Because the decode caching mechanism has been separated out, it's now possible > to have multiple caches which correspond to different types of decoding > context. Having one cache for each element of the cross product of different > configurations may become prohibitive, so it may be desirable to clear out the > cache when relatively static state changes and not to have one for each > setting. > > Because the decode function is no longer universally accessible as a static > member of the StaticInst class, a new function was added to the ThreadContexts > that returns the applicable decode object. > > > Diffs > ----- > > src/arch/alpha/remote_gdb.cc 889818c58eff > src/arch/arm/remote_gdb.cc 889818c58eff > src/cpu/SConscript 889818c58eff > src/cpu/decode.hh PRE-CREATION > src/cpu/decode.cc PRE-CREATION > src/cpu/decode_cache.hh PRE-CREATION > src/cpu/inorder/cpu.hh 889818c58eff > src/cpu/inorder/cpu.cc 889818c58eff > src/cpu/inorder/inorder_dyn_inst.hh 889818c58eff > src/cpu/inorder/inorder_dyn_inst.cc 889818c58eff > src/cpu/inorder/resources/fetch_unit.hh 889818c58eff > src/cpu/inorder/resources/fetch_unit.cc 889818c58eff > src/cpu/inorder/thread_context.hh 889818c58eff > src/cpu/legiontrace.cc 889818c58eff > src/cpu/o3/fetch.hh 889818c58eff > src/cpu/o3/fetch_impl.hh 889818c58eff > src/cpu/o3/thread_context.hh 889818c58eff > src/cpu/simple/base.hh 889818c58eff > src/cpu/simple/base.cc 889818c58eff > src/cpu/simple_thread.hh 889818c58eff > src/cpu/static_inst.hh 889818c58eff > src/cpu/static_inst.cc 889818c58eff > src/cpu/thread_context.hh 889818c58eff > > Diff: http://reviews.m5sim.org/r/828/diff > > > Testing > ------- > > > Thanks, > > Gabe > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
