On Fri, 29 May 2015, Brad Beckmann wrote:
On May 14, 2015, 2:43 p.m., Joel Hestness wrote:
I agree with Nilay on this one. If there is a reason to have a pointer, then
the C++ code should export a pointer type. Brad, it seems you also agree. From
your response on review 2790 ( http://reviews.gem5.org/r/2790/ ):
SLICC has been designed not to directly expose pointers to the programmer
So, this patch breaks a solid programming abstraction that already exists in
SLICC. Further, if this patch were introduced and people use getPointer, then
reverting this change later will be painful. It would be best to fix things the
right way here.
Brad Beckmann wrote:
I don't think there is an easy way to avoid this unless one were to
re-implement PerfectCacheMemor and DirectoryMemory. That goes well beyond this
patch and has many implications. This patch has existed for 3+ years because
there is no easy fix here. Woud you be ok if we changed the name of the
function from getPointer() to convertDirEntryToCacheEntry()?
On 5/19 Nilay said "No.
Can you explain how DirectoryMemory and PerfectCacheMemory are different from
CacheMemory? To me the fact that the patch has existed for 3+ years means that
nobody tried to do things the way I feel they should be done.
Please maintain regularity across different structures. I do not want to treat
DirectoryMemory any different from CacheMemory."
The difference is all three structures have lookup functions that return
different data types. The function getCacheEntry assumes lookup returns a
CacheEntry pointer.
This is a simple change that helps fix a problem we are having and
doesn't impact other protocols. Please do not protest just because it
wasn't done the way you would have done it. There is only one Nilay and
there are many issues encountered when developing protocols that cannot
be solved by a single person.
I have the same objections with the updated patches as before. I find
some of the patches unnecessary, some implemented not keeping the bigger
context in mind, and some are unjustified / out rightly incorrect. We have
had discussions about these patches over past four weeks or so. I felt
AMD unwilling to make any changes other than cursory ones. Hence, I am
not going to consent to these patches.
And yes, there is only one Nilay. He has finite amount of time and he
feels it is not prudent to spent any more time in discussing these patches.
So he would not respond any further discussion on these patches.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
