----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1284/#review3011 -----------------------------------------------------------
It looks reasonable. I am not entirely sure about the distinction of the packets though. What happens for shared I and D? Would it not be better to make it a property of the cache rather than the packet, i.e. a parameter on the class? - Andreas Hansson On July 2, 2012, 11:21 a.m., Anthony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1284/ > ----------------------------------------------------------- > > (Updated July 2, 2012, 11:21 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9086:1c54688932a1 > --------------------------- > cache: don't allow dirty data in the i-cache > > removes the optimization that forwards an exclusive copy to a requester on a > read, only for the i-cache. this optimization isn't necessary because we > typically won't be writing to the i-cache. > > > Diffs > ----- > > src/mem/cache/cache_impl.hh 5f0321c03a2602f34dd03700e41e0cf5b47b8761 > > Diff: http://reviews.gem5.org/r/1284/diff/ > > > Testing > ------- > > Added i-cache invalidation instruction for ARM. These instructions invalidate > i-cache entries without writing them back, because it is not expected for > there to be dirty data in the caches. While invalidating I would get assert > failures and/or the program would hang due to dirty data in the i-cache being > invalidated. Doing this fixed those problems. Ran BBench to completion with > this fix and inv instructions in place. This is a necessary step towards > adding the inv instructions for ARM. > > > Thanks, > > Anthony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
