On Fri, 6 May 2011, Beckmann, Brad wrote:
Hi Nilay,
Yeah, pulling the State into the Machine makes sense to me. If I
recall, my previous patch made it necessary that each machine included a
state_declaration (previously the state enum). More tightly integrating
the state to the machine seems to be a natural progression on that path.
I understand moving the permission settings back to setState is the
easiest way to make this work. However, it would be great if we could
combine the setting of state and the setting of permission into one
function call from the sm file. Thus we don't have to worry about the
situation where one sets the state, but forgets to set the permission.
That could lead to some random functional access failing and a very
painful debug.
Brad
I was trying to recall why I had suggested pulling State in to the
Machine. It seems the reasoning was that then the calls to the function
*_State_to_Permission() can be shortened to State_to_Permission().
The problem with combining the setting state and the permission it seems
would be that cache and directory entries are treated differently. Cache
entries get supplied to set state as pointers, where as directory entries
are sought within the function it self.
I am currently in favor of going with what I submitted earlier so that
functional access patch can get out of the way soon as possible.
--
Nilay
_______________________________________________
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
