On Tue, 11 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the trigger function. That way
the address, cache_entry, and tbe_entry variables are dealt with
consistently and it avoids adding the separate calls to
set_cache_entry() and set_tbe () in the inports.
Firstly, we have to set cache and transaction buffer entry variables
whenever we do allocation or deallocation of entries. This means these
calls cannot be completely avoided. Secondly, while processing events from
the mandatory queue (as it is called in the current implementations), if
these variables are not set, we will have to revert to the earlier
approach. This would double the number of times cache entry lookups are
performed as the trigger function will perform the lookup again. This
would also mean that both the approaches for looking up cache entry in the
cache will have to exist simultaneously.
Another concern is in implementation of getCacheEntry(). If this function
has to return a pointer to a cache entry, we would have to provide support
for local variables which internally SLICC would assume to be pointer
variables.
In my opinion, we should maintain one method for looking up cache entries.
My own experience informs me that it is not difficult to incorporate calls
to set/unset_cache_entry () in already existing protocol implementations.
For implementing new protocols, I think the greater obstacle will be in
implementing the protocol correctly and not in using entry variables
correctly. If we document this change lucidly, there is no reason to
believe a SLICC programmer will be exceptionally pushed because of this
change.
Assuming that this change does introduce some complexity in progamming
with SLICC, does that complexity out weigh the performance improvements?
--
Nilay
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
