Hi Brad,
I have added implicit variables for TBE and Cache entry pointers. These
get inserted in to the doTransition() calls made in Wakeup(). These
variables are forwarded to doTransitionWorker() which passes them on to
all the action functions.
Following is what I think needs to be done next -
1. Currently the implicit TBE and Cache Entry pointers are set to NULL in
the calls to doTransition() function. To set these, we would need to make
calls to a function that returns the pointer if the address is in the
cache, NULL otherwise.
I think we should retain the getEntry functions in the .sm files for in
case of L1 cache both instruction and the data cache needs to be checked.
This is something that I probably would prefer keeping out of SLICC. In
fact, we should add getEntry functions for TBEs where ever required.
These getEntry would now return a pointer instead of a reference. We would
need to add support for return_by_pointer to SLICC. Also, since these
functions would be used inside the Wakeup function, we would need to
assume a common name for them across all protocols, just like getState()
function.
2. I still think we would need to change the changePermission function in
the CacheMemory class. Presently it calls findTagInSet() twice. Instead,
we would pass on the CacheEntry whose permissions need to be changed. This
would save one call. We should also put the variable m_locked in the
AbstractCacheEntry (may be make it part of the permission variable) to
avoid the second call.
3. In the getState() and setState() functions, we need to specify that the
function assumes that implicit TBE and CacheEntry pointers have been
passed as arguments. How should we do this? I think we would need to push
them in to the symbol table before they can be used in side the function.
Thanks
Nilay
On Sat, 11 Dec 2010, Nilay Vaish wrote:
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
