This sounds like a great direction to me... continuing in this vein, would it be possible to factor out the protocol-specific implementations of getState() and setState() entirely? I'm thinking that each of these calls involves a check to see if the block is in a TBE or not, followed by the code to handle the case where it's not in a TBE but is in the cache, and if there's a way to only do the TBE check once per access that could save even more.
In terms of keeping changes small, you should save this for after you do the changes Brad suggests, and maybe it's actually not even a good idea, but I wanted to plant the seed. Steve On Wed, Dec 8, 2010 at 9:00 AM, Beckmann, Brad <[email protected]>wrote: > Hi Nilay, > > Breaking the changes into small portions is a good idea, but we first need > to decide exactly what we are doing. So far we've only thrown out some > ideas. We have not yet to scope out a complete solution. I think we've > settled on passing some sort of reference to the cache and tbe entries, but > exactly whether that is by reference variables or pointers isn't clear. My > initial preference is to use pointers in the generated code and set the > pointers to NULL when a cache and/or tbe entry doesn't exist. However, one > thing I really want to strive for is to keep pointer manipulation out of the > .sm files. Writing SLICC code is hard enough and we don't want to burden > the SLICC programmer with memory management as well. > > So how about this plan? > - Lets remove all the getCacheEntry functions from the slicc files. I > believe that almost all of these functions look exactly the same and it is > easy enough for SLICC to just generate them instead. > - Similarly let get rid of all "isCacheTagPresent" functions as well > - Then lets replace all the getCacheEntry calls with an implicit SLICC > supported variable called cache_entry and all the TBEs[addr*] calls with an > implicit SLICC supported variable called tbe_entry. > - Underneath these variables can actually be implemented as local > inlined functions that assert whether the entries are valid and then return > variables local to the state machine set to the current cache and tbe entry. > - The trigger function will implicitly set these variables (pointers > underneath) to NULL or valid values, and the only what they can be reset is > through explicit functions "set_cache_entry", "reset_cache_entry", > "set_tbe_entry", and "reset_tbe_entry". These function would be called by > the appropriate actions or possibly be merged with the existing > "check_allocate" function. > > I think that will give us what we want, but I realize I've just proposed > changing 100's if not 1000's lines of SLICC code. I hope that these changes > are straight forward, but any change like that is never really "straight > forward". > > Let's think it over some more and let me know if you want to discuss this > in more detail over-the-phone. > > Brad > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Nilay Vaish > Sent: Tuesday, December 07, 2010 5:21 PM > To: M5 Developer List > Subject: Re: [m5-dev] Implementation of findTagInSet > > Brad, > > Let's try to break the required changes into small portions. Given my > feeble knowledge of Ruby, it would be for me to visualize what change is > going to have what effect. > > One question, should we use pointers to pass the cache entry around, or > should we make use of reference variables? Currently lookup functions return > references to cache entries. > > Nilay > > > On Tue, 7 Dec 2010, Beckmann, Brad wrote: > > > Hi Nilay, > > > > Yes, this is not an easy issue to fix. First to answer your other > > question, I believe TBE stands for Transaction Buffer Entry, or > > something to that effect. As you suggested, we can pass in the cache > > entry and possibly even the TBE entry into the trigger function. Thus > > all actions will implicitly include these two parameters as inputs and > > not require continually lookups or even local variables. However, I > > believe to make this work we need to change the semantics for > > allocating and deallocating cache and TBE entries. In particular, > > these operations probably should be handled by specialized operators > > (similar to trigger) that correctly manage the pointers underneath. > > > > Does that make sense? Let me know if you'd like to brainstorm more > > about this over a phone conversation. > > > > Brad > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Nilay Vaish > > Sent: Tuesday, December 07, 2010 12:16 AM > > To: M5 Developer List > > Subject: Re: [m5-dev] Implementation of findTagInSet > > > > I have made changes to SLICC to support local reference variables. I > > think we should reference variables in functions where back to back > > calls are made to lookup/getCacheEntry functions. > > > > Overall, I am still unclear how can we handle this issue. > > > > 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 > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
