This what I have thought of. Currently, doTransition() function takes in
the cache state of the address that is being supplied. This function
further calls setState() function, one of functions that repeatedly calls
isTagPresent(). Instead, if we pass the cache state and the cache Entry
reference to doTransition(), then we will not have to call all the
isTagPresent().
The problem with this is that before the caches looked up, there is a
structure called TBE which is being looked up. What does TBE stands for?
We can pass references to a TBE entry and a cache entry. If the TBE entry
has a valid state, then it is used. Else the state of the cache entry is
looked and used if valid.
Nilay
On Tue, 30 Nov 2010, Nilay Vaish wrote:
Is it possible to have variables local to a function in .sm files. I am
thinking of storing getCacheEntry()'s return value in a local variable.
Nilay
On Mon, 29 Nov 2010, Beckmann, Brad wrote:
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
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
