Brad

We would need to change the lookup functions for TBETable and CacheMemory. Currently the lookup functions assume that the address passed on to the lookup is present. This requires two lookups to the data structures associated with these classes, one for checking whether the address is in the cache, second one for returning a reference to the actual cache entry. Instead of returning a reference, we can return a pointer to the entry. This pointer will be null in case the address is not present in the cache.

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

Reply via email to