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
