> On July 2, 2012, 1:07 p.m., Andreas Hansson wrote: > > 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? > > Ali Saidi wrote: > I think adding a flag on the cache model is more complex and doesn't buy > much in practice. Dirty data can still live in a unified cache (because it > would get inserted by a write instead of an instruction fetch). The change > would need to be a property of the requesting cache, but it would need to > effect the sending cache in which case more fields would need to be added to > the packet. > > In summary, I still think that the way it's implemented is probably > preferable. > > Anthony Gutierrez wrote: > If it's a shared i/d cache, I would assume that a packet that is fetching > an instruction would still be distinguished as such. Also, I think a shared > i/d cache would cause several other issues beyond this. I.e., we couldn't > have the cache invalidation instructions, as they actually function in > ARM/x86, modeled in gem5 at all. E.g., we couldn't implement mcr icialluis as > it actually works, or if we did, we could never have dirty data in the L1.
All makes sense. Do we have to add some form of check to ensure that the user-specified configuration adheres to specific rules? - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1284/#review3011 ----------------------------------------------------------- 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
