I thank that the tags should be a SimObject instead of using the builder magic. We've got some patches kicking around to do this. So you can actually change the replacement policy of the caches by adding a SimObject like everything else in the code base instead of having to hack on builder.cc.
Thanks, Ali On Jun 1, 2013, at 12:02 PM, Anthony Gutierrez <[email protected]> wrote: > As of now the fa_lru tags seem broken. There are a few obvious bugs, due to > the use of unsigned being used as an index in places when it has rolled > over. I tried (not very hard, I admit) to make it functional a while back > but gave up once I realized it was easier just to use the standard tags and > disable fa_lru when I was trying to use a fully-associative cache. So, if > the builder is kept, I think some effort should be put into making fa_lru > functional, as it seems it's a common problem people run into when trying > to use FA caches: > http://qa.gem5.org/42/how-to-set-a-fully-associative-l1-cache > > Anthony Gutierrez > http://web.eecs.umich.edu/~atgutier > > > On Sat, Jun 1, 2013 at 12:55 PM, Steve Reinhardt <[email protected]> wrote: > >> On Sat, Jun 1, 2013 at 9:24 AM, Nilay Vaish <[email protected]> wrote: >> >>> >>> I wonder what the intention was behind the cache builder. >> >> >> >> The idea is that you have a single user-visible Cache class (SimObject) in >> Python that maps to multiple C++ classes. The cache builder then chooses >> the proper C++ cache class based on the configuration-time parameters. So >> we have a tag implementation that's optimized for fully associative caches, >> but you don't have to explicitly instantiate a different class to get it, >> you just use the normal cache class and set the associativity to >> size/block_size and the builder selects that class instead of the "normal" >> class. We used to use this for building an IIC instead of a normal cache >> as well, but the IIC code was removed a while ago since no one used it. >> >> In fact, I don't believe there is a way to use the fully associative tags >> other than via the cache builder, so I'm not sure that Andreas's >> description of the code as "redundant" is actually accurate. Further, it >> seems like if we're going to get rid of the cache builder, then we should >> get rid of the fa_lru.* files as well since (if I'm right) there's no way >> to actually use that code. And if we get rid of fa_lru.*, then we'll only >> have one tag class instance (lru.*), so it doesn't make a lot of sense to >> have a template parameter for the cache that only has one possible value. >> Do we really want to go that far? If yes, then we should go all the way >> there. If not, then we shouldn't start down this path. >> >> Steve >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
