Hi Nilay, I don't think we want to replace the implicit Address parameter inside the state machines with the CacheEntry parameter, but we might want to supplement the state machine functions to include both. I don't think we can replace the Address parameter because certain transitions within a state machine don't operate on a CacheEntry, but they do operate on an Address. However, as we discussed last week, we might be able to pass the CacheEntry into the trigger function along with the Address, which is then implicitly included in all actions. The key in my mind is that we want to maintain the current programming invariant that SLICC does not expose pointers, but underneath the generated code needs to manage that sometimes the CacheEntry pointer may equal NULL. In particular, I would like to minimize any added complexity we put on the setState function. I think we can make this work, but we need to think through the details, including how replacements are handled.
I have a few other things I need to take care of first, but I may be able to look into the details of how to make this work by the end of the week. Brad -----Original Message----- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Saturday, November 27, 2010 11:40 AM To: M5 Developer List Subject: Re: [m5-dev] Implementation of findTagInSet Is it not possible to redesign the functions to accept CacheEntry as a paramemter instead of a Address parameter? On Sat, 27 Nov 2010, Nilay Vaish wrote: > I conducted an experiment to figure out how many calls are made to the hash > table to check if the given address exists in the cache. For the same setup > as before, less than 10% calls are made. That is out of about 880,000,000 > calls to the isTagPresent function, only about 81,000,000 actually go and > search the hash table. > > I think we should work towards removing some of the redundant calls. I have a > partial fix for some portion of the code. But again, it is not a design > change. I am unsure how to change the design of Ruby and/or Slicc to get done > with these redundant calls. > > Brad, do you have something in mind on this? > > Thanks > Nilay > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
