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
