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