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
