On Fri, 24 Jul 2015, Brad Beckmann wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2988/#review6821
-----------------------------------------------------------
I'm surprised you moved forward on this patch. I thought I had
communicated over email a few weeks ago that we should not go down this
path before a lot of careful thought and debate on whether this is a
The patch has been posted to initiate a wider debate, to quantify the
performance gains and the required changes.
good thing to do. Personally I think this patch removes many of the
benefits of having a SLICC ast and goes against many of the main design
principles of SLICC. SLICC is designed to avoid having the programmer
worry about memory management. SLICC is a layered development approach
ruby uses shared pointers for Message objects. But messages are not
shared by multiple objects. At a given time, only one object holds the
pointer to a message object. So there should not be any need for messages
to be shared pointers. They can be deleted as soon as the current owner
realizes that the message is no longer required. In my opinion, the
question memory management does not arise at all.
where the sm file is only meant to considering the protocol logic. I
believe that is why SLICC has been so successful over the past 16+
years. It allows one to create differnet protocols without requiring
one to write C++ and handle complicated memory management. This patch
removes those benefits.
I don't know how to measure the success of a language, more so when it is
allowed to undergo changes. Comparing the ISA description language and
SLICC, I find that SLICC has was change 33% times more even though it has
been around for only half the time. To me this means that SLICC is not as
stable as it can be. And I think the major reason is that it attempts to
do things that are better done in plain C++.
Please do not check this in. We need to come to a consensus on whether
this is even a good direction to go in first.
I'll reiterate the two points that I have made before for this patch.
a. shared_pointers have a cost. I think the savings made is substantial
enough to justify the required changes to current protocols. My back of
the envelope calculations tell me that for a research group like AMD
Research, it makes economic sense as well.
b. We will be unifying the memory systems some time in future. I think
we would end writing a coherence protocol for the classic memory system.
Instead of redoing all the work in SLICC, we would copy the current code
C++ directly. This would require actions to have C++ code blocks.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
