Re: [m5-dev] AccessPermission in AbstractEntry
Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Sunday, April 10, 2011 2:12 AM To: m5-dev@m5sim.org Subject: [m5-dev] AccessPermission in AbstractEntry Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] AccessPermission in AbstractEntry
On Mon, 11 Apr 2011, Beckmann, Brad wrote: Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. I will try to make this change later today. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad Is it not possible that we have a protocol in which different directory controllers may behave differently? -- Nilay -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Sunday, April 10, 2011 2:12 AM To: m5-dev@m5sim.org Subject: [m5-dev] AccessPermission in AbstractEntry Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] AccessPermission in AbstractEntry
-Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Monday, April 11, 2011 2:38 PM To: M5 Developer List Subject: Re: [m5-dev] AccessPermission in AbstractEntry Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Is it not possible that we have a protocol in which different directory controllers may behave differently? Ok, I just had a chance to look at the code and I think you a referring to the lack of a directory MACHINETYPE macro in RubySlicc_ComponentMapping.hh. Is that correct? Ideally, there shouldn't be a problem with adding any arbitrarily named controller to Ruby, as long as you incorporate the right component mapping functions into the protocol. However, in practice I suspect it will take some non-trivial amount of modifications to RubySlicc_ComponentMapping.hh. Also you'll need to be careful how Ruby and generate SLICC code uses the auto generated MachineType functions. There may be some tricky issues there. Overall, I can't really provide you a lot of specifics on why the directory MACHINETYPE macro does not exist. There may have been some assumptions behind that that were relevant in GEMS but are no longer valid in gem5. I would grep through the Ruby and generated code for the MachineType functions to fully understand the ramifications. Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] AccessPermission in AbstractEntry
Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
