Hi Nilay, Yes, I believe a machine can be accessed within AST class functions, though I don't remember ever doing it myself. Look at the generate() function in TypeFieldEnumAST. Here you see that the machine (a.k.a StateMachine) is grabbed from the symbol table and then different StateMachine functions are called on it. You can imagine adding a new function to StateMachine.py that returns whether the TBETable exists.
That seems like it should work to me, but let me know if it doesn't. Brad > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Nilay Vaish > Sent: Thursday, December 09, 2010 5:24 PM > To: M5 Developer List > Subject: Re: [m5-dev] Implementation of findTagInSet > > Hi Brad > > Is there way to access the StateMachine object inside any of the AST > class > functions? I know the name of the machine can be accessed. But can the > machine itself be accessed? I need one of the variables in the > StateMachine object to know whether or not TBETable exists in this > machine. > > > Nilay > > On Wed, 8 Dec 2010, Beckmann, Brad wrote: > > > Hi Nilay, > > > > I think we can avoid handling pointers in the getState and setState > functions if we also add bool functions "is_cache_entry_valid" and > "is_tbe_entry_valid" that are implicitly defined in SLICC. I don't > think we should try to get rid of getState and setState since they > often contain valuable, protocol-specific checks in them. Instead for > getState and setState, I believe we should simply replace the current > isTagPresent calls with the new is_*_valid calls. > > > > As far as changePermission() goes, your solution seems reasonable, > but we may also want to consider just not changing that function at > all. ChangePermission() doesn't actually use a cache entry within the > .sm file, so is doesn't necessarily need to be changed. Going back to > breaking this work into smaller portions, that is definitely a portion > I feel can be pushed to the end or removed entirely. > > > > Brad > > > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf Of Nilay Vaish > > Sent: Wednesday, December 08, 2010 11:53 AM > > To: M5 Developer List > > Subject: Re: [m5-dev] Implementation of findTagInSet > > > > Hi Brad, > > > > A couple of observations > > > > a. If we make use of pointers, would we not need to handle them in > getState and setState functions? > > > > b. changePermission() seems to be a problem. It would still perform a > lookup because the fact that a CacheEntry is a locked or not is > maintained in the CacheMemory object and not with the entry itself. We > can move that variable to be part of the AbstractCacheEntry or we can > combine it with the permission variable which is already there in the > AbstractCacheEntry class. I think lock is only used in the > implementation of LL/SC instructions. > > > > Nilay > > > > > > On Wed, 8 Dec 2010, Beckmann, Brad 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 > >> > >> > >> _______________________________________________ > >> 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 _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
