On Tue, 12 May 2015, Brad Beckmann wrote:
On May 12, 2015, 4:08 a.m., Nilay Vaish wrote:
Again, I would like to know what behaviour is this change trying to achieve?
What more do I need to say beyond what the description already says?
It allows us to overload global functions, such as
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2796/#review6228
---
Ship it!
Ship It!
- Jason Power
On May 11, 2015, 10:21 p.m., Tony
On Tue, 12 May 2015, Brad Beckmann wrote:
On May 12, 2015, 4:05 a.m., Nilay Vaish wrote:
I need an example why this is required. What behavior is not achievable right
now?
Here is the initial patch description from a certain intern back in 2012:
Adds a function to slicc to return the
On May 12, 2015, 9:06 p.m., Nilay Vaish wrote:
I need a clarification on the proposed syntax. Is one port being nested
inside the other? For example
in_port() {
in_port() {
}
}
Or the two in_ports have separate declarations (not nested), but they share
the same
On May 12, 2015, 10:02 p.m., Jason Power wrote:
src/mem/slicc/ast/PeekStatementAST.py, line 69
http://reviews.gem5.org/r/2789/diff/1/?file=45006#file45006line69
Could you explain why an exception is required here? Looking through
the rest of the gem5 code, the only other times we
On May 12, 2015, 10:03 p.m., Jason Power wrote:
Cool. Are you planning on updating the mainline protocols to use these in
the future? Or just new protocols?
Just new protocols.
- Brad
---
This is an automatically generated
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is a stretch. Any module hitting this
On May 12, 2015, 4:22 p.m., Joel Hestness wrote:
This change seems to go away from its apparent aim:
First, this patch seems to be aimed at correcting some common confusion:
The RubyCache latency parameter is strange, because the cache itself does
not enforce the latency. Instead,
On May 12, 2015, 3:24 p.m., Jason Power wrote:
src/mem/ruby/system/RubyPort.cc, line 298
http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line298
I don't understand why the random tester doesn't want to retry failed
requests. Could you explain why this feature is
On May 12, 2015, 3:24 p.m., Jason Power wrote:
src/mem/ruby/system/RubyPort.cc, line 298
http://reviews.gem5.org/r/2776/diff/1/?file=45140#file45140line298
I don't understand why the random tester doesn't want to retry failed
requests. Could you explain why this feature is
On Wed, 13 May 2015, Brad Beckmann wrote:
On May 12, 2015, 5:45 a.m., Andreas Hansson wrote:
src/mem/packet_queue.cc, line 117
http://reviews.gem5.org/r/2776/diff/1/?file=45138#file45138line117
I strongly disagree with this change. This buffer should not exist, and
even 100 packets is
The reason why the requests cannot be processed is not a resource issue. It is
usually an address contention issue. When the address contention issue is
resolved, a large racey burst of requests is issued at once. That is exactly
the type of scenario that finds protocol bugs. The request
On May 12, 2015, 3:48 a.m., Nilay Vaish wrote:
This patch is incorrect on a couple of counts. We are not in 32-bit world.
Secondly, you should expose the getAddress() function as we expose
functions related to other classes.
This comment is dissappointing and unprofessional. I'm
14 matches
Mail list logo
