> On May 20, 2012, 3:34 p.m., Steve Reinhardt wrote: > > src/cpu/decode_cache.hh, line 188 > > <http://reviews.gem5.org/r/1193/diff/1/?file=26343#file26343line188> > > > > Why the change from the if/else structure in the original function? > > That seemed reasonable to me, and avoided duplication of a couple of > > (admittedly simple) lines of code.
The idea was to isolate the different stages of the lookup. The first chunk looks in the address based cache, the second looks in the ExtMachInst based cache, and the third actually decodes the instruction. Each is responsible for fixing up the earlier caches if there's a hit. With the old structure, things were mixed together which, I thought, would make it more difficult to mix and match components, or at least see how this particular caching organization is structured. - Gabe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1193/#review2757 ----------------------------------------------------------- On May 15, 2012, 5:56 a.m., Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1193/ > ----------------------------------------------------------- > > (Updated May 15, 2012, 5:56 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9007:906c07bc6917 > --------------------------- > CPU: Simplify the implementation of the decode cache. > > Also reorganize it to make it more amenable to being rearranged later. > > > Diffs > ----- > > src/cpu/decode_cache.hh f681719e2e99 > > Diff: http://reviews.gem5.org/r/1193/diff/ > > > Testing > ------- > > > Thanks, > > Gabe Black > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
